Continuous Delivery vs Continuous Deployment

Both ship code through automation, but only one removes the human from the final release.

People use "CD" to mean two different things, and the difference matters. Continuous delivery keeps every change releasable and one click away from production. Continuous deployment goes further and ships every passing change automatically. This lesson defines both precisely and helps you pick.

Two definitions, one acronym

Continuous delivery means the main branch is always in a deployable state, and a release to production is a manual decision (a button, an approval). Continuous deployment means that decision is automated: if the pipeline is green, the change goes live without a human in the loop.

Where the gate lives

• Continuous delivery: automated build, test, and packaging, then a manual approval before production.
• Continuous deployment: automated all the way to production, no manual approval.
• Both depend on continuous integration underneath - frequent merges with automated tests.

How to choose

Teams with strong test coverage, fast rollback, and good observability can adopt full continuous deployment for low-risk services. Regulated systems, or anything where a bad release is expensive, usually keep continuous delivery with an approval gate. Many orgs mix both: auto-deploy staging, gate production.

A minimal delivery pipeline

In GitHub Actions, a delivery model adds an environment with a required reviewer so production waits for a human:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production   # require approval here for delivery
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh

Key takeaways

• Continuous delivery keeps code releasable with a manual go-live step.
• Continuous deployment removes that step and ships every green build automatically.
• Choose based on test confidence, rollback speed, and the cost of a bad release.

Related guides