Appearance

Continuous Delivery ​

Building software so it can be released to production at any time

Related Concepts: Continuous Integration | Acceptance Testing

What is Continuous Delivery? ​

Continuous Delivery (CD) is a software development discipline where you build software in such a way that the software can be released to production at any time.

Martin Fowler defines it through four key indicators:

  1. Software remains deployable throughout development - Not just at release time
  2. Teams prioritize keeping software deployable - Even over adding new features
  3. Fast, automated feedback on production readiness - Know the deployment status within minutes
  4. Push-button deployment to any environment - Deploy any version to any environment on demand

The emphasis is on capability. You maintain the ability to release at any time, even if you choose not to.

Continuous Delivery vs. Continuous Deployment ​

These terms are often confused, but the distinction is important:

Continuous Delivery:

  • Software is always releasable
  • Deployment to production requires human decision
  • You can deploy at any time, but may choose not to
  • Release timing is a business decision

Continuous Deployment:

  • Every change that passes all stages automatically goes to production
  • No human intervention required
  • Results in many production deployments per day
  • Release timing is automatic

As Fowler explains: "Continuous Deployment means that every change goes through the pipeline and automatically gets put into production. Continuous Delivery just means that you are able to do frequent deployments but may choose not to do it."

Most organizations practice Continuous Delivery, not Continuous Deployment. They maintain the capability to deploy at any time but make conscious business decisions about when to release.

The Deployment Pipeline ​

The deployment pipeline is the key pattern in Continuous Delivery. It emerged from ThoughtWorks projects where teams struggled with complex, manual processes for preparing environments and deploying builds.

Definition ​

A deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of users. It breaks the build process into stages, each providing increasing confidence while typically requiring more time.

From Continuous Delivery: The deployment pipeline is "an automated process for managing all changes, from check-in to release."

How It Works ​

Each commit to mainline triggers the pipeline. The change flows through a series of stages, and with each passing stage, you gain higher confidence in that revision of the code.

The pipeline addresses the tension between speed (fast feedback) and thoroughness (comprehensive verification):

  • Early stages catch most problems rapidly with fast automated checks
  • Later stages provide slower but more thorough verification
  • Each stage can be configured to run automatically or require manual approval
  • Parallel execution optimizes speed within each stage

Pipeline Stages ​

The canonical deployment pipeline from Continuous Delivery consists of these stages:

1. Commit Stage ​

Purpose: Provide fast feedback that the code is fundamentally sound.

Activities:

  • Compile the code (if applicable)
  • Run unit tests
  • Run static code analysis
  • Create deployable packages/artifacts
  • Produce internal code quality reports

Speed: Must complete in minutes—ten minutes is the absolute maximum. This speed is critical because developers wait for commit stage feedback before moving to their next task.

Output: An environment-independent packaged version of your application that will be used for all subsequent stages.

The commit stage contains mainly unit tests and gives you high confidence that you haven't introduced regressions with your latest change.

2. Acceptance Stage ​

Purpose: Verify that the software meets business requirements and works end-to-end.

Activities:

  • Deploy the artifact from commit stage to a production-like environment
  • Run automated acceptance tests
  • Verify complete workflows and business scenarios
  • Test integration with external systems

Speed: Slower than commit stage (potentially hours), but fully automated. The acceptance stage is parallelized to execute as fast as possible.

Critical Rule: The acceptance test gate is a key point in the release candidate lifecycle. The deployment system will only deploy release candidates that have passed all acceptance tests.

3. Additional Stages (Optional) ​

After passing acceptance tests, organizations may add stages for:

Capacity/Performance Testing:

  • Load testing
  • Stress testing
  • Performance benchmarking

Security Testing:

  • Penetration testing
  • Vulnerability scanning
  • Security compliance checks

Manual Exploratory Testing:

  • User experience validation
  • Edge case exploration
  • Visual verification

UAT (User Acceptance Testing):

  • Business stakeholder validation
  • Real user testing in staging

4. Production Deployment ​

Continuous Delivery: Manual trigger required—human decides when to deploy Continuous Deployment: Automatic deployment—every change that passes all stages goes live

Pipeline Configuration Principles ​

From ThoughtWorks and Continuous Delivery:

Make your pipeline wide, not long:

  • Minimize the number of sequential stages
  • Parallelize each stage as much as possible
  • Reduce total time from commit to production

Each stage can be configured to:

  • Run automatically based on previous stage success
  • Require manual trigger/approval
  • Run in parallel with other stages

Fail fast:

  • Put fastest tests first
  • Stop the pipeline immediately on failure
  • Provide clear feedback on what failed and why

Pull Requests and Modern CD ​

The canonical Continuous Delivery definition assumes trunk-based development without pull requests—developers commit directly to mainline, triggering the pipeline immediately.

However, most modern teams have adapted the practice to include pull requests:

The Modern Adaptation ​

Before Merge (On Pull Request):

  • Run commit stage checks
  • Run subset of acceptance tests (smoke tests)
  • Provide fast feedback to developer
  • Gate the merge—only allow green builds to merge

After Merge to Main:

  • Run full deployment pipeline
  • Commit stage → Acceptance stage → Optional stages → Deployment capability

This adaptation maintains the spirit of CD while providing the code review benefits teams value. The key constraint: pull requests must be short-lived (less than one day) to avoid delaying integration.

Essential Requirements ​

Continuous Delivery requires:

1. Continuous Integration ​

CD builds on CI as its foundation. From Fowler: "Continuous Integration focuses on integrating, building, and testing code within the development environment, while Continuous Delivery extends these practices to production deployment stages."

Without CI's frequent integration and automated testing, you cannot achieve CD.

2. Comprehensive Automated Testing ​

The pipeline depends entirely on automated test confidence:

  • Unit tests for commit stage speed
  • Integration tests for component verification
  • Acceptance tests for business requirement validation
  • Additional tests as needed (performance, security, etc.)

Without comprehensive automated tests, you cannot trust the pipeline to tell you if software is releasable.

3. Deployment Automation ​

Every environment deployment must be automated and repeatable:

  • No manual steps
  • Identical process for all environments (dev, staging, production)
  • Configuration externalized from deployment artifacts
  • Rollback capability

4. Production-Like Test Environments ​

Acceptance and later stages must run in environments that closely mirror production:

  • Same infrastructure configuration
  • Same data patterns (anonymized if necessary)
  • Same deployment process
  • Same monitoring and logging

5. Cultural Practices ​

DevOps Collaboration: Continuous Delivery requires collaborative relationships across all delivery roles—development, operations, testing, security, business stakeholders.

Prioritize Deployability: Teams must value keeping software deployable over adding features. If the pipeline is red, fix it before writing new code.

Small Batch Sizes: Frequent, small changes move through the pipeline faster and with less risk than large, infrequent changes.

The Four Key Metrics ​

The book Accelerate provides research-backed metrics that measure Continuous Delivery effectiveness:

1. Lead Time for Changes ​

How long does it take for a commit to reach production?

  • Elite performers: Less than one hour
  • High performers: Less than one day
  • Medium performers: Between one day and one week
  • Low performers: More than one week

2. Deployment Frequency ​

How often do you deploy to production?

  • Elite performers: On-demand (multiple deploys per day)
  • High performers: Between once per day and once per week
  • Medium performers: Between once per week and once per month
  • Low performers: Less than once per month

3. Change Failure Rate ​

What percentage of changes to production result in degraded service or require remediation?

  • Elite/High performers: 0-15%
  • Medium performers: 16-30%
  • Low performers: More than 30%

4. Mean Time to Restore (MTTR) ​

How long does it take to restore service when an incident occurs?

  • Elite performers: Less than one hour
  • High performers: Less than one day
  • Medium performers: Between one day and one week
  • Low performers: More than one week

These metrics demonstrate a direct link between organizational performance and software delivery performance. Teams with effective Continuous Delivery practices score significantly better on all four metrics.

Benefits of Continuous Delivery ​

Reduced Deployment Risk ​

Deploying small changes frequently is far less risky than deploying large changes infrequently. When something goes wrong, it's easier to identify and fix because the change set is small.

Faster Time to Market ​

The ability to release features when ready—not when the deployment calendar allows—dramatically reduces time from idea to customer value.

Higher Quality ​

Automated verification at every stage catches bugs early. The rapid feedback loop encourages fixing issues immediately rather than letting them accumulate.

Lower Stress ​

Deployments become routine, boring events rather than high-stress, weekend-consuming marathons. Operations teams aren't pulled in for emergency "all hands" deployment support.

Better Products ​

When you can deploy at any time, you can:

  • Release MVPs to test hypotheses quickly
  • A/B test features in production
  • Respond to customer feedback rapidly
  • Roll back bad changes immediately

Improved Productivity ​

Developers spend time building features, not fighting deployment processes or fixing integration problems. Automation handles the repetitive, error-prone tasks.

Common Misconceptions ​

"We do CD because we use a CI/CD tool" ​

Using Jenkins, GitHub Actions, CircleCI, or other tools doesn't mean you practice Continuous Delivery. These tools enable CD, but the practice requires:

  • Software staying deployable at all times
  • Comprehensive automated testing
  • Deployment pipeline with proper stages
  • Cultural commitment to deployability

"CD means deploying to production constantly" ​

No—that's Continuous Deployment. Continuous Delivery means you can deploy at any time. Release timing remains a business decision.

"We can't do CD because of regulations" ​

Regulations typically require audit trails, approval processes, and change control—all of which Continuous Delivery improves:

  • Better audit trails (every change tracked through pipeline)
  • Automated compliance verification
  • Faster, more reliable rollbacks
  • Separation of deployment capability from deployment decision

"CD is only for web applications" ​

While web applications were early adopters, CD principles apply to:

  • Mobile applications
  • Desktop software
  • Embedded systems
  • Infrastructure as code
  • Machine learning models

The pipeline stages and timing may differ, but the core practice—keeping software releasable—remains valuable.

"Our acceptance tests are too slow for CD" ​

This reveals a testing architecture problem, not a CD problem. Solutions include:

  • Parallelize test execution
  • Categorize tests (smoke tests vs. full suite)
  • Optimize slow tests
  • Run subsets in different stages

When CD is Hard ​

Legacy Deployment Processes ​

Organizations with complex, manual deployment processes face significant challenges:

  • Extensive manual testing before release
  • Manual environment provisioning
  • Configuration managed in spreadsheets or documentation
  • Deployment knowledge held by specific individuals

The path forward: Automate incrementally. Start with the most painful manual steps, automate them, then move to the next pain point.

Tightly Coupled Architecture ​

Monolithic applications where changes to one part require redeploying everything make frequent deployment risky.

The path forward: Move toward modular architecture (see Modular Monolith) with clear boundaries, enabling independent deployment of modules.

Insufficient Test Coverage ​

Without comprehensive automated tests, the pipeline cannot provide confidence in release readiness.

The path forward: Add tests incrementally (see Working with Legacy Code). Cover new code completely, add tests to legacy code as you touch it.

Cultural Resistance ​

Common obstacles:

  • "Deployment is operations' job" (siloed responsibilities)
  • "We release quarterly; that's just how we work" (batch mentality)
  • "Testing takes three weeks" (manual testing mindset)
  • "We can't trust automated tests" (lack of confidence in automation)

The path forward: Education, demonstrating success with pilot projects, leadership support, and gradual cultural change.

The Bottom Line ​

Continuous Delivery extends Continuous Integration from integration verification to deployment readiness. By automating the path from commit to production through a deployment pipeline, teams transform releases from high-risk events to low-risk, routine business decisions.

Core Practice:

  • Keep software deployable at all times
  • Automate the path from commit to production
  • Use a deployment pipeline with clear stages
  • Prioritize deployability over feature development
  • Measure effectiveness with the four key metrics

The Deployment Pipeline:

  1. Commit Stage - Fast feedback (under 10 minutes) with unit tests and code quality checks
  2. Acceptance Stage - Automated business requirement verification
  3. Optional Stages - Performance, security, manual exploratory testing
  4. Production Deployment - Manual trigger (CD) or automatic (Continuous Deployment)

Key Insight:

Continuous Delivery is fundamentally about reducing risk through frequency and automation. Small, frequent, automated deployments are safer, faster, and less stressful than large, infrequent, manual deployments.

Remember:

Continuous Delivery is the capability to release at any time, not the requirement to release constantly. It gives business stakeholders the power to decide when to release based on business value, not technical constraints.

Further Reading ​

Books ​

  • Continuous Delivery by Jez Humble and Dave Farley - The canonical text defining CD practices and the deployment pipeline pattern
  • Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim - Research-backed evidence for CD effectiveness and the four key metrics
  • The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, and John Willis - Practical DevOps transformation including CD implementation

Articles ​

Resources ​