Dein Blog zum Thema digitales Business

Die falsche Frage zuerst

Wie oft deployst du? Diese Frage klingt nach einer Geschwindigkeitsfrage, ist aber meistens die falsche Frage. Die richtige lautet: Wie groß ist die Änderung, die mit jedem Deployment live geht? Deploy-Frequenz und Batch-Size sind zwei Seiten derselben Münze. Wer selten deployt, packt zwangsläufig mehr in jedes Deployment. Wer häufig deployt, deployt zwangsläufig kleinere Häppchen. Die Frequenz ist nur das sichtbare Symptom, die Batch-Size ist die eigentliche Stellschraube, und an ihr hängt das Risiko, nicht an der Anzahl der Releases pro Woche.

Was eine kleinere Änderungseinheit tatsächlich verändert

Eine kleine Änderung betrifft weniger Code, weniger Konfiguration und weniger Abhängigkeiten gleichzeitig. Das wirkt sich an mehreren Stellen aus. Ein Review über 40 geänderte Zeilen findet Probleme, die in einem Review über 2.000 Zeilen untergehen, weil Reviewer nach einer bestimmten Menge Diff anfangen, nur noch zuzustimmen statt zu lesen. Ein Fehler in einer kleinen Änderung lässt sich eingrenzen, weil es nur wenige Verdächtige gibt, die ihn verursacht haben können. Und der Blast Radius, also der Teil des Systems, der bei einem fehlerhaften Deployment tatsächlich betroffen ist, bleibt kleiner, wenn die Änderung selbst kleiner ist. Das ist unabhängig davon, wie gut die Rückwegfähigkeit einer Pipeline aussieht (dazu gehört mehr als Rollback, das war Thema eines früheren Beitrags). Hier geht es um etwas Vorgelagertes: um die Größe dessen, was überhaupt zurückgenommen oder repariert werden müsste, falls es schiefgeht.

Wo kleine Batches an ihre Grenze stoßen

Kleiner ist trotzdem nicht automatisch besser. Wer eine Änderung in zehn Einzelschritte zerlegt, die einzeln nicht sinnvoll sind, verlagert den Aufwand nur. Jeder Schritt braucht einen eigenen Review, einen eigenen Testlauf, eine eigene Freigabe, und wenn dazwischen Abstimmung mit anderen Teams nötig ist, wächst der Koordinationsaufwand schneller als der Sicherheitsgewinn. Ein Datenbankschema-Wechsel, der in zu kleine Teilschritte zerschnitten wird, kann zwischenzeitlich Zustände erzeugen, die inkonsistenter sind als eine einzige, gut vorbereitete Migration. Kleinteiligkeit ist ein Werkzeug gegen Risiko, kein Selbstzweck. Ab einem bestimmten Punkt kostet weiteres Zerkleinern mehr an Overhead, als es an Blast Radius einspart.

Die Kennzahl, die zählt

Deploy-Frequenz allein sagt nichts über Qualität aus. Ein Team, das täglich deployt, aber jedes dritte Deployment einen Incident auslöst, ist nicht schneller unterwegs als eines, das wöchentlich deployt und praktisch nie ausfällt, es ist nur öfter im Feuerlöschmodus. Genau deshalb steht neben der Deploy-Frequenz im DORA-Metrikrahmen eine zweite, unabhängige Kennzahl: die Change Failure Rate, der Anteil der Deployments, der zu einem Ausfall, einer Verschlechterung oder einer Notfallkorrektur führt. Erst im Zusammenspiel der beiden Kennzahlen wird eine Deploy-Häufigkeit aussagekräftig. Eine hohe Frequenz bei niedriger Change Failure Rate ist ein Team, das kleine, beherrschbare Einheiten ausliefert. Eine hohe Frequenz bei hoher Change Failure Rate ist ein Team, das lediglich häufiger stolpert.

Batch-Size an Fähigkeit koppeln, nicht an den Kalender

Der praktische Fehler ist, Deploy-Rhythmus als Kalenderfrage zu behandeln: einmal pro Sprint, jeden Freitag, einmal im Monat. Ein fester Rhythmus ignoriert, wovon das Risiko tatsächlich abhängt. Zwei Fragen sind aussagekräftiger als jeder Kalendereintrag. Erstens: Wie viel von der Änderung ist automatisiert geprüft, bevor ein Mensch sie sieht? Eine Änderung mit hoher Testabdeckung darf größer und seltener sein, weil ein großer Teil der möglichen Fehler schon vor dem Deployment auffliegt. Zweitens: Wie sicher ist der Rückweg, falls es doch schiefgeht? Je unsicherer die Fähigkeit, eine Änderung schnell zurückzunehmen, desto kleiner sollte die Änderungseinheit sein, die im Fehlerfall betroffen wäre. Beide Fragen zusammen ergeben eine Batch-Size, die zur tatsächlichen Reife der Pipeline passt, statt zu einem Termin im Kalender. Das ist der Kern: Deploy-Frequenz ist eine Folge, keine Zielgröße. Die Zielgröße ist die Änderungseinheit, die ein Team beherrschen kann, ohne dass ein einzelner Fehler größer wird als nötig.

Ob es um die Einrichtung oder Überarbeitung einer Pipeline geht, um Stellen, an denen KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen, oder um die Frage, wem ein System nach dem Go-Live eigentlich gehört und woran man merkt, dass es niemandem mehr gehört: das sind die Felder, in denen wir arbeiten. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Schreib mir an mm@mhm-dl.de.