Continuous deployment — no approval, what that implies

Continuous deployment is continuous integration plus an automatic apply. The pipeline produces the artifact; the workflow applies the artifact to production without a human approval step. The change reaches production the moment CI finishes. The team has decided, deliberately or by drift, that no human checkpoint is needed between the artifact and the apply.

What “no approval” actually commits to

The decision to deploy without approval commits the team to four things at once, none of them optional:

• Every change that passes CI is production-bound. There is no last-second filter between the artifact and the cluster. The pipeline does not pause for context, risk, or timing.
• Every mistake in a merged change is a production mistake. A configuration typo, an off-by-one, a query that does not match the production data shape - any of these reach production the moment the merge happens.
• The team’s recovery time is the only safety margin. Detection-to-rollback latency, plus the time to roll back, is the window of damage. A team that detects a bad change in thirty minutes and rolls back in five minutes has a thirty-five-minute window.
• Every “is this the right change at this moment” decision has been pre-decided. The team has decided in advance that no human will ever stop a green build from reaching production. That decision cannot be revisited at deploy time.

flowchart LR
    A[Commit] --> B[CI pipeline]
    B --> C{Tests pass?}
    C -- "no" --> D[Pipeline fails]
    C -- "yes" --> E[Artifact published]
    E --> F[Automatic production apply]
    F --> G{Observability signal?}
    G -- "anomaly" --> H[Automated rollback]
    G -- "normal" --> I[Release complete]

The diagram has no approval step. The arrow from artifact to production apply is direct. The only safety mechanism between the apply and the release is observability, which triggers rollback on anomaly.

The four compensating disciplines

What makes continuous deployment safe is not the absence of approval - the absence of approval removes safety - but the presence of four disciplines that catch the mistakes the gate would have caught:

• Comprehensive automated test coverage. Tests must cover the change, the surrounding behaviour, and the failure modes. The CI pipeline must fail on any regression a human reviewer would have caught.
• Production-grade observability. Latency, error rate, saturation, and business metrics must be measurable at the change’s blast radius within seconds. Detection is the only window between the bad apply and the rollback.
• Progressive delivery. Canary releases, blue/green deploys, feature flags, and traffic shaping keep a bad change from reaching 100% of production the moment it is applied. The mistake is contained to a fraction of the traffic.
• Automated rollback. The rollback decision must be automated on anomaly. A rollback that waits for a human to read a dashboard and click a button is a rollback that arrives after the damage has compounded.

What this implies about safety discipline

The trade-off the team is making is explicit:

• The team has chosen to deploy faster in exchange for accepting that every change is a potential production incident.
• The team has accepted that detection and rollback latency are the only safety margin.
• The team has accepted that the four disciplines must be continuously maintained; a discipline that rots (a test suite that no longer covers the changed code, an observability dashboard that no longer reflects the production behaviour, a feature flag that no longer isolates the new behaviour) restores the gate’s job to the pipeline without restoring the gate.

git tag --list 'v1.4.*'

This command lists the tags in the production release range. In a continuous deployment setup, every tag that appears in this output is a tag the team has shipped without a manual gate. The list is the audit record of every deploy. If the list is long and the on-call pager has been quiet, the four disciplines are working. If the list is short and the pager has been quiet, the team has not yet had a change miss the disciplines - the absence of incidents is not evidence of safety.

Production discipline

1. The four disciplines are the gate. A team without them has removed approval without replacing it. The resulting setup is not continuous deployment; it is unmonitored apply.
2. Detection latency is the safety budget. The time between a bad apply and a rollback is the only window in which damage compounds. Shrink the window by investing in observability.
3. Progressive delivery is cheaper than rollback. A 5% canary that catches the regression in two minutes is cheaper than a 100% rollout that catches it in thirty. Use feature flags and traffic shaping.
4. Automated rollback must be tested. A rollback path that has never been exercised in production is a rollback path that may not work. Run chaos drills.
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 on the production environment. 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 deployment removes.
• This course, Part LII (KubernetesCI) - lessons git-cicd-gitops-lii-04-policy-conftest-and-kyverno and git-cicd-gitops-lii-05-security-scanning-trivy-and-kubescape 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