Continuous Delivery vs Deployment

The Two C’s

 CONTINUOUS DELIVERY (CD):
   every green build is DEPLOYABLE on demand.
   a human (or approval flow) presses the button per release.

 [CI ✓] → auto: staging → [await approval] → prod on command

 CONTINUOUS DEPLOYMENT:
   every green build goes ALL THE WAY automatically.

 [CI ✓] → staging → canary gates → prod. no human gate.

 deployment ⊃ delivery: same machinery, minus the pause.

Choosing Between Them

 continuous DEPLOYMENT fits when:
 □ strong automated test culture + observability + rollback
   automation genuinely trusted
 □ product model tolerates feature-by-feature exposure
   (features hidden behind FLAGS until ready)
 □ team size/velocity rewards frictionless shipping

 continuous DELIVERY fits when:
 □ releases are COORDINATED EVENTS (marketing syncs, pricing)
 □ regulated domains demand human review checkpoints
 □ batch-release cadence is an organizational reality
   ("ship Thursdays" cultures exist; fight later, deliver now)

 both beat the alternative — manual artifact juggling with
 snowflake build steps. the debate is WHERE THE GATE SITS,
 not whether pipelines exist.

The Machinery Both Share

 □ ONE artifact promoted through environments
   (build once! the CI lesson's immutability rule)
 □ environment promotion pipeline: dev→staging→prod mirrors,
   config injected externally (12-factor hygiene)
 □ progressive rollout at prod: canary/gates (deployment-
   strategies lessons) — CD without progressive delivery
   is just faster ways to cause incidents
 □ INSTANT rollback path rehearsed and automated
 □ deployment = not release: features ship DARK behind flags;
   exposure decouples from deploy (flags lesson)

Practice	Delivery	Deployment
automated pipeline to staging	✓	✓
prod promotion	approved/manual trigger	automatic
feature exposure control	flags/coordinated	flags
rollback	automated	automated

The Maturity Prerequisites

 honest checklist before turning the crank to full-auto:

 □ test suite TRUSTWORTHY (flaky rate near zero — flaky tests
   + auto-deploy = random production changes)
 □ observability catches regressions in MINUTES (gates need eyes)
 □ automatic rollback proven by GAME DAYS, not believed
 □ database migrations backward-compatible (expand-contract) —
   otherwise deploys entangle with schema state
 □ blast-radius controls: progressive exposure limits any
   single bad build's damage fraction

 missing two or more? stay at delivery-level while fixing.
 auto-deploying atop shaky foundations automates your incidents.

Interview Framing

“Should this team do continuous delivery or deployment?” scored shape: define the distinction crisply, decision factors listed per side (coordination/regulation vs test-trust/velocity), shared machinery emphasized (build-once, progressive rollout, rollback), maturity prerequisites before full-auto named. This question tests whether you treat release engineering as RISK CALIBRATION rather than ideology.