Tips On Continuous Delivery

Last week I attended a talk by Rob Harrop at SkillsMatter on the topic of continuous delivery. The video is here.

Continuous delivery is all about setting up your development processes such that you can deliver into production much more frequently than is typical, perhaps with multiple releases per day.

This is a topic I have been interested in for a long while, having worked on projects with very long release cycles in the past.

There is a lot being written about continuous delivery and I have read a lot of it, but usually the same companies are held up as examples of the practice: Facebook, Twitter, LinkedIn and Flickr, the trendy consumer web companies. With that said, I was really interested in hearing more about how it was being done in the real world in a smaller company.

I took away these points from the presentation.

People and process come before tools

There is a lot of talk about tools such as the cloud, platform as a service, Puppet and virtualisation in this conversation. These tools can save you time, but much more important is getting the team in line such that the good people are trusted and empowered to do it.

Ruby as glue

Rob and his company have clearly come around to the idea of Ruby as a tool to manage their infrastructure and continuous deployments. The Ruby community has generated some very high quality testing tools such as Rake, RSpec and Cucumber which are elegant and efficient for carrying out continuous deployments. Ruby is also great, elegant scripting and glue code for building continuous delivery infrastructure.

Virtualisation

Virtualisation and cloud are key to all of this, and tools such as Vagrant and Chef can help to bring up environments quickly and release software in a repeatable and scalable way. Do not be afraid to bend virtualisation to your own needs, as some of the literature out there is quite prescriptive.

REST and service oriented architecture

A service based model has helped with continuous deployment goals, as it means they can keep the whole architecture loosely coupled and deploy and rollback components quickly and independently. REST and a service oriented approach can be a real boon for continuous deployment.

Minimise branching

Most changes and features are small enough that it is not worth building separate feature branches. Heavy branching is slightly orthogonal to continuous delivery, as it keeps work and changes off the deployed mainline.

Look after your artifacts

Be careful with code artifacts such as JARs and Ruby dependencies. Once we have tested something, we need to make sure those same artifacts move through the testing and deployment pipeline in a locked down and repeatable way.

Design for deployment

It helps if you can architect for continuous delivery by allowing for some form of canary release or blue green deployment so that we can deploy without impacting the codebase. Considerations such as avoiding server side session state can help here.

It is clear that getting to the point of being able to do continuous delivery reliably implies huge change for the average development team: processes, people, code quality and quality control. However, it is equally clear that Rob's startup is benefiting from continuous delivery and have demonstrated to their business that it was worth the investment.

If you want the wider view, read my agile reading list or metrics driven development. My CI tools note covers the first piece of infrastructure most teams need.