What is your preferred php deployment strategy? [closed]

Question

For PHP, SVN with Phing build scripts are the way to go. Phing is similar to ANT but is written in PHP, which makes it much easier for PHP developers to modify for their needs.

Our deployment routine is as follows:

• Everyone develops on the same local server at work, every developer has a checkout on his machine back home as well.
• Commits trigger a post-commit hook which updates a staging server.
• Tests are ran on staging server, if they pass - continue.
• Phing build script is ran:
• Takes down production server, switching the domain to an "Under construction" page
• Runs SVN update on production checkout
• Runs schema deltas script
• Runs tests
• If tests fail - run rollback script
• If tests pass, server routes back to production checkout

There's also phpUnderControl, which is a Continuous Integration server. I didn't find it very useful for web projects to be honest.

I'm currently deploying PHP using Git. A simple git push production is all that's needed to update my production server with the latest copy from Git. It's easy and fast because Git's smart enough to only send the diffs and not the whole project over again. It also helps keep a redundant copy of the repository on the web server in case of hardware failure on my end (though I also push to GitHub to be safe).

We use Webistrano, a web frontend for Capistrano, and are very happy with it.

Webistrano allows multi-stage, multi-environment deployments from SVN, GIT and others. It has built-in rollback support, support for separate server roles such as web, db, app, etc., and deploys in parallel. It allows you to override config parameters on multiple levels, such as per stage, and logs the results of every deploy, optionally mailing it.

Even though Capistrano and Webistrano are Ruby applications, the syntax of the deployment 'recipes' is easy and powerful enough to understand for any PHP programmer. Originally Capistrano was built for Ruby on Rails projects, but easily accommodates PHP projects.

Once configured it is even easy enough to be used by non-programmers, such as testers deploying a staging version.

To provide the fastest deploy possible we installed the fast_remote_cache method, which updates a svn working-copy cache on the remote server, and then hardlinks the result.

I use Apache Ant to deploy to different targets (dev, QA and live). Ant is designed to work for Java deployment, but it provides a pretty useful general case solution for deploying arbitrary files.

The syntax of the build.xml file is pretty easy to learn - you define different targets and their dependencies which run when you call the ant program on the command line.

For example, I have targets for dev, QA and live, each of which depends on the cvsbuild target which checks out the latest head revision from our CVS server, copies the appropriate files to the build directory (using the fileset tag), and then rsyncs the build directory to the appropriate server. There are a few quirks to learn, and the learning curve is not totally flat, but I've been doing it this way for years with no trouble so I'd recommend it for your situation, though I'm curious what other answers I'll see on this thread.

I do stuff manually using Git. One repository for development, which gets git push --mirror'ed to a public repo, and the live server is a third repo pulled from that. This part I suppose is the same as your own setup.

The big difference is that I use branches for nearly every change I'm working on (I've got about 5 right now), and tend to flip back and forth between them. The master branch doesn't get changed directly except for merging other branches.

I run the live server direct from the master branch, and when I'm finished with another branch and ready to merge it, flip the server to that branch for a while. If it breaks, putting it back to master takes seconds. If it works, it gets merged into master and the live code gets updated. I suppose an analogy of this in SVN would be having two working copies and pointing to the live one via a symlink.

I know Phing has been mentioned a few times now, but I've had great luck with phpUnderControl. For us we

1. Check out individual copies of branches to local machines
2. Branches are tested and then merged into Trunk
3. Commits to Trunk are automatically built by phpUnderControl, runs tests and builds all documentation, applies database deltas
4. Trunk gets run through quality testing and then merged into our Stable branch
5. Again, phpUnderControl automatically builds Stable, runs tests, and generates documenation and updates database
6. When we're ready to push to production we run a rsync script that backs up Production, updates the database, and then pushes the files up. The rsync command is invoked by hand so that we make sure someone is watching the promotion.