So we just launched our new site. I figured this was as good a time as any to finally get our ducks in a row vis-a-vis continous deployment. Since this is the sort of thing that a lot of people have to deal with, I figured I'd publish a blog post explaining how we took care of it.

Continuous Integration

isotope|eleven uses Jenkins for our continous integration server. We have it configured to run the relevant tests anytime a commit is pushed to our git repositories, as well as once daily for each job. We keep the Jenkins Wallboard running on our main conference room TV at all times, so we can see at a glance if any builds are failing. These are all fairly standard practices.

Continuous Deployment

Jenkins is pretty flexible, and so when it came time to do continous deployment I decided to use Jenkins to handle it. In Jenkins, it's very easy to make a job that just executes some shell script (in fact, most of our jobs are precisely this sort). This is perfect, because of course we just have a shell script we use to deploy our projects - capistrano!

Setting up the deploy job

To get started, I built a new job in Jenkins. The repository our site lives in is called isotope-rails3, as is the main CI job for our site, so the new job is called isotope-rails3-deploy. I set its git repository URL to our repo. I then added a single build step, an "Execute Shell" step whose command is cap deploy:migrations

Finally, I set it to notify me in the event of a failure.

Setting up deploy without intervention

At this point, I can click the 'Build Now' button to kick off the deploy, but it's going to complain about passwords. I also had to set up the jenkins user on the jenkins server to be able to deploy our site passwordless. If you don't know how to do this, this is a pretty good tutorial on setting up your SSH authorized keys.

So now the button works and it will deploy without intervention, but I want to kick off this job after a successful run of our tests so that it will deploy each time we push new code to the deploy branch. To manage this, I just went into our main CI job for the repo and set it to 'Build other projects' in the Post-build Actions, and I told it to build the 'isotope-rails3-deploy' job only if the build succeeded.

Done! Get your Continous Deploy on.

With those simple steps, you've got a robust Continuous Deployment server that can be modified in a host of useful ways, as it's just a standard Jenkins job. Let me know if you try this and have any problems. Thanks!

Josh Adams is a developer and architect with over eleven years of professional experience building production-quality software and managing projects. Josh is isotope|eleven's lead architect, and is responsible for overseeing architectural decisions and translating customer requirements into working software. Josh graduated from the University of Alabama at Birmingham (UAB) with Bachelor of Science degrees in both Mathematics and Philosophy. He also occasionally provides Technical Review for Apress Publishing, specifically regarding Arduino microprocessors. When he's not working, Josh enjoys spending time with his family. <a href="http://www.erlang-factory.com/conference/show/conference-6/home/"><img src="http://www.erlang-factory.com/static/upload/media/1389191028314604speaker120x125gif" alt="speaker badge" /></a>