Starting CD

Migrating your system to Continuous Delivery

Tags:

2 minute read

Continuous Delivery (CD) is the ability to deliver the latest changes on-demand, with no human touchpoints between code integration and production delivery.

Overview

Continuous Delivery extends beyond automation. It encompasses the entire cycle of identifying value, delivering it, and verifying with the end-user that the expected value was delivered.

Goals

CD aims to:

Uncover external dependencies and organizational process issues
Reduce overhead
Improve quality feedback
Enhance end-user outcomes and team work/life balance

CD Maturity

While avoiding rigid “maturity models,” we can outline competency levels:

Minimums

Daily integration of tested changes to the trunk
Consistent delivery process for all changes
No manual quality gates
Same artifact used in all environments

Good

New work delivered in less than 2 days
All changes delivered from the trunk
Commit-to-production time under 60 minutes
Less than 5% of changes require remediation
Service restoration time under 60 minutes

Continuous Integration (CI)

CI Working Agreement

Branches originate from and are deleted within 24 hours
Changes must pass existing tests before merging
Team prioritizes completing work in progress over starting new work
Fixing a broken build is the highest priority

Desired Outcomes

More frequent integration of smaller, higher quality changes
Efficient test architecture
Lean code review process
Reduced Work In Progress (WIP)

Continuous Delivery/Deploy

Aims to achieve:

Increased delivery frequency and stability
Improved deploy success and time to restore service
Reduced development cycle time and process waste
Smaller, less risky production releases
High-performing product teams with domain expertise

Recommended Practices

Conduct a Value Stream Map
Build a roadmap to remove constraints
Align with the CI working agreement
Implement a single CD automated pipeline per repository

Note

A valid CD process has only one method to build and deploy any change. Deviations indicate an incomplete process that puts the team and business at risk.

Pipeline Best Practices

Focus on hardening the pipeline to block bad changes
Integrate outside the pipeline, virtualize inside
Limit stage gates (ideally one or fewer)
Developers own the full pipeline

Key Metrics

CI cycle time: < 10 minutes from commit to artifact creation
CD cycle time: < 60 minutes from commit to Production

Tips

Use trunk merge frequency, development cycle time, and delivery frequency to uncover pain points
Keep all metrics visible and refer to them often
See CD best practices and CD Roadblocks for more tips