CD is the DevOps practice of keeping software in a releasable state at all times by moving every validated change through an automated release pipeline. The abbreviation covers two closely related disciplines: continuous delivery, in which every change that passes the pipeline can be released with a single approved action, and continuous deployment, in which every passing change goes to production without any manual step.
In DevOps and cloud engineering, CD is the natural continuation of CI. Continuous integration proves that the code builds and passes tests; CD proves that the same build can be deployed safely, then deploys it to staging and production environments using repeatable, scripted procedures rather than hand-run release checklists.
How a CD pipeline moves a change to production
A CD pipeline takes a single immutable artifact, such as a container image or a versioned package, and promotes it through a sequence of environments. The core rule is build once, deploy many: the artifact tested in staging is byte-for-byte the artifact that reaches production, so no rebuild can introduce untested differences.
Each stage acts as a quality gate. A change advances only when automated checks pass, and any failure stops the promotion and notifies the team. The table below shows the stages found in most cloud CD pipelines and what each one verifies.
| Stage | What happens | What it verifies |
|---|---|---|
| Artifact publication | The CI output is tagged and stored in a registry | Traceability from commit to release |
| Test environment deployment | Scripted deployment to a short-lived environment | That the deployment procedure itself works |
| Acceptance testing | Functional, contract and integration tests run | Behavior against business requirements |
| Non-functional checks | Performance, security and compliance scans | Latency, vulnerabilities, policy rules |
| Staging deployment | Release into a production-like environment | Configuration and dependency correctness |
| Production release | Progressive rollout with health monitoring | Real user impact and error rates |
Configuration is kept outside the artifact. Environment-specific values such as connection strings, feature flags and replica counts are injected at deploy time, usually from declarative configuration stored in version control. This separation is what allows one artifact to run correctly in every environment.
Continuous delivery versus continuous deployment
The difference between the two meanings of CD lies in who presses the final button. Both require the same automation, test coverage and pipeline discipline; continuous deployment simply removes the last human approval step before production.
| Aspect | Continuous integration | Continuous delivery | Continuous deployment |
|---|---|---|---|
| Scope | Merge, build and test | Everything up to a releasable build | Everything up to production |
| Production release | Not covered | Manual approval, one action | Automatic on every passing change |
| Release frequency | Not applicable | On business demand | Many times per day possible |
| Test coverage needed | Unit and build tests | Broad automated suite | Very high, trusted suite |
| Typical fit | Every team | Regulated or scheduled releases | Web services with fast feedback |
Continuous delivery suits organizations that must coordinate releases with regulatory sign-off, marketing dates or customer contracts. Continuous deployment suits teams that run online services, own their operations and can detect and reverse a bad change within minutes. Many teams practice delivery for some services and deployment for others.
Deployment strategies used in CD
A CD pipeline needs a release strategy that limits the damage of a faulty change. The strategy determines how traffic moves from the old version to the new one and how quickly the team can roll back. The two most common progressive strategies, blue-green deployment and canary deployment, have their own pages; the table summarizes where they fit.
| Strategy | How traffic moves | Rollback speed | Main cost |
|---|---|---|---|
| Rolling update | Instances are replaced in batches | Minutes, by rolling back again | Mixed versions during rollout |
| Blue-green deployment | Traffic switches between two full environments | Seconds, by switching back | Double infrastructure during release |
| Canary deployment | A small share, often 1-10%, goes to the new version first | Seconds, by draining the canary | Needs good metrics and analysis |
| Feature flag release | Code ships dark and is enabled per user group | Instant, by turning the flag off | Flag debt and testing combinations |
Mature pipelines combine these approaches: an artifact is deployed with a canary analysis step that compares error rates and latency against the stable version, and new behavior stays behind a feature flag until the business is ready to expose it. This decouples deployment from release, which is one of the most valuable ideas in CD.
Measuring and implementing CD
CD performance is commonly measured with the four DORA metrics: deployment frequency, lead time for changes, change failure rate and time to restore service. These metrics balance throughput against stability, so a team cannot improve one by silently sacrificing the other.
| Situation | Recommended choice | Reason |
|---|---|---|
| Weak automated tests | Start with continuous delivery | Manual approval compensates for gaps |
| Monolith with long release cycles | Automate deployment before splitting the system | Repeatable deploys reduce release risk first |
| Database schema changes | Use expand-and-contract migrations | Old and new versions must coexist |
| Regulated environment | Pipeline approvals with audit logs | Evidence is generated automatically |
| Many independent services | One pipeline per service | Teams release without coordination |
Pipelines are usually defined as code in the repository, using tools such as a CI server, a workflow engine or a GitOps controller that reconciles a cluster with the desired state stored in Git. The GitOps model is popular for Kubernetes because the deployed state is always auditable and reversible through ordinary version control history.
Common pitfalls in CD adoption
Most failed CD initiatives fail on process and test quality, not on tooling. The following mistakes appear repeatedly in practice:
- Rebuilding per environment, which means production runs an artifact that was never tested.
- Flaky tests that teams learn to ignore, which destroys trust in the quality gates.
- Manual configuration changes on servers, which create configuration drift the pipeline cannot see.
- Long-lived branches, which turn every release into a risky integration event.
- No rollback rehearsal, so the recovery path fails exactly when it is needed.
- Coupled database migrations that make an older application version incompatible with the new schema.
A useful test of genuine CD is simple: could the team safely release the current main branch right now, on an ordinary afternoon, without a release meeting? If the honest answer is no, the pipeline still has manual gaps.
The short version
CD is a way of shipping software in small, safe, frequent steps. Every time a developer finishes a change, machines build it, test it and prepare it for release. With continuous delivery, a person decides when to release it. With continuous deployment, the release happens automatically once all checks pass.
Think of a bakery that checks every loaf as it leaves the oven instead of inspecting a whole week of baking at once. Problems are caught early, each batch is small, and a bad loaf never reaches many customers. The key idea is that releasing becomes routine rather than a stressful event.
Where it makes a difference
An online booking service with twelve developers used to release once a month after a two-day manual test cycle, and roughly every third release needed an emergency fix. The team introduced a CD pipeline: each merged change produced one container image, which was deployed automatically to a test environment, checked with about 1,500 automated tests, and then released to production as a canary receiving 5% of traffic for 15 minutes.
If error rates or response times rose above the stable version, the pipeline drained the canary and alerted the team. Within a few months, the service moved to several production releases per day, each containing a handful of changes. Incidents still happened, but they were small, easy to trace to a single change and reversed in minutes rather than hours.