In my blog about DevOps, I couldn’t help but mention the associated “buzzwords” Continuous Delivery.
When a powerful idea like Continuous Delivery graduates into a buzzword, there are downsides. A buzzword’s popularity will often make it prone to misuse for example people indiscriminately tagging arguments/ideas with the word to create credibility irrespective of whether it is actually appropriate. Often the original buzzword meaning is poorly understood or gets overloaded enough to cut casual abuser enough ambiguity to proliferate the problem (and maybe lead people astray / advance their evil conquest).
Obviously damage is done when bad arguments/ideas gain traction on account of the strength of the misapplied buzzword. There can also be irony when a bad argument/idea is actually in contradiction to the original meaning. But the worst part is the dilution / loss of the original great idea.
A couple of recent bad cases of buzzword abuse I’ve heard against Continuous Delivery have motivated me to write this in defence.
Continuous Delivery is a real practice applicable to anyone who wants their software releases to be one of more of:
- Predictable / low risk
I personally think it’s relevant to EVERYONE.
Continuous Delivery as a capability in an organisation means that any new change to code or configuration is capable of being fully tested to the extent that it can promoted into live service with just one single manual step: the act of clicking “do the production deployment”.
This means after code or configuration is committed to version control the whole remainder of the software delivery life-cycle… compilation, packaging, unit testing, functional testing, performance testing, security testing, user acceptance testing, operational acceptance testing etc, and all dependent code, configuration and data deployments required to non-production environments …must be automated!
Obviously tools and automation are only one part of the complex full equation and the devastating effect of people on actual outcomes can be dramatic. Martin Fowler provides an elegant definition of whether you are actually achieving the desired intentions here.
Naturally there is one step beyond this where the production deployment is also automated. Generally this is called Continuous Deployment although I prefer the more explicit “Continuous Deployment to Production”. The act of promoting code to non-Production environments is usually also called a deployment and continuously deploying to lower test environments is essential to achieving Continuous Delivery.
Continuous Delivery as a capability is an extremely powerful goal, but sadly so far off the way many organisations currently operate that they are put off altogether. This is even more likely if the distinction of Continuous Delivery versus Continuous Deployment to Production is not understood.
Don’t be scared by the Continuous Delivery capability, instead do the practice!
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 the 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 (full version not the Slight Return 😉 ) with authentic dexterity and feeling, but it doesn’t stop them tangibly improving their playing whilst they try (and having a lot fun). Likewise, every step towards Continuous Delivery is valuable to the organisation 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 organisation.
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 and something I hope to write about soon.
In summary, don’t be blinded by the ambitious end capability. If you aren’t already doing it, start thinking about adopting the Continuous Delivery practice TODAY!