Continuous delivery
Continuous delivery is the engineering practice of keeping software in a releasable state at all times, so that every change that passes the automated pipeline can be deployed to production at any moment by a business decision. It differs from continuous deployment, where every passing change is released automatically with no decision, and from continuous integration, which only guarantees that the change builds and passes its tests.
The longer version
The practice rests on a pipeline that takes each change from commit to a production-shaped environment on its own: build once, run the unit and integration suites, deploy the same artefact to a test environment, run the acceptance and smoke tests there, and stop with the artefact ready. Every stage is a quality gate, and a failure at any gate stops the change and tells the author. Because the artefact that reaches staging is the one that would reach production, the deployment has been rehearsed by the time anyone decides to release. What remains manual is the decision, and a product owner can take it.
Continuous integration is the foundation: developers merge small changes to the main branch at least daily and an automated build verifies each one, so integration problems surface in hours instead of at the end of a phase. Continuous delivery extends the pipeline past the build to a deployable artefact and a rehearsed deployment. Continuous deployment removes the final human decision, so every change that passes the pipeline reaches production by itself, and releasing a feature is then separated from deploying it by a feature flag.
A pipeline that deploys to a staging environment that has drifted from production proves the wrong thing, and the change that passed every gate fails on the real database version. A suite that is slow or flaky trains the team to re-run it until it goes green, at which point the gates are decorative. The practice also fails organisationally when release management is still built for a monthly train, with a freeze and a manual sign-off the pipeline cannot see, so releasable software waits weeks and the batch that finally ships is large again.
Common questions
What is the difference between continuous delivery and continuous deployment?
Continuous delivery keeps every change releasable and leaves the decision to release to a person, who can ship at any time. Continuous deployment removes that decision: every change that passes the pipeline goes to production automatically. The first is a capability; the second is a policy built on it, and it needs feature flags so that deploying code and releasing a feature stay separate.
Is continuous delivery the same as continuous integration?
Continuous integration is the first half: small changes merged to the main branch daily and verified by an automated build. Continuous delivery adds the second half: the verified build is deployed to a production-shaped environment, tested there, and held ready to ship. A team can have continuous integration without continuous delivery; the reverse is not possible.
Do you still need QA with continuous delivery?
The role changes shape. Test cases that ran by hand once per release become automated gates that run per change, and the tester's time moves to exploratory testing on the staged build, to the acceptance tests the pipeline runs, and to the feedback arriving from production. What disappears is the manual regression pass before each release, and what remains is the judgement no gate can automate.
What does a continuous delivery pipeline consist of?
A build stage that compiles and packages the change once into an artefact; automated unit and integration tests against that artefact; deployment of the same artefact to a test environment shaped like production; acceptance, smoke and any performance tests run there; and a holding point where the artefact waits, verified, for the decision to release. Each boundary is a quality gate, and a failure stops the change and tells the author.
What does a team need before adopting continuous delivery?
Version control for everything that goes into a deployment, including configuration and database migrations; an automated test suite the team trusts enough to release on; a build that produces one artefact deployed unchanged to every environment; a staging environment that matches production; and a way to deploy and roll back without a hand-typed procedure. Missing any one of these, the pipeline produces releasable builds that nobody dares release.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.