What Is Continuous Delivery and Deployment?

Analogy categoryAnalogies

Continuous Delivery (CD) and Continuous Deployment are two related but distinct extensions of Continuous Integration, and the industry frequently conflates them because both are abbreviated 'CD'. Continuous Delivery means that every change which passes the automated pipeline — build, tests, quality gates — is automatically packaged into a release candidate that is provably ready to go to production at any moment, with the final decision to actually release left to a human, often via a button click. Continuous Deployment removes that final human gate entirely: every change that passes the pipeline is automatically released to production with no manual approval step. The distance between the two is a single approval gate, but the organizational and technical maturity required to remove that gate safely is substantial.

🏏

Cricket analogy: A team can have a player fully match-fit and ready to walk out to bat at any moment (release candidate ready) while the captain still makes the final call on the batting order (human gate) — versus a franchise that auto-slots the next fit player in without any captain's decision; the difference is one selection meeting, but the trust in the bench required to remove that meeting entirely is substantial.

Continuous Delivery: Always Releasable

The defining guarantee of Continuous Delivery is not that you release constantly, but that you *could* release at any time with confidence. This requires the pipeline to validate everything a human reviewer would otherwise need to check manually: functional correctness via automated tests, security posture via scanning, performance via benchmarks, and packaging via artifact builds. Many organizations that say they 'do CD' are practicing delivery, not deployment — they might release weekly or even monthly, but each release is a routine, low-drama event assembled from an artifact that has been sitting ready since it passed the pipeline.

🏏

Cricket analogy: The mark of a truly match-ready squad isn't that they play every single day, but that any player on the bench could walk out and perform at Test standard the moment needed — a franchise doing genuine 'delivery' might only field a reserve once a month, but that selection is routine and low-drama because the player has been match-fit the whole time, not scrambled into form overnight.

Continuous Deployment: No Human Gate

Continuous Deployment is deliberately more aggressive: there is no 'ship it' button, because the pipeline itself is the ship-it button. This demands extremely high confidence in automated testing, robust rollback mechanisms, and typically progressive rollout strategies (canary releases, feature flags) so that a bad change affects a small fraction of traffic before automated or human monitoring can catch and revert it. Companies like Etsy, Amazon, and Netflix are famous for extremely high deployment frequency enabled by continuous deployment pipelines.

🏏

Cricket analogy: In T20 franchise cricket's most aggressive 'auto-select' model, there's no captain's team-sheet meeting at all — the algorithm itself is the selection decision, which demands extremely reliable fitness-tracking data, a fast bench-swap protocol if a pick underperforms, and typically a soft debut like batting a rookie at number 8 first before trusting them at number 3 — the IPL's most data-driven franchises are famous for this rapid, algorithm-driven rotation.

yaml

name: Continuous Deployment

on:
  push:
    branches: [main]

jobs:
  test-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run test suite
        run: |
          npm ci
          npm test

      - name: Build artifact
        run: npm run build

      - name: Deploy to production
        if: github.ref == 'refs/heads/main'
        run: |
          ./scripts/deploy.sh --env production --strategy canary
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

A useful mnemonic: Continuous Delivery ends with a build sitting in a warehouse, fully packed and ready to ship the moment someone says go. Continuous Deployment skips the warehouse and puts the package on the truck automatically.

Do not assume Continuous Deployment is strictly 'better' or more mature than Continuous Delivery. Regulated industries (finance, medical devices, aviation software) often require a human approval gate by law or policy, making Continuous Delivery — not Deployment — the appropriate and correct target.

What's Required to Move From Delivery to Deployment

Removing the human approval gate safely usually requires: a comprehensive automated test suite with a low false-negative rate, feature flags to decouple deployment from feature exposure, progressive delivery mechanisms like canary or blue-green rollout, strong observability with automated alerting, and a fast, well-rehearsed rollback path. Without these, continuous deployment simply means shipping bugs to users faster.

🏏

Cricket analogy: Trusting a young keeper to play without the senior coach double-checking every session requires a comprehensive fitness and skills testing regime that rarely gives false 'all clear' readings, the ability to bench them mid-series without changing the public lineup announcement, blooding them in low-stakes warm-up matches first, constant injury-monitoring with automatic alerts to the physio, and a rehearsed emergency-substitute plan — skip these and you're just fielding an unready player faster.

Continuous Delivery keeps every passing build in a releasable state, with a human deciding when to actually release.
Continuous Deployment removes the human approval gate: every passing build goes to production automatically.
Both practices depend on Continuous Integration as their foundation — you cannot safely automate releases of code that hasn't been continuously validated.
Continuous Deployment requires strong safety nets: progressive rollout, feature flags, monitoring, and fast rollback.
Regulated industries often intentionally stop at Continuous Delivery for compliance reasons, not lack of technical capability.
The two terms are commonly and incorrectly used interchangeably, both shortened to 'CD' — always clarify which one a team means.

Practice what you learned

1. What is the key difference between Continuous Delivery and Continuous Deployment?

2. Why might a regulated industry such as banking intentionally stop at Continuous Delivery rather than adopting Continuous Deployment?

3. What technical practice most directly helps decouple 'deploying code' from 'releasing a feature to users' in a continuous deployment setup?

4. In the phrase 'always in a releasable state,' which practice does this describe?

5. Which of these is NOT typically a prerequisite for safely adopting Continuous Deployment?

Was this page helpful?

What Is Continuous Integration?

Anatomy of a CI/CD Pipeline

Related Study Notes in DevOps

Browse all study notes

DevOps

Nginx Study Notes

DevOps · 30 topics

DevOps

Ansible Study Notes

DevOps · 30 topics

DevOps

Advanced Kubernetes Study Notes

Kubernetes · 30 topics

DevOps

Advanced Bash Scripting Study Notes

Bash · 30 topics

DevOps

Apache Kafka Study Notes

Kafka · 30 topics

DevOps

Docker & Kubernetes Study Notes

YAML · 40 topics

Topics covered

#YAML#CICDToolsPipelinesStudyNotes#DevOps#WhatIsContinuousDeliveryAndDeployment#Continuous#Delivery#Deployment#Always#StudyNotes#SkillVeris

What Is Continuous Delivery and Deployment?