Continuous Delivery (CD)

Continuous Delivery (CD) is a software engineering approach in which code is always kept in a releasable state, so any change, whether a new feature, a configuration change or a bug fix, can go to production safely and quickly whenever the business chooses. Releasing becomes a routine, low-risk decision rather than a stressful event.

How Continuous Delivery Works

Jez Humble and David Farley set out the approach in their 2010 book Continuous Delivery. Humble defines it as the ability to get changes of all types into production, or into the hands of users, safely and quickly in a sustainable way.

The central mechanism is the deployment pipeline. Every change committed to the main branch moves through automated stages:

1. A commit stage builds the software and runs fast unit tests, which is continuous integration.
2. Later stages run broader automated checks, such as acceptance, performance and security tests, in production-like environments.
3. The same tested build is promoted to production, either at the push of a button or automatically.

If any stage fails, the change stops and the team fixes it before moving on. Martin Fowler offers a simple test: could a business sponsor ask for the current development version to go live right now without anyone panicking?

Why Continuous Delivery Matters

Smaller, more frequent releases carry less risk because each contains fewer changes, and a problem is easier to find and roll back. Progress becomes visible as working software rather than status reports. For product managers, the biggest gain is faster feedback: an idea can reach real users in days, so the team learns whether it works before investing further. Combined with feature flags, it lets a team deploy code continuously while choosing exactly when users see a feature.

Continuous Delivery Example

A B2B analytics team commits to its main branch many times a day. Each commit passes through a pipeline that runs unit tests, deploys to a staging environment, runs end-to-end and load tests, then marks the build as ready. The product manager and engineering lead release to production twice a week, after checking that release notes and support documentation are ready. When a customer reports a reporting error on Tuesday morning, the fix reaches production that afternoon through the same pipeline.

Continuous Delivery vs. Continuous Deployment

The two share the "CD" abbreviation. In continuous delivery, every change is releasable, but a person decides when to release. In continuous deployment, every change that passes the pipeline goes to production automatically, with no manual step. Continuous deployment requires continuous delivery, but a team can practice continuous delivery without deploying automatically, which suits products that need regulatory sign-off or coordinated launches. Deciding when and how to release is the job of release management.