Continuous Integration ends with a tested artifact. That sounds great, but a green build does not mean the software actually works in a realistic environment. Unit tests run in isolation. Integration tests run against mocks. Until you put the software somewhere that looks like production and exercise it under real conditions, you have not really proven anything. Continuous Delivery is the step that closes that gap.
What Continuous Delivery Actually Is#
Continuous Delivery takes the artifact produced by CI and automatically deploys it into a production-like environment — usually called staging — where another set of automated tests runs against it. End-to-end tests, performance tests, contract tests, security tests like DAST, sometimes even penetration tests. The goal is to find the problems that only appear when the software is actually running, talking to real services, against real-shaped data.
Crucially, deployment to staging is automatic, but the release to production is not. Continuous Delivery means the software is always in a releasable state — but a human (or a business rule) decides when to actually push it to customers. You get a button. You press it when the business is ready.
Continuous Delivery vs. Continuous Deployment#
This is the most common source of confusion in the whole CI/CD vocabulary, so it is worth being explicit:
- Continuous Delivery = every change is automatically deployed to staging and could be released to production. The decision to release is manual.
- Continuous Deployment = every change that passes all automated tests is automatically released to production. There is no manual gate.
Both share the same abbreviation — CD — and that is genuinely unhelpful. When someone says “we do CD,” ask which one. The trade-offs are different, the organisational maturity required is different, and the risk profile is different.
Why Continuous Delivery Is the Sweet Spot for Most Teams#
Most organisations are not ready for Continuous Deployment, and that is fine. Regulated industries, customer-facing products with marketing-coordinated launches, mobile apps that need store approval — all of these have legitimate reasons to keep a human in the loop for the final release decision.
Continuous Delivery gives you almost all the benefits without forcing that decision. The pipeline proves that every change could go live. The artifact is built, tested, deployed to staging, tested again. The risk of release is small because nothing surprising happens at release time. The deployment mechanism has run hundreds of times before. Releasing becomes routine instead of an event.
What Runs in the Continuous Delivery Stage#
A typical Continuous Delivery stage adds, on top of CI:
- Automated provisioning or update of the staging environment.
- Deployment of the artifact to staging using the same mechanism that production will use.
- End-to-end tests against the running system.
- Performance and load tests on representative data.
- Dynamic application security testing (DAST), which can only run against a live service.
- Smoke tests that verify integrations with downstream systems.
Everything that needs a running system, real data shapes, or real network behaviour belongs here.
The Discipline Continuous Delivery Demands#
Continuous Delivery only works if the staging environment looks like production — same configuration management, same deployment mechanism, same database engine, ideally the same scale. Differences between staging and production are where bugs hide. Treat configuration drift between environments as a defect, not a feature.
It also requires the deployment process itself to be code. Manual steps, side notes in a wiki, “ask Karl, he knows” — none of that scales. If a human has to do something during deployment, the deployment is not really automated yet.
Key Takeaways#
- Continuous Delivery deploys every artifact to a production-like environment automatically. The release to production stays a human decision.
- Don’t confuse Delivery with Deployment. Both are abbreviated CD, but the second one removes the manual gate. Be precise about which one you actually do.
- The point is being always releasable. Whether or not you press the button on every change, the option must be there.
- Staging must look like production. Drift between environments is where bugs hide.
- Deployment must be code, not steps in a wiki. Manual steps break the chain and break the trust.
- For most teams, Continuous Delivery is the right destination. Continuous Deployment is the next step — but only when the organisation, the tests, and the monitoring are ready for it.