Topic 6.1
CD vs Continuous Deployment: The Real Organizational Decision
In one line
Topic 0.1 defined the difference between Continuous Delivery and Continuous Deployment — this topic covers what actually determines which one a team should genuinely choose, beyond just picking a definition.
Key ideas
- 01
Topic 0.1 established the definitions: Continuous Delivery keeps every passing change genuinely deployable, with a human deciding when; Continuous Deployment removes that human decision, shipping automatically. This topic covers the REAL factors that should decide which one a specific team actually adopts, not just which sounds more impressive.
- 02
TEST COVERAGE MATURITY is the single biggest factor — Continuous Deployment means a passing test suite is the ONLY thing standing between a code change and real users. A team with genuinely comprehensive, trustworthy automated tests (unit, integration, and meaningful end-to-end coverage) has a real basis for that trust; a team with sparse or unreliable tests does not, regardless of how appealing full automation sounds.
- 03
MONITORING AND ALERTING maturity matters just as much as testing — Continuous Deployment without genuinely fast, reliable production monitoring means a bad deployment could affect real users for a long time before anyone even notices. A team practicing Continuous Deployment safely typically has real-time dashboards and alerting (this course's own DevOps roadmap dedicates a full Observability section to exactly this) that would catch a problem within minutes, not hours.
- 04
FEATURE FLAGS (a runtime toggle controlling whether a piece of functionality is actually active, independent of whether its code has been deployed) let a team DECOUPLE deploying code from actually releasing a feature to users — this is genuinely what makes aggressive Continuous Deployment safer in practice: new code can be deployed constantly, dormant behind a flag, and activated for real users only when a human genuinely decides it's ready, recovering much of Continuous Delivery's human-judgment safety net without sacrificing deployment speed.
- 05
ORGANIZATIONAL and REGULATORY constraints sometimes settle the question outright, regardless of technical maturity — some industries (finance, healthcare) have genuine compliance requirements mandating a human review and approval step before certain changes reach production, making full Continuous Deployment simply not an option no matter how strong the team's tests or monitoring are.
- 06
The genuinely mature answer for most real teams is neither extreme — Continuous Delivery with automation all the way up to a single, fast, low-friction manual approval (Phase 2.2's GitHub Environments, Phase 4.3's GitLab
when: manual) captures the overwhelming majority of Continuous Deployment's speed benefit while keeping one deliberate, cheap human checkpoint at the genuinely highest-stakes moment.
Code & diagrams
Not a coin flip — a handful of genuinely concrete factors point toward one answer or the other.
Explain it without notes
Why is 'we have good tests' alone not necessarily sufficient justification for adopting full Continuous Deployment?
How do feature flags let a team get much of Continuous Deployment's speed benefit while keeping a genuine human decision point?
Practice
For a hypothetical team you're familiar with, honestly assess its test coverage, monitoring maturity, and feature-flag usage, and decide whether Continuous Deployment or Continuous Delivery with a manual gate is genuinely the more appropriate choice right now.
Explain, in one sentence, why a regulated industry (finance, healthcare) might be structurally unable to adopt full Continuous Deployment regardless of its actual technical maturity.
Trade-offs
- ↔
Chasing full Continuous Deployment as a goal in itself, ahead of a team's actual testing and monitoring maturity, trades a real, meaningful safety net for a speed benefit the team may not even be positioned to safely use — genuine organizational maturity, not technical capability alone, is what should drive this decision, and there's no shame (and often considerably more safety) in a mature team deliberately choosing to keep one fast, human gate rather than removing it purely for the sake of a label.
Done when you can
I can name the genuine factors (test maturity, monitoring, feature flags, regulation) that should decide between Continuous Delivery and full Continuous Deployment.
I understand how feature flags decouple deploying code from releasing a feature to users.
I can honestly assess a real or hypothetical team's actual readiness for full Continuous Deployment.