Wann sollte eine Pipeline anhalten und auf einen Menschen warten?
Stellen Sie sich Folgendes vor: Ihr Team hat eine solide CI/CD-Pipeline. Tests laufen automatisch. Sicherheitsscans bestehen. Code wird gebaut und ohne menschliches Zutun auf der Staging-Umgebung bereitgestellt. Dann, kurz vor der Produktion, hält die Pipeline an. Eine Benachrichtigung erscheint: „Freigabe erforderlich.“
Jemand muss auf „Genehmigen“ klicken, bevor die Bereitstellung fortgesetzt wird. Vielleicht ist diese Person Ihr Tech Lead. Vielleicht ist es ein Engineering Manager. Vielleicht sind sie gerade in einer Besprechung oder bereits offline für den Tag. Die Bereitstellung wartet.
Dieser Moment offenbart eine Spannung, mit der jedes Team konfrontiert ist. Wie viel sollte die Pipeline selbst entscheiden? Und wann sollte sie anhalten und um eine menschliche Entscheidung bitten?
Die zwei Arten von Prüfungen
Jede Pipeline hat Kontrollpunkte. Bevor eine Änderung von einer Phase zur nächsten wechselt, wird überprüft, ob es sicher ist, fortzufahren. Dieser Kontrollpunkt kann eines von zwei Dingen sein: ein automatisiertes Gate oder eine manuelle Freigabe.
Ein automatisiertes Gate ist eine Prüfung, die ohne menschliches Eingreifen innerhalb der Pipeline läuft. Die Pipeline führt eine Reihe von Tests oder Validierungen durch und entscheidet dann, ob die Änderung fortgesetzt werden kann. Zum Beispiel führt die Pipeline nach dem Push von neuem Code durch einen Entwickler Komponententests durch. Bestehen alle Tests, wird die Änderung fortgesetzt. Schlägt ein Test fehl, stoppt die Pipeline und benachrichtigt das Team.
Eine manuelle Freigabe ist eine Entscheidung, die von einer Person getroffen wird. Normalerweise ist diese Person ein leitender Ingenieur, Tech Lead oder jemand, der für eine bestimmte Umgebung verantwortlich ist. Sie überprüfen die Änderung, berücksichtigen den Kontext und genehmigen oder lehnen sie ab. Die Pipeline wartet, bis diese Entscheidung eingeht.
Beide dienen dem gleichen Zweck: zu verhindern, dass schlechte Änderungen weitergeleitet werden. Aber sie funktionieren grundlegend unterschiedlich.
Das folgende Diagramm zeigt, wie diese beiden Arten von Prüfungen in eine Bereitstellungs-Pipeline passen:
Was automatisierte Gates gut können
Das stärkste Argument für automatisierte Gates ist Konsistenz. Jedes Mal, wenn eine Änderung in die Pipeline gelangt, laufen die gleichen Prüfungen auf die gleiche Weise ab. Nichts wird übersprungen, weil jemand es vergessen hat. Nichts wird überstürzt, weil eine Deadline naht. Die Pipeline wird nicht müde, lässt sich nicht ablenken und bevorzugt niemanden.
Wenn Ihre Tests gründlich und Ihre Prüfungen korrekt sind, liefern automatisierte Gates eine zuverlässige Basis. Jede Änderung, die diese Gates passiert, erfüllt einen Mindeststandard. Sie müssen nicht raten, ob jemand Abkürzungen genommen oder einen Schritt ausgelassen hat.
Automatisierte Gates skalieren auch. Ein Team von fünf Entwicklern kann vielleicht jede Änderung manuell überprüfen. Ein Team von fünfzig kann das nicht. Die Pipeline kann Hunderte von Prüfungen in Minuten durchführen, während ein menschlicher Prüfer Stunden für die gleiche Arbeit bräuchte.
Wo automatisierte Gates an ihre Grenzen stoßen
Aber automatisierte Gates haben einen blinden Fleck. Sie können nur das prüfen, wofür Sie sie programmiert haben. Sie können die Stimmung im Team oder den Zustand der Produktion nicht erfassen. Sie können keine Entscheidung auf der Grundlage von Erfahrung treffen.
Eine Pipeline kann überprüfen, ob alle Komponententests bestanden werden. Sie kann Ihnen nicht sagen, ob diese bestimmte Änderung während des Black-Friday-Verkehrs sicher bereitgestellt werden kann. Sie kann prüfen, ob Ihr Datenbank-Migrationsskript ohne Syntaxfehler läuft. Sie kann Ihnen nicht sagen, ob es eine schlechte Idee ist, diese Migration um 15 Uhr an einem Dienstag auszuführen.
Automatisierte Gates sind hervorragend darin, die Frage zu beantworten: „Erfüllt dies die technischen Kriterien?“ Sie sind schrecklich darin, die Frage zu beantworten: „Sollten wir das jetzt tun?“
Wann Sie einen Menschen brauchen
Hier kommen manuelle Freigaben ins Spiel. Menschen können Faktoren berücksichtigen, die kein Test erfassen kann:
Ist dies der richtige Zeitpunkt für die Bereitstellung? Vielleicht ist die Produktion bereits instabil. Vielleicht ist gerade eine große Marketingkampagne gestartet. Vielleicht bearbeitet der Bereitschaftsingenieur gerade einen Vorfall und sollte nicht durch eine Bereitstellung abgelenkt werden.
Erfordert diese Änderung Koordination? Vielleicht betrifft die Bereitstellung den Dienst eines anderen Teams. Vielleicht muss das Datenbankteam über eine Schemaänderung informiert werden. Vielleicht möchte das QA-Team vor der Auslieferung der Änderung einen letzten Smoke-Test durchführen.
Ist das Risiko akzeptabel? Ein kleiner Bugfix kann an einem Freitagnachmittag sicher bereitgestellt werden. Ein größeres Refactoring vielleicht nicht. Ein Mensch kann das Risiko basierend auf Erfahrung und Kontext abwägen.
Manuelle Freigaben schaffen auch Verantwortlichkeit. Wenn jemand eine Bereitstellung genehmigt, setzt er seinen Namen darauf. Es geht nicht um Schuldzuweisungen. Es geht darum, eine klare Aufzeichnung zu haben, dass jemand die Änderung überprüft und eine bewusste Entscheidung getroffen hat. Wenn etwas schiefgeht, kann das Team zurückblicken und verstehen, was vor der Bereitstellung bedacht wurde.
Wie man zwischen ihnen entscheidet
Die häufigste Frage ist: Welche Prüfungen sollten automatisiert werden und welche sollten einen Menschen erfordern?
Die Antwort hängt von der Art der Prüfung ab. Technische Validierungen, die kodifiziert werden können, sollten automatisierte Gates sein. Tests, Sicherheitsscans, Linting, Formatprüfungen, Abhängigkeitsaudits – all das sind Dinge, die eine Maschine schneller und konsistenter erledigen kann als ein Mensch.
Entscheidungen, die Urteilsvermögen, Kontext oder Koordination erfordern, sollten manuelle Freigaben sein. Zeitliche Entscheidungen, Risikobewertungen, teamübergreifende Koordination und Bewertungen der geschäftlichen Auswirkungen sollten am besten Menschen überlassen werden.
Aber es gibt eine Nuance. Nur weil etwas automatisiert werden kann, heißt das nicht, dass es ein Gate sein sollte. Einige Prüfungen sind als Information nützlich, aber nicht als Hindernis. Zum Beispiel könnten Sie einen Leistungstest durchführen und die Ergebnisse protokollieren, aber die Pipeline nicht blockieren, wenn die Ergebnisse etwas schlechter als erwartet sind. Das ist eine Ermessensentscheidung, die ein Mensch treffen muss.
Sie arbeiten zusammen, nicht gegeneinander
Automatisierte Gates und manuelle Freigaben sind keine konkurrierenden Ansätze. Sie ergänzen sich gegenseitig. Die Pipeline übernimmt die sich wiederholenden, konsistenten, technischen Prüfungen. Menschen übernehmen die kontextbezogenen, situativen, urteilsbasierten Entscheidungen.
Eine gute Pipeline verwendet automatisierte Gates, um offensichtliche Probleme frühzeitig auszufiltern. Wenn eine Änderung einen manuellen Freigabeschritt erreicht, hat sie bereits eine Reihe von Qualitätsprüfungen bestanden. Der menschliche Prüfer muss sich keine Sorgen machen, ob der Code kompiliert oder die Tests bestanden werden. Er kann sich auf die schwierigeren Fragen konzentrieren: Ist dies das Richtige, zu diesem Zeitpunkt, in diesem Kontext?
Eine praktische Checkliste
Wenn Sie die Kontrollpunkte Ihrer Pipeline entwerfen, stellen Sie sich diese Fragen:
- Kann diese Prüfung vollständig in Code definiert werden? Wenn ja, automatisieren Sie sie.
- Erfordert diese Prüfung Kenntnisse über den aktuellen Produktionszustand? Wenn ja, lassen Sie sie manuell.
- Muss diese Prüfung den Geschäftszeitpunkt oder die Teamkoordination berücksichtigen? Wenn ja, lassen Sie sie manuell.
- Ist diese Prüfung rein technisch und wiederholend? Wenn ja, automatisieren Sie sie.
- Würde die Automatisierung dieser Prüfung wertvolle menschliche Aufsicht entfernen? Wenn ja, lassen Sie sie manuell.
Das Fazit
Automatisierte Gates geben Ihnen Geschwindigkeit und Konsistenz. Manuelle Freigaben geben Ihnen Kontext und Urteilsvermögen. Keines ersetzt das andere. Bauen Sie Ihre Pipeline so, dass sie beide verwendet, und Sie erhalten ein System, das schnell arbeitet, aber die schwierigen Fragen nicht auslässt.