{"id":603,"date":"2011-02-13T20:48:26","date_gmt":"2011-02-13T20:48:26","guid":{"rendered":"http:\/\/fragile.org.uk\/?p=603"},"modified":"2011-02-13T20:48:26","modified_gmt":"2011-02-13T20:48:26","slug":"in-praise-of-continuous-deployment","status":"publish","type":"post","link":"https:\/\/fragile.org.uk\/index.php\/2011\/02\/13\/in-praise-of-continuous-deployment\/","title":{"rendered":"In Praise of Continuous Deployment"},"content":{"rendered":"
\n
It doesn’t matter if you get there, every step along the way is an improvement.<\/div>\n<\/blockquote>\n
Me, praising Continuous Deployment<\/div>\n

\nEver since coming across the idea on Eric Ries\u2019s blog<\/a> I\u2019ve always been a big fan of Continuous Deployment<\/a>. For those unfamiliar with the term, it means writing your code, testing frameworks and monitoring systems in such a way that it is possible to completely automate the process of going from source control commit to deployment to a live system without posing a quality melt down. This means teams can find themselves deploying 50 times a day as a matter of course.<\/p>\n

Yeah<\/a><\/p>\n

It\u2019s not without it\u2019s critics<\/a>, and a lot of people see this as one way ticket to putting out poorly tested buggy code. I think that those folk completely miss the point and that in many scenarios in fact the opposite is true. The thing I really like though, is that, whether or you ever get to the point of automatically deploying every commit to live, every step that you might take to get there is hugely positive.<\/p>\n

So, really, what would have to happen in order to employ a Continuous Deployment regime?<\/p>\n

18 months ago my then team started to take this idea more seriously, I thought it would be interesting to give an overview of the steps taken towards Continuous Deployment, and since we’re certainly not there yet, what we plan to do in the future.<\/p>\n

We started from a point where we would release to live environment every few weeks. Deployments, including pre and post deploy testing could take two people half a day sometimes more.\u00a0I should also say that we are dealing with machine to machine SaaS systems where the expectation is that the service is always<\/em> available.<\/p>\n

Reduce manual deployment load<\/h2>\n

Our first efforts aimed to reduce the human load on deployment through automation. Fear<\/a> meant that we still needed to ssh into every node to restart but every other step was taken care of. This meant that it eventually became common place to deploy multiple times a week across multiple platforms.<\/p>\n

Improve system test coverage<\/h2>\n

Once a deploy was live we were still spending considerable time on behaviour verification. To address this we worked to improve our system and load testing capability.\u00a0Doing so meant that we had more time to manually verify deploy specific behaviour, safe in the knowledge that the general behaviour was covered by the tester.<\/p>\n

Improve system monitoring<\/h2>\n

This approach also requires a high level of trust in system monitoring. We have our own in house monitoring system whose capabilities we expanded during this period. In particular, we improved our expression language to better state what constituted erroneous behaviour and we also worked on\u00a0better long term trend analysis, taking inspiration from this paper <\/a>. It\u2019s no surprise to me that it came out of IMVU<\/a> who have been practicing Continuous Deployment for a long time.<\/p>\n

Reduce deploy size<\/h2>\n

Since the act of deployment was now much less expensive we looked to reduce the number of changes that went out in each deploy. At first this felt false, after all if the user can’t use the feature in it’s entirety, what’s the point? We soon realised that smaller chunks were easier to verify and sped us up over time. We took an approach that I’ve since heard referred to as \u2018experiments\u2019 so that new functionality could be deployed live but was hidden from regular users. It meant that we could demo new functionality in production, without disrupting the business as usual service.<\/p>\n

Embrace lean inspired methodology<\/h2>\n

Breaking down deploys into a few day\u2019s worth of work also improved our lead time meaning that we could more responsive in the event of a change of plan. It was during this period that we switched from time boxing to Kanban<\/a>. This is interesting since Continuous Deployment is often championed by the lean startup movement<\/a>.<\/p>\n

The future<\/h2>\n

More recently, actively pursuing Continuous Deployment has taken a back seat, but the next logical steps could be to further flesh out the system test coverage and then look to completely automate deployment to the staging environment (modulo database changes).<\/p>\n

However, it doesn\u2019t really matter what we do next, if it takes us a step closer to theoretically being able to deploy continuously it will undoubtedly improve our existing lead time and responsiveness.<\/p>\n

This post contains a number of Continuous Deployment resources, but a few further articles I found to be interesting follow include:-<\/p>\n