Der Hauptzweig des Buchungsportals der Nordlicht Reisen GmbH ist bisher offen: Wer Schreibrecht hat, pusht direkt. Letzte Woche hat ein Push den Build gebrochen, und niemand hatte die Änderung gesehen. Sie sollen den Hauptzweig so schützen, dass jede Änderung durch einen Pull Request geht, geprüft und gebaut wird, und dass das in Azure Repos und bei GitHub gleich gut funktioniert.
Die Prüfung nennt das: den Pull-Request-Ablauf mit Branch Policies und Branch Protection Rules entwerfen und Merge-Beschränkungen festlegen.
Vorwissen: Eine Pipeline für ein Repository kennen Sie aus K3, Lektionen 3.7.1 und 3.7.2; dort sehen Sie auch, wie ein Build als Bedingung am Pull Request hängt. Welche Zweigstrategie Ihr Team nutzt, entscheiden Sie in Lektion 2.1; hier setzen Sie sie durch. Rechte und Gruppen im Einzelnen folgen in Lektion 2.4 und im Modul D5.
Das Ziel: ein Hauptzweig, der immer baut
Microsofts Anleitung zur Verzweigungsstrategie sagt, der Code im Hauptzweig solle Tests bestehen, sauber bauen und aktuell sein. Dazu empfiehlt sie eine Richtlinie, die drei Dinge verlangt: einen Pull Request für Änderungen (das verhindert direkte Pushes), automatisch hinzugefügte Prüfer und einen erfolgreichen Build. Außerdem soll der Pull-Request-Build schnell sein, damit er die Prüfung nicht aufhält. Bei Azure Repos heißt der Mechanismus Branch Policies, bei GitHub branch protection rules und, neuer, Rulesets.
Microsofts Seite zu Branch Policies sagt: Ein Zweig mit erforderlichen Richtlinien lässt sich nicht löschen, und alle Änderungen müssen über Pull Requests laufen.