Continuous DevOps: The difference between Continuous Delivery and Deployment
17 Oct 2018 - Aaron Dodd
Continuous Integration, Delivery, and Deployment sound like similar concepts and there is often confusion around the last two. Many in DevOps have a good understanding of CI, but what is the difference between Continuous Delivery and Deployment?
When we conducted a Yammer poll in our DevOps group at work and only about 50% answered correctly. If we deliver our code, isn’t that the same as deployed? Well, no, but you may have laid the groundwork for a Continuous Deployment process, and maybe even partially implemented one, without realizing it.
Stefana Muller, Founder of LI Women In Tech and VP at Opsani, breaks down these three concepts succinctly (emphasis added by me):
“Continuous Integration (CI) is a software engineering practice in which developers integrate code into a shared repository several times a day in order to obtain rapid feedback of that code. CI enables automated build and testing so that teams can rapidly work on a single project together.
“Continuous Delivery (CD) is a software engineering practice in which teams develop, build, test, and release software in short cycles. It depends on automation at every stage so that cycles can be both quick and reliable.
“Continuous Deployment is the process by which qualified changes in software code or architecture are deployed to production as soon as they are ready and without human intervention.”1
Another clarification comes from Carl Caum, Product Manager for Puppet:
“Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements … There are business cases in which IT must wait for a feature to go live, making continuous deployment impractical. While application feature toggles solve many of those cases, they don’t work in every case. The point is to decide whether continuous deployment is right for your company based on business needs.”2
Delivery is about keeping the code in a deployable state. The end goal of the Integration/Delivery pipeline is the creation of artefacts on a repository (S3 bucket, download server, etc.) where all included features have passed all unit tests and quality controls and are ready for deployment to production, even if they aren’t deployed at that moment.
For Delivery, automation around infrastructure provisioning/teardown and code deployment to nodes is in support of this goal. Delivery is where many organizations stop and DevOps still has the silo of “developers code, operations deploys.” The last push to production is manual. Even if the actual deployment execution is automated, the approval and initiation is not.
Continuous Deployment goes a step further. Production changes require a special level of trust and responsibility (hopefully!). Changes in code may also require changes in architecture. Key performance objectives cannot be negatively impacted. Therefore, the process and tooling needs to align to and automate the enterprise’s workflows for approvals, audits, and controls around this application. Qualified (approved) releases are then automatically deployed to production.
Foundationally, think of Integration, Delivery, and Deployment as a pyramid sitting atop development and building on each other to production (inspired by Anatoliy Okhotnikov, Head of Engineering at Softjourn Inc.1):
Functionally, a simplified process view would look like (borrowed from Atlassian and others3):
If Agile is supposed to accelerate time to market and improve product quality, then CI/CD/CD are the end-to-end framework extending this through to production (when feasible).
References and further reading: