Der schnellste Weg, eine langsame CI-Pipeline zu reparieren, ist nicht mehr Hardware - sondern die QA zu reparieren
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: 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. Builds liefen einwandfrei. Deploy-Schritte liefen einwandfrei. Der Flaschenhals saß eindeutig in den automatisierten Tests und fraß still 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 stapeln sich. Leute pushen Änderungen und gehen weg, weil "die CI sowieso eine Weile braucht".
Einen Monat später braucht dieselbe Pipeline im Schnitt nur noch 14 Minuten. Entwickler warten wieder darauf. Sie vertrauen den Ergebnissen. Und die größten Gewinne kamen nicht von schnelleren Maschinen oder exotischem Tooling. Sie kamen daher, ehrlich darüber zu sein, wofür Tests eigentlich da sind - und wann man sie tatsächlich braucht.
Lange Pipelines verlangsamen nicht nur Code, sie verändern Verhalten
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.
Die unbequeme Wahrheit: 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.
Stattdessen teilten sie 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.
Dabei ging es nicht darum, Qualität zu senken. Es ging darum, die Feedback-Geschwindigkeit am Risiko auszurichten. 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. 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 Arbeit. Echte Arbeit. Und sie zahlte sich über die reine Geschwindigkeit hinaus aus. Tests, die parallel laufen können, sind meist einfach die besseren Tests, Punkt.
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. Fehler, die beim erneuten Ausführen verschwanden.
Diese Zahl ist brutal. 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. Sie markiert den Test aber. Nichts wird unter den Teppich gekehrt.
Dieser Ansatz erkennt die Realität an. Manche Fehlschläge sind wirklich zufällig. Infrastruktur-Aussetzer passieren. 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. Tests, die häufige Retries brauchen, werden zu Kandidaten für Fixes oder Entfernung. Der Retry-Mechanismus wird 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. 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.
Die wahren Kosten waren nicht Compute - sie waren 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. Es liefert nichts, was für Kunden sichtbar ist.
Und trotzdem ist der Return on Investment enorm. Schnellere Feedback-Loops sparen nicht nur Minuten. Sie sparen mentale Energie. Sie reduzieren Reibung. Sie 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. Fragen Sie, welche flakig sind und warum. Fragen Sie, ob Ihre Test-Suite widerspiegelt, wie Ihr Team heute Software ausliefert, oder wie es das vor drei Jahren tat.
Die meisten Teams haben kein Tooling-Problem. Sie haben ein Vertrauensproblem.
QA zu reparieren macht Ihre Pipeline nicht nur schneller. Es macht sie wieder der Aufmerksamkeit wert. Und genau dann fängt CI an, den Job zu machen, den sie immer machen sollte.