Dein Blog zum Thema digitales Business

Freigabeprozesse haben in vielen Teams einen schlechten Ruf. Sie gelten als das, was zwischen fertigem Code und Produktion steht: ein Ticket, das jemand abzeichnen muss, ein Meeting, das erst am Donnerstag stattfindet, eine Person, die gerade im Urlaub ist. Die Schlussfolgerung liegt dann nahe, dass Kontrolle und Geschwindigkeit sich ausschließen. Das stimmt nicht. Die Bremswirkung kommt fast nie aus der Freigabe selbst, sondern aus ihrer Bauweise.

Woher die Bremswirkung wirklich kommt

Ein langsamer Freigabeprozess hat meist drei Ursachen, und keine davon ist die Kontrolle an sich. Erstens hängt die Freigabe an einer einzelnen Person, die alles prüfen soll und deren Verfügbarkeit zum Flaschenhals wird. Zweitens prüft ein Mensch Dinge, die eine Maschine schneller und zuverlässiger prüfen würde: ob Tests grün sind, ob das Artefakt signiert ist, ob keine Secrets im Diff liegen. Drittens ist unklar, was überhaupt bewertet werden soll, weshalb jede Freigabe zur Einzelfallentscheidung wird. Wer diese drei Punkte trennt, bekommt Tempo zurück, ohne die Kontrolle aufzugeben.

Freigabe an den Build koppeln, nicht an eine Person

Der erste Schritt ist, die Freigabe an einen Zustand zu binden statt an eine Unterschrift. Ein Release ist freigabefähig, wenn definierte Bedingungen erfüllt sind: die Pipeline ist durchgelaufen, die Prüfungen sind bestanden, die Herkunft des Artefakts ist belegt. Diese Bedingungen prüft die Pipeline selbst, bei jedem Durchlauf, ohne dass jemand darauf wartet. Die menschliche Freigabe entscheidet dann nicht mehr, ob technisch alles in Ordnung ist, sondern ob dieses Release jetzt raus soll. Das sind zwei verschiedene Fragen, und nur die zweite braucht wirklich einen Menschen.

Was automatisch prüfbar ist, gehört nicht in ein Meeting

Alles, was sich als Regel formulieren lässt, sollte als Regel in der Pipeline stehen und nicht auf einer Checkliste, die jemand manuell durchgeht. Testabdeckung über einer Schwelle, keine kritischen offenen Schwachstellen, ein Vier-Augen-Review auf dem Merge, ein signiertes Artefakt mit nachvollziehbarer Herkunft. Solche Kriterien sind entweder erfüllt oder nicht, und ein Mensch bringt bei dieser Prüfung keinen Mehrwert, sondern nur Wartezeit. Der Gewinn ist doppelt: die Prüfung passiert bei jedem Commit statt einmal am Ende, und der Prüfer muss nicht mehr im Kopf behalten, was er alles kontrollieren sollte.

Die menschliche Freigabe auf das begrenzen, was nur ein Mensch kann

Bleibt die Frage, was der Freigebende dann noch tut. Er trifft die Entscheidungen, die Kontext brauchen und sich nicht in eine Regel gießen lassen. Passt der Zeitpunkt, oder läuft gerade eine kritische Kampagne, bei der eine Störung teuer wäre. Ist der fachliche Umfang der Änderung wirklich der, der besprochen war. Gibt es einen Grund, dieses eine Mal genauer hinzusehen. Diese Freigabe dauert Minuten, nicht Tage, weil die Person sich darauf verlassen kann, dass die technische Grundlage bereits geprüft ist. Sie liest kein Log und zählt keine Tests, sie entscheidet.

Nachvollziehbarkeit fällt dabei nebenbei ab

Ein so gebauter Prozess produziert seine eigene Dokumentation. Weil die Kriterien in der Pipeline liegen, ist bei jedem Release automatisch festgehalten, was geprüft wurde und mit welchem Ergebnis. Die menschliche Freigabe hinterlässt einen Eintrag, wer wann was freigegeben hat. Niemand muss im Nachhinein rekonstruieren, ob ein Deployment sauber war, weil die Antwort bereits vorliegt. Was bei einem audit-fähigen Freigabeprozess ohnehin gebraucht wird, entsteht hier als Nebenprodukt einer schnelleren Arbeitsweise, nicht als zusätzliche Last.

Die Einsicht dahinter ist einfach. Ein Freigabeprozess bremst, wenn er Menschen Arbeit gibt, die Maschinen besser erledigen, und wenn er die eine Entscheidung, die wirklich zählt, hinter einer Wand aus manueller Prüfung versteckt. Trennt man beides, wird die Freigabe schneller und die Kontrolle stärker, gleichzeitig.

Wenn Sie wissen wollen, wo Ihr eigener Freigabeprozess Zeit verliert und welche Prüfungen sich in die Pipeline verlagern lassen, ist der GitSecOps QuickCheck der schnelle Einstieg. In drei Werktagen prüfen wir Ihre Pipeline auf die entscheidenden Stellen und liefern konkrete Befunde. 1.990 Euro netto. Kontakt: mm@crank.zone.