CI/CD Analytics: Wo die Pipeline-Zeit wirklich bleibt

Eine Pipeline ist rot. Oder sie ist grün, hat aber 27 Minuten gebraucht. Man öffnet GitLab, klickt sich durch Jobs und findet irgendwann einen Test, der zweimal gelaufen ist, einen Docker-Build mit acht Minuten Wartezeit und eine Child-Pipeline, die im Gesamtbild fast verschwindet.

Damit ist dieser eine Lauf erklärt. Was weiterhin fehlt, ist die Antwort auf die wichtigere Frage: Wo bleibt unsere Pipeline-Zeit eigentlich liegen? Nicht heute Morgen, sondern über Wochen. Nicht in einem Job, sondern über Projekte, Runner und Merge Requests hinweg. Und nicht nur als Summe, sondern so, dass aus einem auffälligen Wert wieder ein konkreter Lauf wird, den jemand untersuchen kann.

Im Artikel Never Release to Test war diese Arbeit eine forensische Einmalanalyse. Wir haben Pipeline-Läufe exportiert, klassifiziert und daraus Massnahmen abgeleitet. Das war wertvoll, und gerade deshalb unbefriedigend. Eine Diagnose, die erst nach einem Vorfall von Hand gebaut wird, ist kein Instrument. Sie ist ein Bericht.

Mit den CI/CD Analytics in Workbench haben wir aus dieser Untersuchung eine Produktsicht gemacht.

Drei Ansichten, eine Untersuchung

Die Navigation beginnt nicht bei einer Liste von Pipelines, sondern bei drei Fragen, die aufeinander aufbauen.

Waste & Reliability fragt, wo Runner-Zeit verbraucht wurde und wie viel davon in fehlgeschlagenen oder abgebrochenen Versuchen endete. Die Ansicht trennt erfolgreiche, fehlgeschlagene und abgebrochene Zeit, zeigt die teuersten Fehlerquellen und misst, welche Gates bereits beim ersten Versuch bestanden haben. Das ist die Lagekarte: Wo lohnt sich eine Untersuchung überhaupt?

Jobs nimmt eine dieser Spuren auf. Pro Jobserie zeigt Workbench Anzahl, Fehler, gesamte und fehlgeschlagene Laufzeit, P50 und P95 sowie die typische Wartezeit vor dem Start. Ein Vergleich stellt das gewählte Zeitfenster dem unmittelbar vorhergehenden, gleich langen Fenster gegenüber. Der Trend beantwortet damit nicht nur «ist dieser Job langsam?», sondern «wird er langsamer?».

Pipelines und Merge Requests führen schliesslich zum einzelnen Lauf. Eine Pipeline wird als Wasserfall aus Parent- und Child-Pipeline gezeigt, Jobs liegen auf einer gemeinsamen Zeitachse. Beim Merge Request stehen die verschiedenen Versuche nebeneinander: der erste Fehler, ein Retry auf demselben Commit oder ein späterer Erfolg mit neuem Code.

Ein Aggregat ist erst dann handlungsfähig, wenn es einen Weg zurück zum konkreten Lauf besitzt.

Die drei Ansichten sind deshalb keine getrennten Dashboards. Sie sind die Zoomstufen derselben Untersuchung: verlorene Zeit, betroffene Jobserie, konkreter Pipeline-Versuch.

Eine Zahl ist immer auch eine Regel

Die Oberfläche war nicht der schwierige Teil. Der schwierige Teil war festzulegen, was die Zahlen bedeuten. «Fehlerrate» klingt objektiv, bis eine Pipeline abgebrochen wird, ein nicht blockierender Check rot ist oder derselbe Commit beim zweiten Versuch durchläuft.

Workbench macht diese Regeln explizit:

• Nur erfolgreiche und fehlgeschlagene Versuche gehen in die Outcome-Rate ein. Ein abgebrochener Lauf hat Rechenzeit verbraucht, aber kein Ergebnis geliefert.
• Fehlgeschlagene und abgebrochene Jobs zählen als verlorene Runner-Zeit. Die Rechnung verschweigt also nicht, was wegen eines neueren Commits oder eines manuellen Abbruchs aufgegeben wurde.
• Blockierende und nicht blockierende Checks bleiben getrennte Reihen. Wer ein Gate auf allow_failure stellt, darf dadurch keine scheinbare Verbesserung der Zuverlässigkeit erzeugen.
• Ein Job gilt nur dann als flaky, wenn derselbe Job auf demselben Commit sowohl scheitert als auch erfolgreich ist. Ein Fehler auf SHA A und Erfolg auf SHA B ist kein Flake; dazwischen hat sich der Code geändert.
• Rework liegt vor, wenn eine fehlgeschlagene Merge-Request-Pipeline erst auf einem anderen SHA erfolgreich wird. Ein Retry desselben Commits ist etwas anderes.
• Unter 20 Beobachtungen markiert Workbench die Aussage als wenig belastbar, statt eine kleine Stichprobe mit derselben Autorität wie eine lange Serie zu zeichnen.
• GitLabs gemeldete Dauer ist massgebend. Fehlt eine Queue-Zeit, wird keine scheinbar präzise Ersatzgrösse erfunden.

Das klingt pedantisch. Es ist aber der Unterschied zwischen einer Kennzahl und einer Behauptung. Ein Diagramm kann auf zwei Dezimalstellen genau sein und trotzdem die falsche Frage beantworten.

Ruhige Tage sind ebenfalls Daten

Diese Genauigkeit endet nicht bei der Abfrage. Sie gilt auch für die Darstellung.

Unsere erste Trendansicht zeichnete nur Buckets, in denen tatsächlich Versuche lagen. Ein Zeitfenster von 90 Tagen mit Aktivität an vier Tagen bekam deshalb eine Achse mit vier Kategorien. Das sah ordentlich aus und war fachlich zweideutig: Waren 86 Tage ruhig, oder besassen wir schlicht nur vier Tage Historie?

Heute liefert der Server die vollständige Bucket-Liste für das gewählte Fenster. Tage ohne Versuche bleiben als Lücke sichtbar. Erst dadurch wird Abwesenheit zu Information.

Die Buckets entstehen serverseitig in einer UTC-Datenbanksitzung. Würden Server und Browser dieselbe zeitliche Gruppierung getrennt implementieren, hätten wir zwei Definitionen, die bei einem Sommerzeitwechsel um eine Stunde auseinanderlaufen können. Das Frontend zeichnet deshalb die Zeitachse, die mit den Zahlen zusammen berechnet wurde.

Status muss Bedeutung tragen

Beim ersten Produktionseinsatz fiel eine zweite Form von Mehrdeutigkeit auf. Erfolgreiche, fehlgeschlagene und manuelle Jobs trugen zwar unterschiedliche Wörter, sahen aber nahezu gleich aus. Die CI-Navigation wirkte wie eine Linkleiste, Tabellenköpfe und Werte standen nicht auf einer Linie, und ein nicht blockierender Fehler sah aus wie ein kaputter Build.

Das sind keine kosmetischen Details. In einer Analytics-Oberfläche ist visuelle Hierarchie Teil der Semantik.

Status-Badges tragen ihre Bedeutung heute sichtbar: Erfolg, Fehler, manuell und übersprungen sind unterscheidbar; ein fehlgeschlagenes allow_failure erscheint als Hinweis, nicht als gebrochene Pipeline. Die aktive Ansicht liest sich als Tab. Zahlen stehen unter ihren Überschriften. Und jedes Diagramm behält eine tabellarische Repräsentation, damit seine Aussage nicht von Farbe, Maus oder Sehvermögen abhängt.

Lesbarkeit ist bei Analytics keine Politur nach der eigentlichen Arbeit. Eine missverständliche Darstellung ist eine falsche Antwort mit richtigen Daten darunter.

Vom Signal zum konkreten Lauf

Eine Rangliste der teuersten Jobserien erzeugt Aufmerksamkeit. Sie erzeugt noch keine Handlung. Dafür muss die Person, die den Wert sieht, den Lauf finden können, der ihn verursacht hat.

Workbench verbindet deshalb die Ebenen. Aus einer Jobserie führt der Weg in ihren Trend und Vergleich. Eine Pipeline zeigt Parent und direkte Child-Pipelines als gemeinsamen Wasserfall. Der Merge-Request-Drilldown gruppiert die Versuche, sodass sichtbar wird, ob derselbe Commit nur erneut lief oder ob ein neuer Commit die Situation veränderte. Pipeline und einzelne Job-Versuche verlinken von dort zurück nach GitLab.

Auch die Adresse eines Pipeline-Laufs folgt dieser Regel. Die erste Version verwendete die interne Datenbank-ID in der URL. Das war für die Anwendung bequem, für eine lesende Person bedeutungslos und über Mandanten hinweg aufzählbar. Heute besitzen Pipeline-Läufe und Job-Versuche öffentliche UUIDs; die API gibt die internen IDs gar nicht mehr aus.

Eine UUID ersetzt keine Autorisierung. PostgreSQL Row Level Security bleibt die Mandantengrenze und verhindert, dass ein Workspace die Daten eines anderen erreicht. Die UUID sorgt für etwas anderes: Eine öffentliche Adresse verrät keine interne Tabellenposition und bleibt ein eigener Vertrag statt ein zufälliges Implementierungsdetail.

Welche Daten Workbench bewusst nicht sammelt

CI-Historie ist eine Ausnahme in Workbench. Work Items, Merge Requests und Milestones bilden wir als wegwerfbare Projektion aus GitLab ab. Analytics braucht dagegen Geschichte: Ein Job, der heute langsam ist, wird erst im Vergleich mit den letzten Wochen interessant.

Diese Ausnahme ist begrenzt. Standardmässig behält Workbench 400 Tage und speichert nur, was für die Auswertung notwendig ist:

• Zeitstempel, Dauer und Queue-Zeit, soweit GitLab sie liefert
• Status und Failure Reason
• Jobname und Stage
• Runner-Identität und Tags
• die Zuordnung zu Pipeline, Projekt, Commit und Merge Request

Nicht gespeichert werden Job-Traces und Logs, Artefakte, CI/CD-Variablen oder Commit-Nachrichten. Die Analytics sollen zeigen, wo eine Untersuchung beginnen sollte; sie werden nicht zu einem zweiten Archiv für den Inhalt der CI.

Weitere Grenzen bleiben sichtbar. Die Pipeline-Dauer wird aus dem frühesten Start und dem spätesten Ende ihrer Jobs abgeleitet und enthält nicht jede GitLab-interne Wartephase. Ein umbenannter Job beginnt eine neue Serie, weil der Name seine Identität im Vergleich ist. Und Workbench kann nur Projekte auswerten, die in den jeweiligen Workspace aufgenommen und nicht von der Erfassung ausgeschlossen wurden.

Was wir behalten würden

Drei Regeln aus diesem Bau reichen über CI/CD Analytics hinaus:

• Analytics beginnt mit Definitionen. Ohne explizite Zählregeln sind präzise Diagramme nur präzise dargestellte Mehrdeutigkeit.
• Ein Aggregat braucht einen Drilldown. Ein Signal wird erst handlungsfähig, wenn es bis zum konkreten Versuch zurückverfolgt werden kann.
• Lesbarkeit gehört zur Korrektheit. Vollständige Zeitachsen, semantische Statusdarstellung und öffentliche Identitäten sind kein Dekor um die Daten, sondern bestimmen, was Menschen darin erkennen.

Damit lässt sich die Ausgangsfrage beantworten. Workbench zeigt nicht nur, dass CI Zeit verbraucht. Es zeigt, wo sie verloren ging, ob ein instabiler Job, ein realer Fehler oder neuer Code dahinterstand, und in welchem konkreten Pipeline-Lauf die Untersuchung weitergeht.