Kann das Pull Request-Modell von GitHub zur Implementierung von Post-Genehmigungen verwendet werden?

Die akzeptierte Antwort auf " Was sind mögliche Implementierungen (oder Beispiele) des Vier-Augen-Prinzips? " Schlägt vor, dass das Pull-Request-Modell von GitHub eine mögliche Implementierung ist.

Und meine eigene Antwort auf " Wie wird das Vier-Augen-Prinzip für Notfallkorrekturen implementiert? " Erklärt das Konzept der Nachgenehmigungen .

Meine Frage : Kann das Pull Request-Modell von GitHub auch für die Implementierung von Post-Genehmigungen verwendet werden? Wenn das so ist, wie? Wenn nicht, gibt es noch etwas in Git (GitHub?), Das ich dafür verwenden könnte?

Ja, das glaube ich. Um zu erklären, dass ich einige Grundlagen dafür schaffen muss, wie ich etwas Ähnliches implementiert habe, habe ich das Modell vereinfacht, um es so klar wie möglich zu machen.

Annahmen

Ich gehe hier davon aus, dass Jenkins, TeamCity oder ähnliches als CI / CD-Tool der Wahl verwendet wird. Zusätzlich wird GitHub verwendet und es gibt eine gut definierte und entsprechend gesteuerte Verzweigungsstruktur:

Aufbau

In diesem Beispiel ist GitHub wie folgt konfiguriert:

• Der schwarze 'Master'-Zweig kann nur mit Pull Requests zusammengeführt werden , direkte Commits sind nicht zulässig.
• Der blaue Zweig "Entwicklung" kann direkte Commits oder Zusammenschlüsse akzeptieren. In der Praxis kann es zusätzliche Einschränkungen für diesen Zweig geben.
• Der rote 'Hotfix'-Zweig kann direkte Commits und Zusammenführungen akzeptieren.
• Erforderliche Statusprüfungen werden im strengen Modus aktiviert , um zu verhindern, dass Pull-Anforderungen zusammengeführt werden, wenn der Zweig den Build nicht besteht.
• Wenn der Hotfix-Zweig vor dem Master liegt, werden Pull-Anforderungen in den Master blockiert, entweder mit der Status-API oder den Pre-Receive-Hooks auf GitHub Enterprise .

Die CI / CD-Tools sind wie folgt konfiguriert:

• Builds aus dem Entwicklungszweig können nicht für die Produktion bereitgestellt werden.
• Builds von Master können in allen Umgebungen bereitgestellt werden.
• Builds von Hotfix können in allen Umgebungen bereitgestellt werden.
• Deployments von Hotfix wird einige Nicht-Entwicklungsfunktion, zum Beispiel das Ändern / Veröffentlichung Team benachrichtigen und sie bitten, die auszuführen nach der Genehmigung .

Anmerkungen

Der Master ist geschützt, da er den aktuellen Produktionsstatus darstellt. Um dies praktisch zu tun, haben Sie möglicherweise einen anderen "Release" -Zweig, von dem aus Bereitstellungen vorgenommen werden, und zwar nur dann, wenn der Master-Zweig erfolgreich zusammengeführt wurde.

Wichtige Punkte

Die Blue Development-Niederlassung ist im Grunde genommen ein Alleskönner. Hotfix ist eine Art eines free-for-all aber alle Installationen eine Art auslösen Break Glass durch eine Nicht-Entwicklung Funktion benachrichtigt, die den Willen ausführt nach der Genehmigung und in dem Prozess wird die Änderung in Meister verschmelzen.

Es ist wichtig, in den Master-Stop zu verschmelzen, während Hotfix dem Master voraus ist, um:

1. Verhindern Sie, dass der Master den Hotfix überschreibt, was zu einer Regression führen kann.
2. Verhindern Sie, dass ein Hotfix im Hotfix-Zweig schmachtet, ohne zusammengeführt zu werden.

In einigen Organisationen kann es hilfreich sein, alle Pushs in das zentrale GitHub-Repository zu verhindern, während ein Hotfix nach der Genehmigung aussteht.