Skip to main content Skip to Footer


January 27, 2016
Don’t be scared by the continuous delivery capability, instead do the practice
By: Mark Rendell

In this blog, I thought I would take a step back and do some level-setting on Continuous Delivery.

Continuous Delivery as a practice is the act of pro-actively evolving your software development and release processes towards the ultimate target of achieving the Continuous Delivery capability.  This doesn’t just mean creating isolated bits of automation (some of which you hopefully already have); it means orchestrating all your automated tasks into a workflow capable of getting as close to implementing “the capability” as your automated tasks will permit. This delivers value.

Think about it like a new guitar player trying to learn Jimi Hendrix.  They know realistically it is going to take a long time to nail Voodoo Chile with authentic dexterity and feeling, but it doesn’t stop them tangibly improving their playing while they try (and have a lot fun too).  Likewise, every step towards Continuous Delivery is valuable to the organization as a whole (and to the people involved).

A very early step towards achieving a Continuous Delivery capability, is to properly sort out version control of your code and configuration.  If these are not adequately controlled, there is no real hope of a change even triggering a code build, let alone the following chain of automated quality assurance processes. Even if you just do this, you will no doubt have improved productivity and predictability in your organization.

Another early staple is to have commits to the version control repository automatically trigger code builds, static code analysis and unit testing. This practice pre-dates Continuous Delivery and is usually called Continuous Integration.  Again, this is extremely valuable in its own right.

This sequence of automated processes and quality gates was to my knowledge first described as a Deployment Production Line in this paper which argues ‘why stop at Continuous Integration’ and ‘why stop at application and configuration when you can consider infrastructure as well’.  Both great arguments.  It then went on to be described as Deployment Pipeline in this excellent book (by Humble and Farley).

As you stick to the Continuous Delivery practice and the Deployment Pipeline matures you will expect to see greater throughput of change, granted not yet all the way to production, but still extremely valuable.  Building your Deployment Pipeline is a key element of the practice.

In summary, don’t be blinded by the ambitious end capability.  If you are not already doing it, start thinking about adopting the Continuous Delivery practice today!

Popular Tags

    More blogs on this topic


        Industry & topics highlighted