Practice : Continuous Delivery (CD)
Purpose and Strategic Importance
Continuous Delivery (CD) is the discipline of ensuring software can be released to production at any time, safely and sustainably. It builds on the foundation of Continuous Integration and enables teams to deliver business value quickly, with reduced risk and manual effort.
CD transforms deployment from a risky event into a routine activity. By automating the end-to-end path to production, teams gain confidence in frequent releases and can respond rapidly to feedback and market changes. This accelerates learning loops and unlocks more frequent delivery of valuable features.
Description of the Practice
- The system is always in a deployable state, and teams can release on demand.
- Builds that pass CI are automatically promoted through test environments, with gating checks.
- Deployments are automated, repeatable, and require no manual intervention or approvals.
- Releases are decoupled from deployments through feature flags, versioning, or progressive delivery techniques.
- Delivery workflows are observable and monitored for success, performance, and reliability.
How to Practise It (Playbook)
1. Getting Started
- Extend your CI pipeline to include packaging, deployment to staging, and smoke tests.
- Automate deployments using infrastructure-as-code tools (e.g. Terraform, Pulumi, Bicep).
- Introduce feature flags to decouple deployment from release.
- Define a minimal “Definition of Done” that includes successful deployment to a test environment.
2. Scaling and Maturing
- Implement progressive delivery techniques such as blue-green deployments or canary releases.
- Use environment promotion pipelines that move artefacts from staging to production without rebuilding.
- Monitor every deployment with health checks, logs, and telemetry.
- Integrate approval gates for high-risk releases based on metrics, not manual sign-offs.
- Make rollback easy and automatic - include one-click or instant revert options.
3. Team Behaviours to Encourage
- Treat deployments as everyday activities - not high-risk events.
- Proactively discuss deployment health in retrospectives and blameless postmortems.
- Collaborate with platform teams to improve deployment speed and reliability.
- Ensure developers own their deployments end-to-end, not just hand over to operations.
4. Watch Out For…
- Long-lived feature branches that delay integration and increase merge conflicts.
- Manual deployment steps or reliance on tribal knowledge.
- Testing only in production-like environments - production is the truth.
- Poor observability - “deployed” doesn’t mean “working” without confirmation.
5. Signals of Success
- Deployments occur multiple times per day or per week without drama.
- Changes can be deployed independently of each other.
- Recovery from failed deployments is fast and automated.
- Customers receive value incrementally and consistently.
- Engineers feel confident deploying to production without fear.