Want to succeed in a digital world? You’re going to need agility, agility, and more agility – and that means building your business on an agile infrastructure and using agile software methodologies that include continuous delivery (CD), a technique designed to infuse users’ input and experience.
CD extends the automated testing used in continuous integration (CI) all the way into production environments, where feedback can be captured directly from users. It relies on an automated infrastructure that provides on-demand capacity and API-based integration.
CI is typically implemented as a pipeline where committed code runs through automated unit and integration tests.
CD allows code that passes CI tests to be deployed directly into production. It’s important to note that there’s a deliberate process break so decisions can be made about which version — and hence which features — will be deployed into production. This differs from continuous deployment, where code that passes tests is automatically deployed into production without human intervention.
Large enterprises, particularly those that are regulated, tend to prefer continuous delivery over continuous deployment because the act of deciding which versions to promote into production aligns well with segregation of duties, change management practices, and a general sense of being in control. Continuous deployment is more favoured by consumer internet companies seeking to optimize the speed of their feedback loop regarding new features.
DevOps needs continuous delivery
CI pipelines can be built entirely by development teams. But this can lead to the phenomenon known as deploy to shelf, where engineers complete multiple sprints without their code ever being deployed into production, thus denying themselves of the user feedback that’s essential to proper agile development. If developers do two-week sprints, and operations does quarterly releases (13 weeks), then six or seven sprints will stack up before getting any user feedback.
By extending a CI pipeline into production, it becomes a CD pipeline and crosses the traditional divide between Dev and Ops, and the decisions about which versions get deployed to production happen at the border. The pipeline extension may rely on the same tools as CI, such as Jenkins, or on tools specifically built for CD, such as Spinnaker.
Continuous delivery needs automated infrastructure
- Capacity on demand – Integration tests are, by their very nature, transient. An environment is spun up to verify something works or fails, and then its work is done. Such activity naturally lends itself to parallelisation, where it’s possible to get quick feedback and queuing as needed, so the maximum number of tests can be run on a minimum-resource footprint.
- API-based consumption – APIs connect pipelines to infrastructure. Without them, there are more process breaks, slower flows through pipelines and an overall lack of automation. So-called ticket clouds, where a request for resources becomes a queued ticket requiring action by a human operator, quickly get overwhelmed by the throughput of even a relatively trivial CD pipeline.
Is CD worth the effort?
As organizations advance their DevOps initiatives and consider CD, they may ask whether it provides the necessary resources to ensure that the code being developed is ready to deploy. Does it slow development times because of the need to ensure code is deployable? And is the customer feedback on deployed software worth the effort?
We believe organizations need CD capabilities to be truly agile so, yes, CD is worth the effort. Digital business demands agility at three levels — how the business responds to customer needs, how software is built to meet those needs, and how infrastructure is made available to run that software. CD pipelines let modern organisations connect customer needs to their infrastructure, and that infrastructure must be automated to provide sufficient flow through the CD pipeline.