Since I adjusted the focus of my subject matter on this blog over the past couple of weeks, one of the main subjects I’ve been talking about is continuous delivery. This is a term coined in a book by the same name. I’m attempting to summarize some of the concepts in the book, and putting an emphasis on how the practices described in it can be applied to development processes that are in trouble. I’ll also discuss specific technologies in the Microsoft and Ruby community that can be used to implement them.
If you really want to understand this concept, I can’t overemphasize the importance of reading the book. While I love blogs for finding a specific answer to a problem or getting a high level overview of a topic, if you are in a position to enact change in your project or organization it really pays to read the entire thing. It took me odd hours over a week to read and I purchased the Kindle version so I can highlight the important points and have it available to my mobile phone and browsers.
That being said, I want to use this post to dispel what continuous delivery is not, and why you would use it in the first place.
Continuous delivery is not
- Using a continuous integration server (Team Foundation Server, CruiseControl.NET, etc.)
- Using a deployment script
- Using tools from Microsoft or others to deploy your app into an environment
Rather, the simplest description I can think of for this concept is this.
“Continuous delivery is a set of guidelines and technologies that when employed fully, enable a project or organization to delivery quality software with new features in as short a time as possible.”
Continuous delivery is
- Requiring tasks to have a business case before they are acted upon
- Unifying all personnel related to software development (including operations) and making them all responsible for delivery
- Making it harder for personnel to cut corners on quality
- Using a software pattern known as a “delivery pipeline” to deliver software into production
- Delicate improvements to the process used for testing, configuration, and dependency management to eliminate releasing low quality software and make it easy to troubleshoot problems
I’ll continue to blog about this and I still encourage you to read the book, but one thing that really needs to be spelled out is why you would want to do this in the first place. There are several reasons I can think of that might not be immediately apparent unless you extract them out of the bounty of knowledge in the text.
Why continuously deliver software?
When personnel consider their work done but it is not available to users:
- That work costs money and effort to store and maintain, without providing any value.
- You are taking a risk that the market or technologies may change between when the work was originally desired and when it is actually available.
- Non-technical stakeholders on the project cannot verify that “completed” features actually work.
When you can reduce the time it takes to go from an idea to delivering it to your users:
- You get opportunities for feedback more often, and your organization appears more responsive to its customers.
- It increases confidence in delivering on innovation.
- It eliminates the need to maintain hotfix and minor revision branches since you can deliver fixes just as easily as part of your next release.
- It forces personnel to focus on quality and estimating effort that can be delivered, instead of maximum work units that look good on a schedule.
And lastly: when personnel must deliver their work to users before it can be considered done, it forces the organization to reduce the amount of new functionality they expect in each release; and to instead trade volume for quality and availability.