Continuous delivery extends continuous integration beyond building and testing into the act of releasing. The goal is to keep software in a state where it can always be deployed, so that putting a change into production is a routine, low-risk decision rather than a large, dangerous event. The practice was set out by Jez Humble and David Farley in their 2010 book “Continuous Delivery.”
On the practice’s own site, continuous delivery is defined as “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.” Each of those words matters: changes should move to users reliably, without the rush and breakage that comes from releasing infrequently in large batches.
The mechanism is an automated pipeline. Every change flows through a sequence of automated stages - build, automated tests, and progressively more production-like environments - and only changes that pass each stage are eligible to be released. Because the pipeline exercises the full path to production on every change, the team always knows whether the current code could be shipped, which removes much of the uncertainty from a release.
Continuous delivery builds directly on continuous integration: CI ensures that integrated code is built and tested continuously, and continuous delivery carries that verified code the rest of the way toward release. Together with infrastructure automation and monitoring, it is one of the technical practices that underpins the broader DevOps movement.