Continuous Delivery

In Turkish: Sürekli Teslimat

Updated October 6, 20262 min read

In short

Continuous delivery is the practice of keeping software ready to release at any time, with an automated pipeline building, testing and preparing every change.

What is continuous delivery?

Continuous delivery, the CD in CI/CD, is the practice of keeping software in a state where it can be released to production at any moment. Every change that passes continuous integration continues through an automated deployment pipeline, so releasing stops being a risky project and becomes a routine decision, often a single click. Jez Humble and David Farley described the approach in their 2010 book Continuous Delivery.

A deployment pipeline builds the application once and then promotes that same artifact, such as a container image, through a series of stages: unit tests, deployment to a test or staging environment, automated acceptance tests and sometimes performance and security checks. Because every environment is created and deployed in the same automated way, a production deployment is just one more run of a well-practiced process. If something goes wrong, the previous version can be redeployed just as easily.

Continuous deployment goes one step further and removes the final human approval: every change that passes the pipeline goes to production automatically, often many times a day. That needs a very reliable test suite, good monitoring and safety nets such as canary deployments, automatic rollbacks and feature flags, which let code be deployed while a new feature stays switched off until it is ready.

Continuous delivery and continuous deployment share the abbreviation CD and are easily mixed up. The difference is a single step: in continuous delivery every change is ready to go and a person decides when it reaches production, while in continuous deployment the pipeline decides. Think of a packed suitcase: continuous delivery keeps it packed so you can leave whenever you choose, and continuous deployment leaves as soon as it is packed.

Key takeaways

Continuous delivery keeps every change ready to release to production at any time.
An automated deployment pipeline builds once and promotes the same artifact through each stage.
In continuous delivery, a person approves the production release.
In continuous deployment, every change that passes the pipeline goes live automatically.
Feature flags separate deploying code from releasing a feature to users.

Example

A deployment pipeline in GitHub Actions: staging, then productionyaml

on: { push: { branches: [main] } }
jobs:
  staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v5
      - run: ./deploy.sh staging
  production:
    needs: staging           # runs only after staging succeeded
    runs-on: ubuntu-latest
    environment: production  # with required reviewers: continuous delivery
    steps:                   # without them: continuous deployment
      - uses: actions/checkout@v5
      - run: ./deploy.sh production

Readers ask

What is the difference between continuous delivery and continuous deployment?

In continuous delivery, every change that passes the pipeline is ready for production, but a person chooses when to release it. In continuous deployment, there is no manual step: each change that passes goes to production automatically.

Do you need continuous integration for continuous delivery?

Yes. Continuous delivery builds on CI: only changes that continuous integration has merged, built and tested can move through the rest of the pipeline. Without CI, there is nothing reliable to deliver.

Is continuous deployment risky?

It can be less risky than rare, large releases, because each deployment is small and easy to undo. It does require strong automated tests, monitoring that spots problems quickly, and tools such as canary deployments and feature flags that limit the damage.

Sources

Spotted a mistake or something missing on this page?Suggest an edit