Practice : Continuous Deployment

Purpose and Strategic Importance

Continuous Deployment (CD) is the capability to automatically release every validated change into production. It represents the pinnacle of automation maturity, reducing lead time, enabling real-time feedback, and accelerating value delivery to users.

By eliminating manual steps between integration and production, CD allows teams to move at high velocity without sacrificing quality. It supports experimentation, empowers developers, and fosters a high-trust environment where change is safe, rapid, and reversible.

Description of the Practice

  • Every code change that passes CI is automatically deployed to production without manual approval.
  • Deployments are small, frequent, and low-risk by design.
  • Feature management strategies are used to separate deployment from release.
  • Real-time monitoring ensures that deployed changes can be validated quickly.
  • Rollbacks are automated and tested regularly.

How to Practise It (Playbook)

1. Getting Started

  • Ensure your CI pipeline is stable and provides fast, reliable feedback.
  • Automate deployment to production using tools like ArgoCD, Spinnaker, or GitHub Actions.
  • Implement feature flags to hide incomplete or risky features from users.
  • Include smoke tests or health checks in the deployment flow.
  • Define a “stop the line” policy for any production failure.

2. Scaling and Maturing

  • Automate all validation gates - security checks, performance thresholds, and rollback triggers.
  • Use blue-green or canary deployments to safely introduce change.
  • Record and visualise deployment frequency as a team metric.
  • Integrate deployment events with observability platforms to detect and respond to anomalies quickly.
  • Align CD tooling with your organisational release governance or audit requirements.

3. Team Behaviours to Encourage

  • Build a culture where releasing is routine - not exceptional.
  • Focus on reducing batch size and time between idea and impact.
  • Encourage experimentation with rollback safety nets in place.
  • Share learnings from every deployment - successful or not.
  • Take collective ownership of production health, not just dev completeness.

4. Watch Out For…

  • Deploying without adequate observability - you can’t fix what you can’t see.
  • Releasing features without a way to disable or revert them.
  • Fragile pipelines that break under frequent use.
  • Teams bypassing CD flows due to lack of trust in automation.

5. Signals of Success

  • Teams deploy changes to production multiple times per day.
  • Lead time for changes is consistently under 1 day.
  • Rollbacks are rare, fast, and treated as expected flow, not failure.
  • Releases happen during business hours without needing incident rooms.
  • Developers express high confidence in releasing code safely.