The decision framework — choosing between continuous delivery and continuous deployment

The choice between continuous delivery and continuous deployment is not a tooling decision. The platform supports both; the configuration is one boolean. The choice is a maturity claim about the team that runs the pipeline. A team that adopts deployment without the maturity to back it up has not adopted deployment; they have removed the gate. The framework below is the assessment that determines whether a team is ready to remove it.

The five criteria

Five criteria, in order of weight, determine whether a team should run continuous delivery or continuous deployment:

• Test coverage. Is every production-critical path exercised by CI? A coverage floor below 80% is a team that should not deploy without a gate.
• Observability. Can the team detect a production regression within minutes? A team without production alerting, without dashboards, without a runbook for rolling back, should not deploy without a gate.
• Blast radius. What fraction of production traffic does a single change affect? A change that affects 100% of traffic on apply should not deploy without a gate.
• Regulation. Does the workload require a documented change-approval record? Regulated workloads require the gate as an audit mechanism, regardless of the team’s maturity.
• On-call burden. What is the cost of a production regression? A team whose on-call rotation is a single engineer, or a team with no on-call rotation, should not deploy without a gate.

flowchart TD
    A[Assess team against five criteria] --> B{Coverage adequate?}
    B -- "no" --> C[Continuous delivery]
    B -- "yes" --> D{Observability adequate?}
    D -- "no" --> C
    D -- "yes" --> E{Blast radius acceptable?}
    E -- "no" --> C
    E -- "yes" --> F{Regulation requires gate?}
    F -- "yes" --> C
    F -- "no" --> G{On-call burden acceptable?}
    G -- "no" --> C
    G -- "yes" --> H[Continuous deployment is safe]

The diagram shows the assessment path. The default outcome

• if any criterion fails - is continuous delivery. Only a team that passes all five is ready to remove the gate.

What each option requires

Concrete practice is what distinguishes the options:

Continuous delivery requires:

• A CI pipeline that produces a reproducible artifact on every merge.
• An environment protection rule on the production environment with named reviewers.
• A wait timer between approval and apply, typically five minutes.
• A documented rollback procedure for the on-call engineer.
• A reviewer pool that is broad enough to not bottleneck on a single individual.

Continuous deployment additionally requires:

• A coverage floor enforced in CI, typically 80% or higher for the production-critical paths.
• Production-grade observability with alerts on the metrics that matter: latency, error rate, saturation, business signals.
• Progressive delivery: canary releases, feature flags, traffic shaping, blue/green.
• Automated rollback triggered on anomaly, not on human decision.
• A chaos-drill programme that exercises the rollback path under simulated failure.
• The cultural willingness to deploy on Friday afternoon and to deploy while the on-call engineer is asleep.

Moving from delivery to deployment

The path from continuous delivery to continuous deployment is the path of acquiring the four compensating disciplines. A team that wants to deploy should establish the discipline in the order below, with each discipline proven in production before moving to the next:

1. Test coverage. Set a coverage floor; expand the test suite until every production-critical path is exercised. Block merges below the floor.
2. Observability. Add alerts on the metrics that matter. Confirm the alerts fire on synthetic and staging incidents before relying on them in production.
3. Progressive delivery. Adopt feature flags. Run canaries. Confirm the canary catches a regression in staging before relying on it in production.
4. Automated rollback. Build the rollback automation. Run chaos drills that exercise the rollback path under simulated failure. Confirm the rollback completes within the team’s detection-to-rollback budget.

git tag --list 'v*' --sort=-version:refname | head -10
gh workflow enable deploy-production.yml

The first command lists the most recent production tags; the team uses this output to confirm the rollback target when a regression ships. The second command re-enables the production deploy workflow, which may have been disabled while the team acquired the disciplines.

The sequence is “prove the discipline in delivery, then remove the gate that the discipline replaced”. A team that removes the gate before proving the discipline has not replaced it; they have removed it. The promotion from delivery to deployment is the moment the team demonstrates that the four disciplines catch what the gate used to catch.

Production discipline

1. Default to continuous delivery. A new team has not earned the right to deploy without a gate. The gate is structural defence against unknown unknowns.
2. Assess the five criteria before removing the gate. Coverage, observability, blast radius, regulation, and on-call burden must all be adequate before the gate is removed.
3. Prove the discipline in delivery. Acquire the four compensating disciplines while the gate is in place. Confirm they catch what the gate would have caught.
4. Promote to deployment as a deliberate decision. The promotion is a documented change to the team’s deployment policy, not a quiet configuration edit.
5. The gate can be re-added at any time. A team that realises it is not ready for deployment can fall back to delivery by configuring required reviewers. The reverse is not true.

Cross-course references

• This course, Part XLVIII (ConditionalExec) - lesson git-cicd-gitops-xlviii-06-environment-protection-rules describes the gate that the framework is built around.
• This course, Part L (TerraformCI) - lessons git-cicd-gitops-l-05-terratest-and-integration-tests and git-cicd-gitops-l-06-plan-as-artifact-and-pr-comment are part of the test-coverage discipline that deployment requires.
• Linux for Production Sysadmins - Part XXXI (Observability) covers the metrics and alerting that detection latency depends on.

Quiz