What is Continuous Delivery (CD)?

What is Continuous Delivery (CD)?

Continuous delivery is a software development discipline in which every change is built, tested and promoted automatically, so the software can be released to production at any time. Martin Fowler's definition says exactly that: the software "can be released to production at any time". Whether and when you actually release stays a human or business decision. The practice builds on continuous integration and usually relies on a deployment pipeline.

Continuous delivery vs continuous deployment

The two get abbreviated to "CD", which causes most of the confusion. Fowler's distinction: continuous deployment means every change that goes through the pipeline is put into production automatically. With continuous delivery you could deploy often, but you may choose not to, for example because the business wants a slower release rhythm. Continuous deployment is therefore continuous delivery plus an automatic last step. The reverse does not hold.

How a delivery pipeline works

A change moves through stages, and a failure at any stage stops it:

1. Commit and build. A merge to the main branch triggers a build that produces one artifact, such as a container image.
2. Fast tests. Unit tests and static checks give feedback in minutes.
3. Deploy to a production-like environment. The same artifact is promoted, never rebuilt, so what you tested is what you ship.
4. Slower checks. Integration, end-to-end and regression tests run here, and so can a load test.
5. Release. A person presses the button (delivery) or the pipeline does it (deployment).

Two techniques make frequent releases safer: feature flags separate deploying code from switching a feature on, and a gradual rollout limits how many users see a change first.

Example

A team merges a pull request at 10:00. By 10:15 the pipeline has built an image, passed the unit tests and deployed it to staging, where the end-to-end suite and a short load test also pass. The build is marked releasable. The product owner waits for a marketing announcement and releases on Thursday with one click. If the pipeline released it at 10:15 without that step, the team would be doing continuous deployment.

Common mistakes

• Calling a build server "CD". Without automated tests and a repeatable release step, the software is not releasable on demand.
• Rebuilding per environment. A different artifact in production than in staging breaks the point of the pipeline.
• Long-lived branches. Integrating rarely makes every release large and risky.
• Manual environment setup. Staging that drifts from production hides problems until release day. Infrastructure as code helps.
• Skipping performance. Functional tests pass while a change makes the app slow under load.

Continuous delivery, load testing and monitoring

A releasable build should also be a build that holds up under traffic. LoadFocus's load testing page describes a GitHub Action that runs a load test, reads the pass/fail verdict and can block a deploy when a threshold is breached. After release, API monitoring tells you whether production behaves as the pipeline predicted. For practical advice on pipelines, see our CI/CD best practices and the guide to canary deployments.

FAQ

Is continuous delivery the same as continuous deployment?

No. Continuous delivery keeps every change in a releasable state and leaves the decision to release to people. Continuous deployment releases every change that passes the pipeline automatically.

Do I need continuous integration first?

Yes, in practice. Continuous delivery builds on continuous integration: changes must be merged and tested frequently before they can be promoted through later stages.

Does continuous delivery mean releasing many times a day?

No. It means you can release at any time. How often you do is a business choice.

Where do load tests belong in the pipeline?

After the build is deployed to a production-like environment, as one of the slower checks. A threshold on response time or error rate can fail the build before release.