I’m back with the fourth part of my look at deployment of PHP applications to focus on the actual deployment technologies. I’ve already talked some about version control, build tools and unit testing in the previous parts of the series and this new information should round it out nicely with a simple approach to the push part of the deployment.
As it stands right now, the final step in our deployment is one of the simplest. We have some bash scripts that are aliased to rsync commands for pushing files out to each of our different sites. Since the assumption is that anything that’s in the QA/staging area is good to go, the rsync commands take everything that’s out on production and, if there’s any differences, overwrites the remote version. It’s light, simple and makes it easy to push out an entire site in one go. Things can get a bit tricky of you only want to deploy a portion of the site at a time though. There haven’t been many cases where we needed to do this, but it would have been nice to have a way to break it up a bit more.
I posted two TwtPolls in the past few days asking some of the other developers in the community (some outside of PHP too) about which method they preferred for deploying their sites out to a production server. Here’s the results of the latest poll (hopefully it’ll stick around for a while – I’ll mention the numbers too, just in case).
There were 45 votes total on ten different options…here’s how it came out:
|FTP/SFTP||[ 20% (9 votes) ]|
|SSH/SCP||[ 4% (2 votes) ]|
|RSYNC||[ 9% (4 votes) ]|
|SVN (via ssh or export)||[ 49% (22 votes) ]|
|Capistrano||[ 7% (3 votes) ]|
|Ant||[ 2% (1 votes) ]|
|Cut & Paste||[ 2% (1 votes) ]|
|Other Manual Process||[ 2% (1 votes) ]|
|Other Automatic Process||[ 2% (1 votes) ]|
|A mashup of several||[ 2% (1 votes) ]|
As you can see rsync, our current choice, only came in third under FTP/SFTP and the overwhelming favorite, Subversion deployment. Some of them choose to make the copy of the code on the production server a checkout of the current version (svn up when it needs refreshing) and some export from their current version and push those files out. Unfortunately, we’re still stuck with CVS for the time being (coming soon, hopefully!) so working with branching, tagging and all should be quite a bit easier.
This final step can either be a manual one (how we do it now) or as a part of another process (how I want to do it). I currently have a final step in my Phing build file that, if all goes well during the build, will call one of our bash scripts to push the code directly from there. This helps to keep things nice and tidy and makes it a simple “single process” tool that sysadmins or QA folks can use to ship out the code that’s been cleared for public consumption.
Now that I’ve gotten to the end of the descriptions on all of this stuff, let’s head back to the beginning and look at some of the actual code, configurations and technologies related to deployment. I’ve seen some good suggestions as to a step I’ve been missing – optimization. Keep an eye out for this first in the “Deployment Tech” series, a continuation of this general look at deployment of PHP applications.