Right now I have a development server running a basic LAMP configuration. The production server is a slicehost. But I'm wondering what is the best way to push the instances of the code/db to the stages dev > stage > production. Does it have to do with how you create the stages?
How do you do it without bring the site down? Is it even possible if you don't do load balancing?
I know this is somewhat general, I'm just looking to be pointed in the right direction.
I use .htaccess to create a "maintenance mode" jiffy where only my IP can see the main site while updating. Everybody else gets to view a short message so they know everything should be back online in a few ticks.
Then I:
It's a given but you should test things as much as you can locally before pushing to a live server. Some people use two live servers (like a cryptically name subdomain on the production server) to act as a test-area for live-time updates. This can reduce the main site's actual downtime.
I should stress that it's important not to push updates to a live server without shutting it down beforehand (especially if you're using binaries ala ASPNET) because users trying to use the site while you update will get hideous error messages and you might get locked files.
I'd look into some sort of automated "build" style environment for lamp where you have scripts that package and prepare your releases for each environment.
I recognize there is no actual building for PHP but you could set up automation to change any configuration or setup issues and save everything off to a folder ready to be implemented.
I don't believe you can completely eliminate downtime without load balancing / web farm style environments. However the easiest way to reduce it in my book is by establishing a consistent code prep process and testing the process multiple times. Automation would help there.
As for the act of actually copying the files, well I don't know much more than using something like FTP or whatever is convenient. Maybe putting up a loading message. Again this could all be scripted out.
Finally keep in mind since PHP isn't built it might work well for you to track differences between what's there now and what you have changed and only move those files. Sometimes that can add unneeded complexity though.
I don't know if this is a good idea, but what about automated checkouts from a source control system? Perhaps having a few branches of development - testing for bleeding-edge, development for maintenance/small improvements, and production for the production code. Whenever development is stable, merge it into the production branch and have it automatically checked out on a regular basis by the production machine.
As far as pushing files out to all the web servers I find that good old robocopy does the trick. My dev/stage/prod environments are all identical of course. Just put up a temporary page that tells users the site will be right back.
现在，我们使用一系列带有配置文件的 shell 脚本，这些脚本将我们更改的文件打包，将它们 scp 到集群中的每个服务器，然后在它们存在后解压缩它们。这种方法当然有其缺点，我们正在考虑一种方法，其中每个服务器成员都安装一个 svn 客户端，并且一旦我们标记一个新版本，我们就将生产服务器上的工作副本切换到该新标记。当然，我们现在在维护期间发布，所以我们不必为我们的用户做任何特别的事情（他们无论如何都会看到维护页面）。
我的核心配置中有一个选项可以允许访问站点或预设 URL 列表，我可以将所有用户重定向到（并使用适当的 http 代码停止任何 API 流量）。
这些 url 是指向静态 html 文件的链接，向用户解释正在发生的事情。
启用此功能后，不会对数据库或任何文件发出请求，因为在此之前所有请求都会发送到 HTML 文件，这为我提供了一个“清晰”的空间来部署任何更新。
具有 svn 和 ftp 任务的 apache ant 为我买单。甚至有人用 ANT 做 db 的事情，但我倾向于亲自观看这些。一旦你有一个干净的和推送的 ftp 构建到你所有的位置，你会惊讶于它是多么容易。