Continuous delivery requires approval — what the gate means

Continuous delivery is continuous integration plus a manual approval gate before the production apply. The CI artifact is held at the gate; a human reviews the production-bound change in context and either approves or rejects; on approval, the workflow applies the artifact. The pipeline does not proceed on its own. That is the entire definition. Anything more is implementation detail.

What the gate is

The gate is a workflow-state transition that requires human input to resolve. The CI workflow has produced an artifact; the deploy job is ready to run; the gate stops the deploy job and waits for an approver. The workflow file declares an environment for the deploy job, the platform reads the environment’s protection rules, and the rules hold the job until the named approvers have responded.

gh workflow enable deploy-production.yml
gh workflow run deploy-production.yml --ref v1.4.2 -f environment=production

The first command re-enables a workflow that may have been disabled by a previous incident. The second triggers a workflow run against a specific tag. The run will reach the production deploy job and stop there if the production environment has required reviewers configured. The workflow will not proceed until a named approver clicks Approve in the platform UI.

flowchart TD
    A[CI artifact published] --> B[Deploy job requests environment]
    B --> C{Required reviewers approved?}
    C -- "no" --> D[Job held - awaiting review]
    D --> C
    C -- "yes" --> E{Wait timer elapsed?}
    E -- "no" --> F[Job held - waiting]
    F --> E
    E -- "yes" --> G{Branch restriction satisfied?}
    G -- "no" --> H[Job rejected]
    G -- "yes" --> I[Production apply]

The three rules - reviewers, wait timer, branch restriction - are the canonical shape of the gate. Each is platform-side configuration, not workflow-side code. The gate is enforced by the platform, not by the workflow author.

What the gate is not

The gate is not a code review. The pull-request review approves the change; the gate approves the deployment. Two different audits, two different decisions, two different records. A change can be reviewed and approved, sit on main for a week, and then be deployed - at which point the deploy is a separate act that requires its own approval.

The gate is also not a substitute for testing. A green CI build, a passing test environment, and a reviewed pull request are preconditions for the gate; the gate itself adds nothing to the verification of the change. The gate adds a human checkpoint that catches the kinds of mistakes automated tests cannot - production-context mistakes, risk-tolerance mistakes, and “is this the right change at this moment” mistakes.

The three forms of approval

The gate can be implemented in three forms, often in combination:

• Environment protection rules. The platform holds the deploy job until named reviewers approve. This is the modern, workflow-integrated form. Reviewers are named in the platform configuration, not in the workflow file.
• Change advisory board (CAB) records. A pre-existing change-management process produces a record number, and the deploy job checks for the record before it runs. Common in regulated environments where the audit trail must be independent of the CI platform.
• Manual workflow steps. A workflow step that requires a human to type approve or to post a review comment before the next step runs. The least ergonomic form, but sometimes the only one available on platforms that lack environment protection rules.

What a real gate looks like

The most useful diagnostic for a gate is the latency it adds. A genuine gate adds seconds to minutes between the artifact being ready and the deploy job running, because a human must read the change, decide, and click. A gate that adds milliseconds is a gate that has been automated away.

The second-most useful diagnostic is the rejection rate. A gate that never rejects is a gate that has been turned into a checkbox. Production gates occasionally reject - the timing is wrong, the change is risky, the change has not been tested in staging yet, the on-call engineer is not ready. A rejection rate of zero over six months is evidence that the gate is not doing its job.

Production discipline

1. The gate approves a deployment, not a change. A change can be reviewed and approved; the deployment is a separate decision that the gate exists to make.
2. Audit the gate’s latency and rejection rate. A gate that approves in milliseconds is a rubber stamp; a gate that never rejects is a checkbox.
3. Reviewers are teams, not individuals. A reviewer who quits takes their approval authority with them; a team that owns the gate keeps it.
4. The wait timer is the cheapest safety mechanism. A five-minute wait between approval and apply costs the team five minutes and saves them from the deploy that was approved before the on-call engineer noticed.
5. The gate is platform-side configuration, not workflow code. A workflow that can edit its own gate is a workflow with no gate.

Cross-course references

• This course, Part XLVIII (ConditionalExec) - lesson git-cicd-gitops-xlviii-06-environment-protection-rules is the full treatment of the three rules (reviewers, wait timer, branch restriction) that the gate is built from.
• This course, Part XXXVII (CIFundamentals) - lesson git-cicd-gitops-xxxvii-01-what-ci-is-and-is-not establishes that CI does not gate; the gate is the structure that continuous delivery adds on top.
• Linux for Production Sysadmins - Part XXII (ChangeMgmt) covers the change advisory board process that historically implemented the gate before workflow-side approval existed.

Quiz