Festlegen, wo Taiga auf eine Entscheidung wartet

Trennen Sie vier Entscheidungen

Der fiktive Ausstattungsdienst hat vier unterschiedliche Entscheidungen: den Plan annehmen, den Build ausführen, die Änderung mergen und sie bereitstellen. Behandeln Sie einen einzelnen Schalter nicht als Autorisierung für alle vier.

Prüfen Sie vor einer Autonomy-Änderung, was die Repository-Pipeline nach dem Merge tut. Wenn ein Merge in den Arbeitsbranch ein Deployment auslöst, kann auch ein automatisierter Merge diesen bestehenden Workflow starten.

Entscheiden Sie, ob ein Plan wartet

Die Produkteinstellung Build on its own by default steuert, ob auf einen abgeschlossenen Plan ein Build folgt oder ob er auf Genehmigung wartet. Deaktivieren Sie sie, wenn Pläne zuerst eine menschliche Entscheidung brauchen.

Die Einstellung Build on its own einer Initiative kann dieses Verhalten für die einzelne Initiative ändern. Prüfen Sie sowohl den Standardwert als auch eine spezifische Auswahl, bevor Sie Arbeit in Queue stellen.

Approve startet den Build als genehmigende Person und im Rahmen ihrer aktuellen Berechtigungen. Ein fehlgeschlagener Plan startet keinen Build. Build-Automatisierung autorisiert für sich genommen keinen Merge des entstandenen Pull Requests.

Verstehen Sie die Merge-Hierarchie

Autonomer Merge wird getrennt gesteuert und ist bis zur Aktivierung ausgeschaltet. Die dokumentierte Integration unterstützt GitHub einschließlich GitHub Enterprise.

Eine deaktivierte Organisations- oder Factory-Obergrenze lässt sich darunter nicht übersteuern. Eine deaktivierte Produktstandardeinstellung ist anders: Eine Initiative kann ihren eigenen Merge aktivieren, wenn die Obergrenzen es erlauben.

Halten Sie beim Ausstattungsdienst den ersten Umfang ausdrücklich fest. Eine Initiative mit geringen Folgen kann innerhalb der erlaubten Grenzen eine andere Einstellung haben als eine Änderung an Mitarbeiterzugriffskontrollen.

Machen Sie erforderliche Reviews durchsetzbar

Taiga fragt den Anbieter der Versionsverwaltung, ob der Pull Request gemergt werden darf. Ihr Branch-Schutz bestimmt die erforderlichen Prüfungen, Reviews und weiteren Bedingungen. Autonomer Merge umgeht diese Regeln nicht.

Wenn ein automatisiertes Review den Merge blockieren muss, machen Sie sein Ergebnis über die unterstützte Repository-Konfiguration zu einer erforderlichen Statusprüfung. Ein beratendes Ergebnis wird nicht verbindlich, nur weil Sie dies erwarten.

Prüfen Sie auch erforderliche menschliche Genehmigungen. Eine grüne Prüfung ersetzt keine Genehmigung, die Ihre Richtlinie verlangt. Bestätigen Sie die Regeln auf dem tatsächlichen Zielbranch.

Verstehen Sie einen gestoppten Merge

Lesen Sie den Grund an der Initiative. Eine ausstehende Prüfung, fehlende Genehmigung, ein Konflikt und ein unvollständiger Plan erfordern unterschiedliche Reaktionen. Taiga stoppt autonomen Merge auch, wenn Korrekturen die Kriterien verändern, durch die zuvor fehlgeschlagene Prüfungen bestehen. Prüfen Sie diese Änderung direkt.

Entfernen Sie keine erforderliche Prüfung, nur weil sie den Fortschritt blockiert. Wenn sie nie ein Ergebnis meldet, korrigieren Sie ihre Konfiguration oder nutzen Sie das autorisierte Richtlinienverfahren. Prüfen Sie nach jeder Korrektur den aktuellen Commit.

Halten Sie die Deployment-Autorisierung getrennt

Die Taiga GitHub App führt einen autonomen Merge aus und wird als ausführende Identität vermerkt. Die Repository-Pipeline behält ihr bestehendes Deployment-Verhalten.

In diesem Szenario führt der Merge zu einem Deployment nach Staging. Die Produktion braucht weiterhin die Produktionsentscheidung und Nachweise der Organisation. Bestätigen Sie, dass die Pipeline diese Trennung durchsetzt. Fahren Sie mit dem Delivery-Review fort.