Ein Qualitätsgateway ist eine Prüfung, die die Arbeit vor dem Weiterlaufen bestehen muss. Gateways sorgen dafür, dass das Kriterium „gut genug für den Versand“ nicht mehr subjektiv entschieden wird, sondern vom System jedes Mal gleich umgesetzt wird.
Blockierend und empfehlend
Jedes Gateway ist entweder das eine oder das andere – dieser Unterschied bildet das gesamte Design:
- Blockierend – bei einem Fehler wird die Aufgabe gestoppt. Die Arbeit geht erst weiter, wenn der Fehler behoben ist oder ein Mensch eine Ausnahme macht.
- Empfehlend – ein Fehler wird als Hinweis festgehalten und dem Pull-Request zugeordnet, doch die Aufgabe wird fortgesetzt.
Beginnen Sie mit empfehlenden Gateways. Beobachten Sie eine Woche oder zwei lang, welche Gateways bei echter Arbeit tatsächlich auslösen, und heben Sie anschließend die nützlichen auf die Stufe blockierender Gateways. Ein Gateway, das bereits am ersten Tag blockiert, ohne zuvor angepasst worden zu sein, führt meist dazu, dass die Nutzer es umgehen.
Blockierendes Gate
- Abdeckung unter 80%Fehlschlägt
Die Aufgabe wird gestoppt
Sie wird als Nachbesserung zurückgesendet, anstatt einen pull request zu öffnen, den Sie ohnehin ablehnen würden.
- Eine berechtigte Person kann dies außer Kraft setzen. Das Außerkraftsetzen protokolliert wer, wann und worauf.
Beratendes Gate
- Abdeckung unter 80%Fehlschlägt
Ein Ergebnis wird protokolliert
Die Aufgabe setzt den Review-Prozess fort.
- Das Ergebnis wird dem pull request beigefügt, damit Sie es berücksichtigen können.
Was Gateways prüfen können
Gateways greifen in die Verifizierungsphase ein und können Folgendes abdecken:
- Das erfolgreiche Durchlaufen Ihres eigenen Test-Suites
- Vorgaben zur Codeabdeckung
- Linting und statische Analyse
- Sicherheitsprüfungen, konfiguriert in Sicherheit
- Browser-Tests anhand einer laufenden Vorschau
- Nachweise von externen Anbietern, die dem pull request beigefügt werden
Das wertvollste Gateway ist fast immer Ihre bestehende Test-Suite, denn sie enthält bereits die Kriterien, die Ihr Team für wichtig hält.
Wo ein Gateway die Arbeit stoppen kann
Gateways werden während der Verifizierung ausgeführt – nach Abschluss durch den Entwickler-Agenten und vor der Rezension. Ein blockierender Fehler sendet die Aufgabe als Nachbesserung zurück, anstatt einen pull request zu erzeugen, den Sie ohnehin ablehnen würden.
Diese Reihenfolge ist beabsichtigt: Es ist günstiger, innerhalb des Prozesses zu scheitern als direkt auf dem Bildschirm.
Richtlinien
Gateways werden in Richtliniengruppiert, die Sie tatsächlich Projekten zuweisen. Eine Richtlinie ist eine benannte Sammlung von Gateways mit ihren blockierenden bzw. empfehlenden Einstellungen, sodass Sie eine Standard-Richtlinie für Produktionsdienste und eine weniger strenge für interne Tools haben können.
Richtlinien sind versionsbehaftet. Sie veröffentlichen eine Änderung und können bei zu aggressiven neuen Gateways auf eine frühere Version zurückgreifen.
Überschreibungen
Ein blockierendes Gateway kann von einer berechtigten Person überschrieben werden. Die Überschreibung wird dokumentiert – wer, wann und worauf.
Genau diese Dokumentation ist der Sinn dahinter. Ein Gateway, das niemand überschreiben kann, wird umgangen; ein Gateway, das jeder stillschweigend überschreiben kann, ist kein echtes Gateway. Eine nachvollziehbare Überschreibung ist sowohl praktisch als auch nachvollziehbar.
Was Gateways nicht tun
Gateways prüfen Eigenschaften. Sie beurteilen nicht, ob die Arbeit das richtige Problem löst – dafür dienen die Annahmekriterien in der Spezifikation und die anschließende Rezension.
Eine Änderung kann alle Gateways bestehen und dennoch die falsche Lösung sein.