We are a small development team, at Harvest Digital, handling multiple tasks throughout the day, across different environments and projects. It makes for an exciting challenge. Our roles/ skills are clearly defined and our small size means we can react quickly to change, with little margin for communication errors and so on (see Getting Real and Less is more: Jumpstarting Productivity with Small Teams). But, when it comes to deploying to a staging or production server, I am ashamed to admit that we had often introduced a huge potential for human error by doing much of the work manually. Each project is different and so there is no consistent deployment process across the board.
Deployment is often the last step in the process to get any attention and it is one that can be unnecessarily tedious and prone to error. With more agile development projects, where deployments may be required several times a day, we obviously cannot afford the time nor the potential mistakes that may be made by manually deploying a project.
At its simplest level, deployment may just involve making sure that the target server (i.e. staging or production) has the latest revision of files from the project’s source control repository (we use SVN). But factor in automated tests and database migration and you can see how easily things can go wrong. Especially if you are deploying several times a day. You need to automate as many steps in the process as possible, thereby eliminating any manual tasks that introduce potential error and duplication.
Whenever we reach a point in a project where the code can be considered stable, we should tag it in SVN as a release. This gives you the ability to deploy a particular release based on its tag, instead of just the latest revision in the repository. By convention you never create revisions in the tag folder – tags are simply named snapshots of the source repository. We typically use version numbers as tags with some scheme based on feature-set or milestone and release date that can be ordered alpha-numerically e.g. “rel_belfast_2.04″. This allows us to say with certainty what is deployed at any one time, without having to scan logs etc. Tags give context to a release name (you can easily associate the release with project milestones) that revision numbers and timestamps do not. Tags are usually kept in a ‘tags’ subfolder, in the top level of the repository.
For a while now at Harvest, we’ve been working with symfony – an excellent PHP framework – that includes a few tools to help simplify the deployment process (such as Pake). These tools allow for remote syncronisation of files with rsync (the benefits of synchronisation over standard FTP are much touted elsewhere) via SSH (with the shell command: e.g. symfony sync staging) and semi-automate the build process (including database schema changes, data dumps etc: e.g. symfony propel-build-all myApp) by using Pake on the target machine.
But there is still a lot of room for improvement, particularly when it comes to database migrations and SVN integration. Plus, symfony is not our only set-up. We need an automated deployment process that can be applied across all our projects. This is where I’ve previously seen shell scripts being used but Phing can do much of this heavy lifting work for us, as it has many standard deployment tasks built-in to it. According to the Phing blurb:
Features include file transformations (e.g. token replacement, XSLT transformation, Smarty template transformations), file system operations, interactive build support, SQL execution, CVS operations, tools for creating PEAR packages, and much more.
Phing (PHing Is Not GNU make) is a project build system based on Apache Ant and is available through the PEAR installer. If you use --alldeps on Phing, it’ll grab, funnily enough, all the dependencies. But most are good packages (e.g. PHPUnit, PHPdoc and VersionControl_SVN). It can be used in a multitude of ways, including unit testing, creating docs, running SQL – which allows us to keep database schema changes in version control. The beauty of Phing is everything can be configured easily through the build.xml file (and then further with properties files) – so that the project’s deployment configuration can be kept in version control too.
In short, we love this thing called Phing!
For more detail on advanced tasks such as database migration take a look at these posts from Federico Cargnelutti and Dave Marshall.
