Michael Bolton sparked a fascinating discussion on Twitter by asking what exactly is the business value of Continuous Delivery? I’ve attempted to capture the conversation on Storify but I also want to explore the topic a little further.
Michael quite rightly pointed out that beyond CD being technically possible and cool, it is difficult to see the business value of the approach. I agree with him that there are practically no systems that could ever need to release new features every few minutes. In fact I can’t think of a single system which would require such frequent updates.
Despite this I believe that Continuous Delivery can provide value to the business.
Let’s step back for a moment and consider what ‘Business value’ actually means. It obviously means ‘providing something of value to the business’. Usually this ‘something’ will be a new feature or maybe a bug fix. Being able to release frequently could certainly get either one of those out to the business, but CD is only one possible solution to this problem. Even more important that releasing frequently is releasing reliably.
Almost every business wants to know exactly when a feature will be useable by real users. Releases require code to have been written and tested. Deploy scripts need to be reliable. Code needs to be packaged for release. Release documents, notes, maybe even marketing materials need to be produced. It seems logical to think that with so many parts to a release, and most likely the need for multiple people or even teams to be involved, you should release as infrequently as possible to reduce impact. In reality the more infrequently you perform an action the more likely you are to make a mistake.
The more frequently you practice a series if actions the more natural they feel.
Painful systems requiring workarounds or insider knowledge are often accepted if the user only has to feel the pain once in a blue moon. Bringing the pain forwards is really the only way to motivate people to fix these issues.
Simon Stewart responded to Michael Bolton’s initial Tweet questioning the business value of CD with the benefit of cleaner code. To be successful at CD you will need to learn how to be disciplined about writing and maintaining code. Developers need to be adding automated checks, and builds will need to be manged. My experience of adopting CD showed that having a goal that the developers were excited to achieve could be be a great motivator to get people fixing test environments, taking responsibility for quality, and maintaining automated checks. Obviously there are others ways that you could achieve these benefits but it would be foolish to dismiss the impact that CD can have on a development team.
Maybe the value of CD only starts to appear when you have multiple development teams contributing to a single code base. With a single developer and a single codebase the thought of releasing multiple times a day points to poorly written and tested code being endlessly thrust upon the user. If you consider a CD approach for multiple small development teams working on a shared codebase then you can see that if you do 3 releases in a day you are not necessarily saying that each developer released in that day. In fact at Songkick our release problems increased as the development team grew. Each developer was spending around 1-3 days on building and testing new features but this alongside regular bug fixing and technical improvements meant we were exceeding our release capabilities.
We could see that creating a process that allowed developers to commit code freely and receive fast feedback would be a huge improvement. Once we had made the necessarily cultural and technical changes to our process, attitude, and environments, we realised that with just a few additional changes we could ship our code directly to production without increasing the risk beyond our comfort zone. Taking this final step was hugely motivating for the development team; we wanted to create an environment where everyone has access to the information they need, can make decisions based on their expertise, and has access to support when they want it. At Songkick we did this by giving all developers the freedom to ship code whenever they were ready.
Unfortunately it seems rare for a team to sit down and define their release process, instead they rely on some process which evolves over time to handle new tools or respond to problems. Business value can only be achieved if you have code that actually makes it to the hands of your users. Being able to release the code to production in minutes doesn’t remove the need to define, design, build, and test changes but it can help you to develop a reliable release process.
I consider CD to be a technical solution to the problem of release delays. As with all releases there is likely to be some impact to the user, consider what this means and then plan accordingly.
Look at the risks of every release and identify actions to monitor or mitigate them. CD gives you a hugely flexible release process, you have the means to release quickly and frequently, but you also have the choice over whether you use it.