Der Build wird zum Engpass: was nach dem KI-Rollout in der Pipeline passiert
Nach einem Rollout verschiebt sich der Engpass. Erst auf den Review, das ist bekannt. Danach, sobald die Prüfung automatisiert ist, auf die Pipeline — und dieser zweite Schritt überrascht regelmäßig, weil die Pipeline vorher nie ein Problem war.
Nach der Automatisierung der Prüfung wandert der Engpass auf die Pipeline. Bei zweihundert Änderungen pro Woche und zwanzig Minuten Laufzeit entstehen Warteschlangen, und Wartezeit kostet Aufmerksamkeit statt nur Rechenzeit. Lange Wartezeiten führen dazu, dass Änderungen größer werden — genau die Kennzahl, die gesenkt werden sollte. Drei Hebel in dieser Reihenfolge: Testauswahl nach betroffenen Bereichen, Wiederverwendung von Zwischenergebnissen, gestaffelte Ausführung mit schneller Rückmeldung zuerst. Beobachtet wird die Zeit von Einreichung bis Rückmeldung inklusive Warteschlange.
Warum die Rechnung kippt
Bei zweihundert Änderungen pro Woche und einer Pipeline von zwanzig Minuten sind das rund siebzig Stunden Rechenzeit — machbar, solange parallel gearbeitet werden kann. Sobald Läufe aufeinander warten, weil sie dieselbe Umgebung brauchen oder die Kapazität begrenzt ist, entsteht eine Warteschlange, und Wartezeit ist teurer als Rechenzeit: Sie kostet Aufmerksamkeit.
Der Effekt, den niemand einplant
Lange Wartezeiten ändern das Verhalten. Wer zwanzig Minuten auf Rückmeldung wartet, wechselt in der Zwischenzeit die Aufgabe, kommt mit Verzögerung zurück und macht dann größere Änderungen, um weniger Läufe zu brauchen. Damit steigt die Änderungsgröße — und die ist die Kennzahl, die man gerade senken wollte.
Die drei Hebel, in dieser Reihenfolge
Erstens: Nur ausführen, was betroffen ist. Testauswahl nach geänderten Bereichen statt alles bei jeder Änderung. Das ist der größte Hebel und in den meisten Pipelines nicht umgesetzt. Zweitens: Zwischenergebnisse wiederverwenden statt jedes Mal neu zu bauen. Drittens: Staffeln — schnelle Prüfungen zuerst mit Rückmeldung in Minuten, langsame danach und parallel.
Was man nicht tun sollte
Tests abschalten, um Zeit zu sparen. Das ist der naheliegende und teuerste Weg, weil er genau die Absicherung entfernt, auf der das Modell beruht. Wenn die Pipeline zu langsam ist, ist die Pipeline das Problem, nicht der Testumfang.
Die Zahl, die man beobachten sollte
Nicht die Laufzeit allein, sondern die Zeit von der Einreichung bis zur Rückmeldung — inklusive Wartezeit in der Warteschlange. Diese Zahl unterscheidet sich in ausgelasteten Systemen erheblich von der reinen Laufzeit, und nur sie beschreibt, was Entwickelnde tatsächlich erleben.
Häufige Fragen
Wie schnell sollte eine Pipeline sein?
Für die schnelle Stufe unter zehn Minuten bis zur ersten belastbaren Rückmeldung; langsamere Prüfungen dürfen danach laufen. Entscheidend ist nicht die Gesamtlaufzeit, sondern wann jemand weiß, ob es sich lohnt weiterzuarbeiten.
Was ist Testauswahl nach betroffenen Bereichen?
Es werden nur die Tests ausgeführt, die von den geänderten Dateien abhängen — ermittelt über Abhängigkeiten oder Abdeckungsdaten. In großen Codebasen reduziert das die Laufzeit oft um den größten Teil, ohne die Aussagekraft zu senken.
Darf man Tests bei dringenden Änderungen überspringen?
Als dokumentierte Ausnahme mit Name, Grund und Nachlauf, nicht als Praxis. Sobald das Überspringen zur Gewohnheit wird, ist das Modell aufgehoben — und zwar genau in den Fällen mit dem höchsten Zeitdruck, also den riskantesten.
Wie hängen Build-Zeit und Änderungsgröße zusammen?
Direkt: Lange Wartezeiten belohnen große Änderungen, weil sie die Zahl der Läufe senken. Wer kleine Änderungen will, muss die Rückmeldung schnell machen — sonst arbeitet die Pipeline gegen das eigene Ziel.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Angaben, fünf Minuten. Ihre Zahlen, kein Login.
Engineering-Check starten →
