In our book, Dave and I focussed mainly on the principles and technical practices of continuous delivery and its ecosystem: things like automated testing, managing configuration, environments, and data, and implementing a deployment pipeline. One of the things we didn’t spend much time on was the business context and value proposition of continuous delivery. In a way that’s just as well, because the book is already long enough.
However this context is important – and not just because it helps you convince your boss to implement continuous delivery. One of the big technical memes of the last year has been continuous deployment – the practice of releasing every good version of your software, often multiple times a day. But that practice came out of a business imperative, which finds its general expression in the lean startup movement. In startups, it’s essential to get a minimum viable product available to users and then iterate rapidly based on real feedback. Sometimes you need to change direction in a more radical way (known as pivoting) if you discover what you built isn’t valuable.
When building strategic (as opposed to utility) software in a non-startup environment, many of the same imperatives apply. Furthermore, continuous delivery has other important benefits: for example, it reduces the risk of each individual release substantially, and provides a true measure of project progress.
I’ve found myself talking a lot about the value proposition of continuous delivery since I wrote the book, so I thought it would be useful to write it all down. You can get hold of my essay here on InformIT for free. InformIT have also made chapter 5 of my book – which explains the deployment pipeline in some detail – available free of charge too.