Protected environments and required reviewers — the platform-side mechanism that enforces the gate

The approval gate is not a workflow feature. The gate is a platform feature: the deployment environment itself enforces the rules. On GitHub the construct is an environment on the repository, with protection rules attached. On GitLab the construct is a protected environment with allowed tiers and approval rules. In both cases the gate lives outside the workflow file.

The three canonical protection rules

A protected environment can have three canonical rules:

• Required reviewers. Named users or teams whose approval is required before the deploy job can run.
• Wait timer. A minimum delay between approval and the deploy job starting.
• Branch restriction. Only workflows triggered from named branches can deploy. A restriction of main and release/* means a feature branch cannot write to production.

flowchart TD
    A["Deploy job requests environment"] --> B{"Branch allowed?"}
    B -- "no" --> X["Job rejected"]
    B -- "yes" --> C{"Reviewers approved?"}
    C -- "no" --> Y["Job held"]
    Y --> C
    C -- "yes" --> D{"Wait timer elapsed?"}
    D -- "no" --> Z["Job held"]
    Z --> D
    D -- "yes" --> E["Apply with production identity"]

Each rule addresses a different category of failure: branch restriction prevents the wrong source, reviewers add human judgement, and the wait timer creates a window for catching a hasty approval.

Configuring required reviewers from the CLI

The real command is gh environment edit with --required-reviewers, taking a comma-separated list of users or teams:

gh environment edit production \
  --required-reviewers user:alice,bob,team:platform-sre

The command adds three entries: two users and one team. The team is expanded at approval time.

gh environment view production

The view subcommand lists the active configuration.

The lifecycle of a gated deploy

A gated deploy passes through four states:

1. Request. The deploy job declares environment: production. The platform looks up the rules.
2. Held. The platform holds the job; reviewers are notified. The status is waiting.
3. Approved. Every reviewer has clicked Approve. The wait timer (if any) starts.
4. Apply. The timer elapses. The platform issues a deployment token scoped to the environment.

The wait timer as the cheapest safety mechanism

The wait timer is the cheapest safety mechanism in the gate. A five-minute wait costs the team five minutes and saves them from the deploy approved before the on-call engineer noticed. The timer requires no human reviewer pool; it requires only a number. It catches the approval made in haste, the engineer not yet at their desk, the rotation about to change.

Protected environments also do not enforce identity isolation between environments. The platform enforces the gate; identity isolation is enforced by the OIDC trust policy. A reviewer who clicks Approve without reading has satisfied the platform; human behaviour is a separate discipline (LVII-01, LVII-02).

Production discipline

1. The gate is platform-side configuration. Reviewers, wait timer, branch restriction live outside the workflow file.
2. The wait timer is the cheapest safety mechanism. A five-minute wait costs five minutes.
3. Audit the wait timer quarterly. A zero timer is a configuration completed but not finished.
4. Branch restriction is the source-of-truth gate. A workflow from feature/* cannot write to production.

Cross-course references

• This course, Part LVII-01 (When approval adds safety) covers human judgement.
• This course, Part XLVIII-06 (Environment protection rules) covers the three rules in detail.
• This course, Part XLIII-04 (OIDC in AWS) covers identity isolation.
• This course, Part LVII-06 (Approval fatigue and bypass) covers human-behaviour failure.

Quiz