Environment protection rules — required reviewers, wait timers, and branch restrictions

Protection rules are guards that the platform attaches to a named environment. They are evaluated after the workflow has decided to run, before the deployment job starts.

The three rules

flowchart TD
    A[Deployment job requested] --> B{Trigger gate OK?}
    B -- "no" --> Z[Job skipped by workflow]
    B -- "yes" --> C[Submit deployment to environment]
    C --> D{Required reviewers approved?}
    D -- "no" --> Y[Job held, awaiting review]
    Y --> D
    D -- "yes" --> E{Wait timer elapsed?}
    E -- "no" --> X[Job held, waiting]
    X --> E
    E -- "yes" --> F{Branch restriction satisfied?}
    F -- "no" --> W[Job rejected]
    F -- "yes" --> G[Job runs]

The three rules in production order:

• Required reviewers. One or more named operators must approve before the job starts.
• Wait timer. A delay between approval and execution - typically minutes. Gives the team time to react to an in-flight bad deploy.
• Branch restriction. Allowed only from specific branches, tags, or commit patterns.

Required reviewers

jobs:
  deploy-prod:
    environment:
      name: production
    runs-on: ubuntu-latest
    steps:
      - run: deploy.sh production

The workflow declares this job targets the production environment. The platform reads the production environment’s protection rules and applies them. The list of reviewers lives at the platform level, not in the workflow. Name reviewers by team, not by individual.

Wait timers, branch restrictions, the canonical shape

A wait timer is a delay between approval and execution. Two effects: the cooling-off effect (lets the approving reviewer revoke the approval if they notice something wrong) and the audit effect (the deployment record shows approval time, timer expiry, and deploy start time). A branch restriction says this environment can only be deployed to from these branches or tags. Combined with a tag trigger, the restriction ensures only a tag-named commit can deploy to production.

The canonical production deploy:

on:
  push:
    tags: ['v*.*.*']
jobs:
  deploy-prod:
    environment:
      name: production
    runs-on: ubuntu-latest
    steps:
      - run: deploy.sh production

Five guards. All must agree: tag trigger, environment binding, required reviewers, wait timer, branch restriction. A protection rule in a workflow file can be edited by anyone with write access; a protection rule in the platform settings requires admin access. That difference is the operational reason the rules live in the platform.

Production discipline

1. Configure at the platform level. Do not reimplement the gate in the workflow file.
2. Name reviewers by team, not by individual.
3. Set a non-zero wait timer for production. The cooling-off effect gives the team a chance to revoke an in-flight approval.
4. Combine with a tag trigger. Branch restrictions say no deploys from feature branches; tag triggers say no deploys except from a tagged release.

Cross-course references

• Linux for Production Sysadmins - Part XXXVI covers change windows for system changes.
• Terraform for Production Sysadmins - Part XXVIII covers the canonical promotion pattern through protected environments.

Quiz