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.
blog.phpdev 
I wrote up a piece about my own bash script that I use to SVN export to the site I’ve been paid to develop over the last couple of years. A couple of other use-of-svn posts are also linked from there.
http://topbit.co.uk/serendipity/archives/1-svn-checkouts-vs-exports-for-live-versions.html
There’s also a mention there about how I swap between a dev/staging version and the live site by setting the document root to a path that is actually partly a symlink, which can get pointed to a different base directory.
LikeLike
I wonder, does anyone beside me worry about the fact the while any copy the files one at time technology is updating the site there is a distinct possibility that the code can be in an inconsistent state. Say for example, to fix one problem you had to modify one existing file to make it call a new class you wrote. You have copies the updated file but the new class is in a different directory that is not copied yet. A request hits your site and boom. Probably not a big problem for any low volume site as it’s a race condition but that depends a lot of load and location. I guess ti sort of assume you don’t bring the site down to do the update but if your servers need tostay up 24×7 ….Just wondering what other people think….
LikeLike
Is SVN the only VCS that you’ve looked at upgrading to? Why not git, bazaar or mercurial?
LikeLike
@david Really, there’s two reasons we’re planning on svn:
1) Its what we, as admins, know
2) There’s a low cross-over with cvs for the developers (almost no retraining)
I’ve looked into git before and it looks pretty slick, but I can’t say I’ve really seen the other two.
LikeLike
@kent Sure, there’s the possibility but more often than not, what I’ve seen is a PHP error when that sort of thing happens, not an issue with partial code being executed. Usually the deployment (if it’s a good process) takes seconds to get new releases pushed out. If you’re doing it by hand – copy&paste or something like a manual FTP – you’re doing it wrong 🙂
LikeLike
We use an own PEAR channel and distribute our web sites using pear. Upgrading, downgrading, post install (db update) scripts are no problem.
LikeLike
I’m suprised the PEAR installer didn’t get a mention – afterall, there is a very complete book, by Greg Beaver, written on the subject.
LikeLike
I worked at a place that had a very slick method for RPM installation. they had an ./update that just ran in place, grabbed the latest rpms and installed, fully automated. Worked fantastically, but obviously depending on your release timelines, build patterns, and source type this is likely not for most people.
LikeLike
@kent – I’m with you, and for my mind,, that can be an issue, hence the script I linked to above to that will export a new copy of the site, and only after it’s ready to be put online does it get put into somewhere Apache could see it.
It’s also got the advantage that as I put it into a staging area for a quick look-around first, it’s building some caches as I click – both APC, and in that particular case, Smarty compiling the templates, so that when it is put live, they are already at least warmed up.
LikeLike