Continuous delivery: What it is, and why it matters
Continuous delivery (CD) "is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely, and quickly in a sustainable way."
This definition comes from the website ContinuousDelivery.com, maintained by CD gurus Jez Humble and Dave Farley, co-authors of a 2010 book about the subject, called Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.
The concept sounds simple. After all, any developer can push changes to production and patch them later. But here's what you need to know about CD, and why it matters for modern software development.
Key elements of continuous delivery
CD always has certain elements, most of which contribute in some way to the essential ingredient, speed.
It's automatic
If the pipeline from commit to production is automatic—that is, if everything in the code that passes testing is promoted to production—that is CD. It is possible for a delivery pipeline to have manual steps and still be CD; the steps just need to be quick, safe, and sustainable regardless of whether they're manual or automatic.
It delivers code quickly
This includes both the pieces themselves and the entire delivery pipeline. Development in separate branches for weeks, or even days, with integration at the end, is just not possible. Teams pursuing CD need to learn to slice stories thin, typically taking less than a day of work to develop.
Once the code is created, the build/test process typically needs to run in under an hour; the deploy process should be push-button. Organizations that require "change control" approval, a ticket request, and a physical stop/start of the server to complete the build/test process may find that their initial challenge lies in building the infrastructure to make CD possible.
The simplest way to go fast is to let the programmers have the keys to production. With traditional development, that might not be safe. You can think of traditional development as injecting the defects into the process, finding them in test, and removing them later. With CD, there simply is no time for that.
It builds and tests code safely
DevOps provides teams with many ways to reduce the risk of deployments. Staged deployments and canary releases both expose a smaller set of users, while blue-green deployments offer the ability to perform quick rollbacks.
Continuous monitoring, combined with configuration flags or rollback, is another way to reduce the impact of a problem in production. CD teams often use a highly separated architecture, such as microservices, to make sure that a problem can affect only one service or feature at a time. That greatly reduces the chance of spill-over and all but eliminates the need for regression testing.
The book Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations—discusses this issue in great detail. It reviews some of the relevant DevOps survey data and concludes that high-functioning DevOps teams not only put code out quickly, but they do so with fewer regression defects.
That means traditional teams are doing a lot more testing. They need to, because they are creating more bugs.
It's sustainable
All the processes used in CD need to reinforce each other. For example, to allow fast deployment, you need other techniques to reduce risk or impact. These techniques minimize common pain points such as merging, production deploys, and firefighting when things go wrong.
In his talk on sustainability at the 2019 DevOps Conference in Germany, Manuel Pais mentioned four elements of sustainable continuous delivery: The system must have high availability (low downtime), be scalable (the pipelines cannot be backlogged), be monitored continuously for problems, and be recoverable, with a low mean time to recovery.
Why CD matters
Working quickly, safely, and sustainably helps build a system that can enable rapid change.
Ron Jeffries, co-author of "The Agile Manifesto," calls running tested features (RTF) a core metric for agility. (Jeffries defines RTF as "software that works, and that has the most features possible per dollar of investment.")
With CD, a team of 10 developers might deliver 5 to 10 working micro-features per day. Compare that to a Scrum team, working at the same velocity, that delivers the same value in two weeks.
Nine days into the sprint, the Scrum team has delivered nothing. Assuming five delivery units per day, the CD team has delivered 225 units in those nine days.
Beyond the release, consider how long a bug lives in production. In the CD model, if the bug is important, it can likely be found and fixed the same day, perhaps the same hour. In the Scrum model, if the minor bug in Sprint 1 is found on Day 2 of Sprint 2, it will be put on the backlog. The bug will be fixed in Sprint 3 and deployed at the end of Sprint 3.
Assuming a two-week sprint, it is nearly a month from the time the bug arrives in production until it is removed. With quarterly releases, that is nearly three months later.
Finally, there's the value of picking the right features.
Scrum makes it possible to create an experiment and validate the feature in two weeks, but CD allows the team to conduct a dozen experiments, or micro-features, and pick the most promising two or three in a day or two. That way you build the more valuable features and have fewer (or zero) duds.
Why you should get started now
Teams that can perform true CD will find they can create features more quickly, run more experiments more safely, and reduce or eliminate whole-system regression testing, all while improving reliability.
Special thanks to Peter Walen for his review of this article, and his insights into continuous delivery.