Ein Repository-Collaborator mit Schreibrecht kann einen Branch pushen und einen Pull Request mergen. Ob derselbe Mensch damit auch in die Produktionsumgebung deployen darf, ist eine andere Frage, und GitHub beantwortet sie über eine eigene Konfigurationsebene: Deployment Environments. Öffentliche Repositories können Environments auf jedem GitHub-Plan einrichten, bei privaten Repositories braucht es mindestens GitHub Pro für ein Einzelkonto oder GitHub Team für eine Organisation. Mit GitHub Free bleibt die Funktion für private Repositories unerreichbar.
Abgrenzung: worum es hier nicht geht
Anders als beim Vier-Augen-Prinzip in der Pipeline, wo Required Reviewers auf Pull-Request-Ebene wirken, geht es hier um die Freigabe des Deploys selbst: eine eigene, vom Repo-Review unabhängige Berechtigungsgrenze je Environment.
Im Unterschied zu „GitHub Actions Environments und Approval Gates: wann eine manuelle Freigabe wirklich schützt“ (muellermh.blog, 11.09.2026), der Environment-Gates als Laufzeitkontrolle betrachtet, steht hier die Berechtigungsstruktur im Vordergrund: wer welches Environment überhaupt ansteuern darf, getrennt von Repo-Rechten und Branch Protection.
Required Reviewers: bis zu sechs, aber nicht sich selbst
Ein Environment kann bis zu sechs Personen oder Teams als Required Reviewers eintragen. Es reicht, wenn eine davon zustimmt, der Job läuft dann weiter. Diese Liste ist unabhängig von den Required Reviewers einer Branch Protection Rule: Dort geht es um die Freigabe eines Pull Requests, hier um die Freigabe des Jobs, der in das Environment deployt.
Dazu kommt eine zweite Stellschraube: die Einstellung „Prevent self-review“, in der REST-API als Parameter prevent_self_review hinterlegt. Ist sie aktiv, kann die Person, die den Workflow-Lauf ausgelöst hat, den eigenen Deployment-Job nicht selbst freigeben, selbst wenn sie als Reviewer eingetragen ist. Ohne diese Einstellung reicht ein Trigger plus Selbstfreigabe, und aus „vier Augen“ werden faktisch zwei.
Wait Timer: Zeit als eigene Schutzschicht
Der Wait Timer verzögert einen Job um eine festgelegte Anzahl Minuten, nachdem er ausgelöst wurde, bevor er tatsächlich startet. Laut REST-API-Referenz liegt der zulässige Wertebereich zwischen 0 und 43.200 Minuten, also bis zu 30 Tage. Anders als ein Required Reviewer braucht der Wait Timer niemanden, der aktiv zustimmt; er schafft nur ein Zeitfenster, in dem ein Deployment noch gestoppt werden kann, bevor es anläuft.
Deployment Branch and Tag Policies: woher deployt werden darf
Die dritte Stellschraube entscheidet, von welchem Branch oder Tag aus überhaupt in ein Environment deployt werden darf. Mit der Option „Selected branches and tags“ legst du einzelne Namensmuster fest, und zwar getrennt für Branches und für Tags: Ein Muster für Branches erlaubt noch keinen Tag und umgekehrt. Damit lässt sich zum Beispiel festlegen, dass in das Environment „production“ nur von main oder von einem Release-Tag aus deployt werden darf, unabhängig davon, wer sonst Schreibrecht auf das Repository hat.
Eine eigene Berechtigungsebene, unabhängig von Repo-Rechten und Branch Protection
Diese drei Stellschrauben zusammen ergeben etwas Grundsätzliches: Ein Environment hat eine eigene Berechtigungslogik, die neben, nicht innerhalb der Repository-Rechte und neben, nicht innerhalb der Branch Protection Rules steht. Zum Konfigurieren eines Environments selbst braucht es Repository-Eigentümerschaft bei einem persönlichen Repository oder Admin-Zugriff bei einem Organisations-Repository. Wer darüber hinaus als Required Reviewer eingetragen wird, ist eine eigene, pro Environment gepflegte Liste, die mit der Collaborator-Rolle einer Person im Repository nichts zu tun haben muss. Ein Mitglied mit Schreibrecht kann damit mergen, aber trotzdem nicht deployen; ein Required Reviewer kann ein Deployment freigeben, ohne selbst Schreibrecht auf dem Repository zu haben. Dieselbe Trennung gilt gegenüber Branch Protection: Eine Branch Protection Rule entscheidet, was auf einen Branch gelangen darf, ein Environment entscheidet unabhängig davon, wer von dort aus deployen darf.
So sieht das im Workflow aus
Ein Job referenziert ein Environment über den Schlüssel environment im Workflow. GitHub Actions wendet die dort konfigurierten Regeln automatisch an, sobald der Job startet:
name: Deploy to productionon: push: branches: [main]jobs: deploy: runs-on: ubuntu-latest environment: name: production url: https://example.com steps: - name: Deploy run: ./deploy.sh
Sobald dieser Job ausgelöst wird, prüft GitHub die für production konfigurierten Required Reviewers, den Wait Timer und die Deployment Branch and Tag Policy, bevor der Job tatsächlich läuft. Keine dieser Prüfungen hat etwas mit den Rechten zu tun, die der Workflow-Trigger ohnehin schon hatte.
Was das für deine Pipeline bedeutet
Für kleine Teams heißt das vor allem: Wer Schreibrecht auf ein Repository vergibt, vergibt damit noch keine Deploy-Berechtigung. Diese beiden Entscheidungen lassen sich getrennt treffen und getrennt pflegen, und genau das ist der Punkt. Ein Environment für Produktion mit eigenen Required Reviewern, einem Wait Timer und einer engen Branch-Policy lässt sich einrichten, ohne an den Repository-Rechten oder an den bestehenden Branch Protection Rules etwas zu ändern.
Wo Unterstützung ansetzt
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Ein künftiger Artikel zu Secrets-Scoping in GitHub Actions muss sich von diesem Beitrag abgrenzen: hier geht es um die Freigabe-Policy des Environments, nicht um den Zugriff auf die darin gespeicherten Secrets.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen