Der Beitrag vom 6. August (Vier-Augen-Prinzip in der Pipeline) beschreibt Required Reviewers auf Ebene des Pull Requests: ein zweiter Mensch liest den Code, bevor er in den Ziel-Branch gemergt wird. GitHub Actions kennt eine zweite, unabhängige Stelle für eine manuelle Freigabe: das Environment. Eine Environment Protection Rule greift nicht beim Review des Codes, sondern unmittelbar davor, dass ein Workflow-Run tatsächlich auf eine bestimmte Umgebung zugreift und dort etwas ausführt. Das ist keine Wiederholung des Code-Reviews, sondern eine andere Kontrolle mit einem anderen Ziel.

Was ein Environment Gate kann, das ein Code-Review nicht kann

Ein Code-Review sieht den Quelltext, aber nicht, welche Secrets ein Workflow-Run zur Laufzeit tatsächlich ausliest. GitHub Actions bindet Secrets an ein Environment: Ein Secret, das nur der Umgebung „production“ zugeordnet ist, steht einem Job erst zur Verfügung, wenn der Job dieses Environment referenziert und die zugehörige Freigabe passiert hat. Ein Workflow-Run von einem Fork oder einem Feature-Branch, der niemals gegen „production“ deployt, kommt an dieses Secret gar nicht heran, unabhängig davon, wie der Code aussieht. Das ist ein Kontrollpunkt, den ein Reviewer beim Lesen von Diff-Zeilen strukturell nicht prüfen kann, weil die Trennung erst zur Laufzeit greift.

name: Deploy to production
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        env:
          DEPLOY_TOKEN: ${{ secrets.PROD_DEPLOY_TOKEN }}
        run: ./scripts/deploy.sh

Required Reviewer markiert den Moment, in dem ein Workflow-Run tatsächlich beginnt, gegen eine geschützte Umgebung zu wirken, nicht den Moment, in dem Code in einen Branch wandert. Zwischen Merge und Deploy können Stunden oder Tage liegen, in denen sich der Zustand der Zielumgebung ändert. Wer einen Pull Request freigibt, sagt damit noch nichts über die Produktionsumgebung zum Zeitpunkt des tatsächlichen Deploys.

Ein Wartefenster erzwingt eine Mindestverzögerung zwischen Freigabe und Ausführung, unabhängig davon, wie schnell jemand den Freigabe-Button klickt. Diese Verzögerung ist keine Bürokratie, sie ist die einzige Stelle in der Pipeline, an der ein Mensch einen bereits freigegebenen Deploy noch stoppen kann, ohne vorher ahnen zu müssen, dass etwas schiefläuft. Eine Branch-Policy für das Environment grenzt zusätzlich ein, von welchem Branch aus überhaupt deployt werden darf, sodass ein Workflow-Run von einem experimentellen Branch gar nicht erst in die Position kommt, in der die Freigabe gefragt wird.

PUT /repos/{owner}/{repo}/environments/production
{
  "wait_timer": 30,
  "prevent_self_review": true,
  "reviewers": [
    { "type": "Team", "id": 4321 }
  ],
  "deployment_branch_policy": {
    "protected_branches": true,
    "custom_branch_policies": false
  }
}

Wo das Gate an seine Grenze kommt

Ein Environment Gate ist nur so unabhängig wie die Menschen, die es bedienen. Ein Required Reviewer verlangt eine Person aus einer Liste, nicht zwingend eine andere Person als die, die den Pull Request bereits freigegeben hat. In kleinen Teams, in denen dieselbe Person Code-Review und Deploy-Freigabe übernimmt, wiederholt sich exakt dasselbe Urteil zweimal, nur an einer zweiten Stelle in der Pipeline. Die Einstellung „prevent_self_review“ verhindert lediglich, dass jemand seinen eigenen Workflow-Run freigibt, sie erzwingt keine andere Person als die, die vorher schon den Code gesehen hat. Wer beide Rollen strukturell trennen will, muss das über die Zusammensetzung der Reviewer-Liste selbst lösen, nicht über eine einzelne Einstellung.

Dazu kommt: Ein Environment Gate schützt nur, was durch dieses Environment läuft. Ein Workflow, der Produktionszugriff über einen anders benannten Job, ein separates Secret außerhalb des Environments oder einen zweiten Workflow ganz ohne Environment-Referenz erreicht, umgeht die Freigabe vollständig. Nicht weil die Regel falsch konfiguriert ist, sondern weil sie an der Stelle im Workflow gar nicht erst zur Anwendung kommt.

Zwei Fragen, keine Wiederholung

Required Reviewer auf PR-Ebene und Environment-Freigabe vor dem Deploy beantworten unterschiedliche Fragen: die eine, ob der Code in Ordnung ist, die andere, ob genau jetzt gegen genau diese Umgebung ausgeführt werden soll. Wer nur eine der beiden Stellen absichert, hat die andere Hälfte des Problems unberührt gelassen.

Wer sich für die andere Seite dieser Kontrolle interessiert, die Ebene, auf der ein Pull Request selbst durchgesetzt wird, findet dazu mehr auf digital-business.blog.