I have been suffering from a major case of blogger's block, so I reached out to the lucky people who follow me on Twitter to ask them about some topics to talk about on the blog. Thanks to them I've got at least two blog posts coming. Credit to this one goes to Neil Crookes (who I met at the first CakeFest conference in Orlando) who suggested I talk about deployment issues
What's that you are saying? You thought I was using Capistrano to do deployments at work? Gentle reader, things change. All my work in trying to automate deployments is designed to allow me to do a deployment either from my own laptop or remotely on the server where it's run. Tools like Capistrano and Phing let me do that. Sure, I could cobble together my own solution using rsync or shell scripts, but my experience telecommuting has taught me that if you want others to use your tools, they have to be tools that can be used by others.
While Capistrano is certainly up to the task of deploying my own personal projects, I had nothing but problems getting people OTHER than myself to get it up and running. You wouldn't think that getting Ruby and then assorted gems installed on a non-Windows machine would be that hard. Apparently it is. So what was my alternate solution? Create something that can be run on the server where the code is going to be deployed.
As a guy who is always up to his neck in the devops environment (with a tip of the hat to Brian Moon for bringing this term to my attention) I am determined to NOT be the only one who can do deployments. It's 2010, the year we make contact, and there is no reason that my boss, when he alters some marketing copy on our main web site, should not be able to push those changes himself (with the side-effect being leaving me out of it). With a little work and some digging, I got Phing to do it for me.
Like many awesome tools with lots of documentation, Phing suffers from a lack of easy-to-find tutorials covering the exact things I wanted to do. Or sure, I eventually tracked it all down (with the help of the best support group in the world, Twitter) but I'm guessing this a trend that will not go away.
So, being the lazy sort, I set out to duplicate how Capistrano does their deploys:
- Check out the latest version of code from HEAD on your repo (SVN in this case)
- Create a new "current" directory
- Symlink the latest checkout (which is in release/yyyymmddhhmmss) to current
Why the symlink method? Capistrano allows you to also rollback to a previous deployment, but I haven't gotten around to implementing that feature with the new Phing-based setup. I never make mistakes that need to be rolled back like that. Yes, I'm kidding.
So, what would a build script to cover the basics look like?
< ?xml version="1.0"?>
So, after you install Phing then to run things you just need to type 'phing -f
So what else do I do when I deploy? There is always some clean-up work to be done after the fact, so I add a few more actions to the file:
So, sometimes you are lazy and don't want to mess around with symlinks and figuring out how to roll things backwards. Here's how you could do a deployment using Phing that simply updates a directory that you checked out using SVN already:
< ?xml version="1.0"?>