A few months ago, there was a surge of activity around the idea of continuous deployment (specifically, as it is practiced at IMVU). When some of us at Viget saw this, it got us thinking – maybe, as many of the commentors said, this wouldn’t be the best idea for a production application (though that is debatable), but it could do wonders for a staging environment. We decided to experiment with it on a couple of projects in that capacity, and so far it’s worked wonderfully. Here’s one of the ways we set it up.
Our project is stored in a git repository at Unfuddle. Our continuous integration server (running CruiseControl.rb) is hosted within Viget’s firewall. We’re enforcing 100% code coverage through vl_cruise_control, a simple plugin that our own Mark Cornick wrote some time ago. Our staging server is hosted at Viget, but is accessible from the outside.
The first step was finding the ccrb_cap_deployer plugin for CruiseControl and installing it (with a minor modification to have it run migrations when it deploys) on our CI server, in the .cruise/builder_plugins directory (not in lib/builder_plugins, in our case). Then, we updated the project cruise_config.rb file with the following lines:
project.cap_deployer.emails = ['firstname.lastname@example.org'] project.cap_deployer.stages = ['staging']
And really, that's all it took... well, there was also some setup around making sure the CI server could deploy to the staging server (SSH keys and whatnot), but that's specific to our arrangement.
So now, whenever we have a successful build (no test failures, 100% code coverage), that code is automatically pushed to our staging server for everyone to see. This makes it much easier for the project manager to review stories and run acceptance tests (and frees them both from having to run the application locally and from having to bug a developer to deploy it every time they want to test something). All in all, it's been a great experience, and I highly recommend this level of continuous deployment.