Understanding Continuous Delivery
Continuous Delivery, often shortened to CD, builds on Continuous Integration by carrying every verified change further down the pipeline. Instead of stopping once unit tests pass, the pipeline packages the change into a versioned, deployable artifact, for example a container image or a signed build, and pushes it through additional stages such as a staging environment, integration tests, and sometimes performance or security testing. The defining feature of Continuous Delivery is that production deployment remains a deliberate, manual decision, typically a single approval click, rather than something that happens automatically.
How It Differs from CI and Continuous Deployment
Continuous Integration ends at “the code builds and passes tests.” Continuous Delivery continues past that point to prove the change is release-ready, but it stops short of actually releasing it. Continuous Deployment goes one step further and removes the manual gate entirely, deploying every passing change straight to production. In short: CI verifies, Delivery prepares and gates, Deployment ships automatically. Many organizations use the term “CI/CD pipeline” loosely to cover all three, but the manual approval step is what specifically separates delivery from deployment.
Example Pipeline
A typical delivery pipeline in GitLab CI or Jenkins might look like: build the application, run unit tests, package a container image and push it to an artifact repository, deploy that exact image to a staging environment, run integration and smoke tests against staging, and then wait at a manual job for someone to approve production release. When approved, the same artifact that was tested in staging is promoted to production, rather than being rebuilt.
Why Teams Use It
- Releases become small and frequent instead of large and risky, since every change is already proven deployable.
- Business stakeholders retain control over release timing, which matters for regulated industries, marketing launches, or customer-visible changes.
- Rollback is simpler because each release is a small, well-tested increment rather than a large batch of unrelated changes.
- Lead time from commit to “ready to ship” shrinks dramatically, which is one of the four DORA metrics used to measure delivery performance.
Trade-offs and Requirements
Continuous Delivery demands environment parity between staging and production; if staging does not resemble production closely, tests passing there mean little. It also requires investment in infrastructure for staging environments, and enough automated test coverage across multiple layers, not just unit tests, to trust that a passing pipeline really is release-ready. Without that discipline, the manual approval step becomes a false sense of safety rather than a genuine gate.
Best Practices
- Maintain staging environments that mirror production configuration, network topology, and dependency versions as closely as practical.
- Build the artifact once and promote the same artifact through every stage rather than rebuilding per environment.
- Use feature flags to decouple deployment from release, so code can be shipped to production dark and switched on separately.
- Automate a rollback path for every release so the manual approval step is not the only safety mechanism.
- Track deployment frequency and lead time for changes to measure whether the practice is actually reducing release risk.
Frequently Asked Questions
What is Continuous Delivery?
Continuous Delivery extends Continuous Integration so every change that passes automated tests is automatically packaged into a deployable release artifact, with production deployment triggered by a manual approval step.
How does Continuous Delivery work?
Continuous Delivery works by combining the components described in the sections above. The main page walks through the architecture, the typical use cases, and the trade-offs to weigh before adopting it.
Why does Continuous Delivery matter?
Teams adopt Continuous Delivery to ship faster, run more reliably, and reduce the cognitive load on engineers. The benefits, limits, and adjacent tools are covered in the body above.
When should you use Continuous Delivery?
Use Continuous Delivery when the problems it solves match what your team is hitting today. The page above outlines the signals that mean you should adopt it now, and the cases where a simpler approach is fine.
