Continuous Deployment Setup at 2morethin.gs

I’ve set up continuous deployment for 2morethin.gs. Continuous deployment means that as soon as a developer finishes work, his code is pushed to the website. IMVU does it, as does WordPress.com and kaChing. This post should show you that there is no magic in continuous deployment, everyone can do it.

Why would one want to drop releases and do continuous deployments? The main benefit is that your time to market goes down drastically. Usually your time to market from idea to customer is weeks or often months. With continuous deployment it can go down to 30 minutes. This will enable your company to experiment more, take higher risks because you can change your decision in 30 minutes.

Continuous deployment setup diagram 2morethin.gs

The setup is quite easy and involves a HAProxy balancer, two Tomcats, some shell scripts, cron and Mercurial. It’s very alpha but works. I develop locally – a benefit of a distributed SCM – and when I’m done I push to the central repository. There a hook executes and writes a flagging file to /tmp. Each minute a cron job runs, checks for the file and if it’s there removes it and does a deployment. The deployment script is rather simple, it goes through the tomcats, stops each one, deploys the application and then restarts the tomcat. The HAProxy load balancer takes care of sending requests to the tomcat which is currently up, so the site does not go down during deployments.

Obviously missing currently is a test stage and roll backs if deployment on one tomcat went wrong, feedback is appreciated, leave a comment.

As continuous deployment involves a different thinking on the part of developers, testers, operators or devops, it’s better to start early with continuous deployment than later. So if you’re running a startup, do yourself a favor and use it right now.

Comments are closed.