Eine langsame CI-Pipeline repariert man am schnellsten über die QA statt mit mehr Hardware
Wenn Ihre CI-Pipeline fast eine Stunde braucht, hören Sie jedes Mal dieselben drei Dinge: mehr Runner hinzufügen, bessere Hardware draufwerfen, alles cachen, was sich nicht bewegt.
Manchmal funktioniert das. Sehr oft macht es ein ohnehin schon unordentliches System nur geringfügig schneller darin, frustrierend zu sein. Das eigentliche Problem sitzt meist an einer weniger aufregenden Stelle, nämlich in der QA.
So war es bei einem Team, dessen Pipeline im Schnitt 58 Minuten von Anfang bis Ende brauchte. Auf dem Papier sah nichts besonders kaputt aus, denn Builds und Deploy-Schritte liefen einwandfrei. Der Flaschenhals saß eindeutig in den automatisierten Tests und fraß unbemerkt 42 Minuten aus jedem Durchlauf.
Sie deployten etwa zehnmal am Tag. Rechnet man das durch, wird schnell klar, was diese Art von Latenz mit einem Team macht: ständige Kontextwechsel, PRs, die sich stapeln, und Leute, die Änderungen pushen und weggehen, weil „die CI sowieso eine Weile braucht“.
Einen Monat später braucht dieselbe Pipeline im Schnitt nur noch 14 Minuten. Entwickler warten wieder darauf und vertrauen den Ergebnissen. Schnellere Maschinen oder exotisches Tooling spielten bei den größten Gewinnen keine Rolle. Die kamen aus einer ehrlichen Antwort auf die Frage, wofür Tests eigentlich da sind und wann man sie tatsächlich braucht.
Lange Pipelines verändern das Verhalten im Team
Langsame CI hat einen psychologischen Preis, der selten in Dashboards auftaucht.
Wenn Feedback eine Stunde braucht, hören Entwickler auf, sich in Echtzeit darum zu kümmern. Sie öffnen einen PR, starten die Pipeline und widmen sich etwas anderem. Wenn sie fehlschlägt, fühlt sich der Fehler losgelöst von der Änderung an, die ihn verursacht hat. So werden kaputte Tests ohne Untersuchung erneut ausgeführt oder, schlimmer noch, ignoriert.
Mit der Zeit passen sich Teams auf ungesunde Weise an. Leute bündeln Änderungen, damit sich „das Warten lohnt“. Sie mergen spät am Tag und hoffen, dass über Nacht nichts explodiert. Sie behandeln CI als Formalität statt als Sicherheitsnetz.
Die Ironie ist, dass dieses Verhalten Pipelines langsamer und instabiler macht, was den Kreislauf verstärkt. QA wird zu etwas, das dem Code widerfährt, statt etwas, das ihm hilft.
Nicht alle Tests verdienen dieselbe Behandlung
Die erste große Veränderung, die dieses Team vornahm, war intern auch die umstrittenste. Sie hörten auf, so zu tun, als müsste jeder Test bei jedem Pull Request laufen, und teilten ihre Test-Suite in zwei klare Stufen auf.
Die kritische Suite läuft bei jedem PR. Sie deckt Authentifizierung, Zahlungen und die zentralen User-Flows ab, deren Ausfall katastrophal wäre. Bei effizienter Ausführung dauert sie etwa sieben Minuten. Schlägt diese Suite fehl, wird nichts ausgeliefert.
Die vollständige Suite existiert weiterhin, sie liegt nur nicht mehr im Hot Path. Sie läuft nachts und auf Release-Branches, wo es sich lohnt, die zusätzliche Zeit für das Aufspüren obskurer Randfälle zu investieren.
Das Ziel war, die Feedback-Geschwindigkeit am Risiko auszurichten, ohne die Qualität zu senken. Die meisten Änderungen berühren nicht die tiefsten Winkel des Systems. Jeden Entwickler bei jedem Commit auf eine erschöpfende Abdeckung warten zu lassen, macht Software nicht sicherer, es macht Teams nur langsamer und zynischer. Sobald dieser Denkwandel saß, ließ sich alles andere leichter rechtfertigen.
Parallelisierung ist offensichtlich, bis sie es nicht mehr ist
Jeder weiß, dass parallele Tests schneller sind. Sie tatsächlich zum Laufen zu bringen, ist eine andere Geschichte.
Die kritische Suite lief ursprünglich seriell, was bedeutete, dass jeder Test die Sünden aller vorherigen Tests erbte. Ein langsamer Setup-Schritt konnte sich durch den gesamten Durchlauf ziehen. Indem sie die Suite auf sechs Runner aufteilten, halbierte das Team die Ausführungszeit fast sofort, und das war auf dem Papier der größte Einzelgewinn.
Aber Parallelität hat scharfe Kanten. Tests, die sich Daten teilen, auf globalem State beruhen oder Annahmen über die Ausführungsreihenfolge treffen, brechen tendenziell zusammen, wenn sie nebeneinander laufen. Das zu beheben erforderte, das Testdesign selbst anzufassen, nicht nur die CI-Konfiguration.
Jeder Test musste für sein eigenes Setup und Cleanup verantwortlich sein. Gemeinsam genutzte Ressourcen brauchten Isolation. Ein paar Tests, die seriell „okay“ waren, entpuppten sich als heimlich brüchig. Das war echte Arbeit, und sie zahlte sich über die reine Geschwindigkeit hinaus aus, weil Tests, die parallel laufen können, meist einfach die besseren Tests sind.
Flaky Tests sind schlimmer als langsame
Wenn langsame Pipelines Entwicklern beibringen, CI zu ignorieren, bringen flakige Pipelines ihnen bei, ihr nicht zu glauben.
Vor der Überarbeitung waren etwa 18 Prozent der Fehlschläge False Positives: zufällige Timing-Probleme, UI-Tests, die fehlschlugen, weil ein Button ein paar Millisekunden zu spät gerendert wurde, und Fehler, die beim erneuten Ausführen einfach verschwanden. Diese Zahl ist brutal, weil sie bedeutet, dass Entwickler darauf konditioniert sind, in fast jedem fünften Fall davon auszugehen, dass CI sie anlügt.
Das Team ging das direkt an, indem es die schlimmsten Übeltäter ersetzte. Einige Legacy-Browsertests wurden mit stabileren Tools neu geschrieben. Andere wurden komplett neu gedacht, weg von brüchigen UI-Checks hin zu Ansätzen, die Verhalten validierten, ohne Pixel-genaue Präzision zu verlangen.
Das Ergebnis war keine Perfektion, aber es war drastisch. Falsche Fehlschläge sanken auf etwa drei Prozent. Diese Änderung allein sparte wahrscheinlich mehr Entwicklerzeit als die reinen Geschwindigkeitsverbesserungen.
Auto-Retry ist kein Schummeln, wenn man ehrlich damit umgeht
Eine der pragmatischeren Entscheidungen war, automatische Retries für einzelne fehlgeschlagene Tests einzuführen. Schlägt ein Test einmal fehl und besteht beim Retry, blockiert die Pipeline den PR nicht, markiert den Test aber, sodass nichts unter den Teppich gekehrt wird.
Dieser Ansatz erkennt die Realität an. Manche Fehlschläge sind wirklich zufällig, Infrastruktur-Aussetzer passieren, und Timing-Probleme schleichen sich selbst bei gut designten Tests ein.
Der Schlüssel ist Rechenschaftspflicht. Wiederholte Tests werden getrackt und überprüft, Muster zeigen sich schnell, und Tests, die häufige Retries brauchen, werden zu Kandidaten für Fixes oder Entfernung. Der Retry-Mechanismus wird so zum Diagnosewerkzeug statt zur Krücke.
Ohne diese Nachverfolgung können Retries echte Regressionen definitiv verstecken. Mit ihr reduzieren sie Rauschen, während sie das System trotzdem in Richtung Stabilität drängen.
Geschwindigkeit veränderte Vertrauen, und Vertrauen veränderte alles andere
Sobald die Pipeline zuverlässig in etwa 14 Minuten durchlief, passierte etwas Subtiles, aber Wichtiges: Entwickler fingen wieder an, auf CI zu warten.
Sie öffneten einen PR und sahen den Checks tatsächlich beim Durchlaufen zu. Wenn etwas fehlschlug, fühlte es sich unmittelbar und handhabbar an. Einen kaputten Test zu fixen bedeutete nicht mehr, eine Stunde Momentum zu verlieren.
Dieses Vertrauen hatte Folgewirkungen: kleinere PRs, häufigere Deploys und weniger Versuchung, riskante Änderungen spät am Tag zu pushen. Die Pipeline hörte auf, ein Hindernis zu sein, und fühlte sich stattdessen wie Teil des Workflows an.
Das machte auch Gespräche mit dem Management einfacher. Eine schnelle, zuverlässige Pipeline lässt sich leichter rechtfertigen als eine teure, die trotzdem alle frustriert.
Teurer als Compute war der Fokus
Der gesamte Aufwand dauerte etwa einen Monat, nicht weil die Ideen komplex waren, sondern weil sie anhaltende Aufmerksamkeit über Tooling, Tests und Teamgewohnheiten hinweg erforderten.
Das ist der Teil, den viele Organisationen unterschätzen. Schnellere Runner zu kaufen ist einfach. Zeit freizuschaufeln, um Testdesign zu reparieren, Flakiness zu reduzieren und die QA-Strategie zu überdenken, ist schwerer. Es konkurriert mit Feature-Arbeit und liefert nichts, was für Kunden sichtbar ist.
Und trotzdem ist der Return on Investment enorm. Schnellere Feedback-Loops sparen Minuten und mentale Energie, reduzieren Reibung und sorgen dafür, dass sich Engineering weniger wie Warten und mehr wie Bauen anfühlt.
Zuerst QA reparieren, dann um alles andere kümmern
Wenn Ihre CI-Pipeline langsam ist, ist es verlockend, bei der Infrastruktur anzufangen: hochskalieren, Caches optimieren, Sekunden von Builds abknapsen.
Aber wenn QA Ihre Laufzeit dominiert, liegt dort der eigentliche Hebel. Fragen Sie, welche Tests wirklich laufen müssen, welche flakig sind und warum, und ob Ihre Test-Suite widerspiegelt, wie Ihr Team heute Software ausliefert oder wie es das vor drei Jahren tat. Die meisten Teams haben am Ende weniger ein Tooling-Problem als ein Vertrauensproblem.
QA zu reparieren macht Ihre Pipeline schneller und sie wieder der Aufmerksamkeit wert. Genau dann fängt CI an, den Job zu machen, den sie immer machen sollte.