Continuous Delivery (CD)
What it is
Continuous Delivery (CD) is the practice of automatically building, packaging, and preparing every validated change so it can be released to any environment (dev → test → staging → production) with the push of a button — or fully automatically. It’s the “delivery” half of CI/CD, running after Continuous Integration produces a tested artifact.
Why it exists
CI proves every change builds and passes tests. CD extends that to prove every change is always in a releasable state and can get to production quickly and safely. It shrinks the time between “code merged” and “value delivered to users” and removes the risky, manual, error-prone “release day” ritual.
Key ideas
- Automation: a pipeline (e.g. release pipeline in Azure Pipelines/GitHub Actions) carries a build artifact through stages: deploy → test → smoke → sign off → production.
- Releasable state, not necessarily released: CD makes a release possible and easy; it doesn’t force auto-releasing to users.
- Continuous deployment is the stricter cousin: every change that passes the pipeline is automatically released to production with no human approval. CD is a prerequisite; continuous deployment is a choice layered on top.
- Relies on deployment gates (quality/approval checkpoints), rollback, and automated environment parity.
How it fits
Code → CI (build+test) → CD pipeline → stage → gates → production
Exam notes
- Distinguish continuous delivery (change is ready to release; deployment to production may be manual) from continuous deployment (every change is released automatically).
- CD requires high test automation and rollback capability; without those, you can’t safely auto-release.
- In Azure Pipelines, releases are modeled with stages + approval/gates (see deployment-gate).
Related
release-strategy · release-definition · deployment-gate · rollback-strategy · feature-flags · deployment-ring
📘 Source: Microsoft Learn — Cd