CI-Pipeline-Ergebnisse im Sankey-Diagramm: vom Auslöser zur Fehlerursache
Verfolgen Sie Pipeline-Läufe vom Auslöser zum Ergebnis und zur Ursache jedes Fehlers: instabile Tests, echte Regressionen, Konfiguration und Umgebung. Beispielwerte durch Ihre CI-Historie ersetzen.
Ein Sankey-Diagramm der CI-Pipeline zeigt, wie Builds nach Auslöser enden und warum sie fehlschlagen. Es trennt Fehler, die etwas bedeuten (eine Regression), von denen, die nichts bedeuten (ein instabiler Test).
Das Beispiel hat 900 Pipeline-Läufe aus drei Auslösern: Pushes auf main, Pull Requests und Nightly-Builds. 760 bestehen alle Stufen und 140 scheitern, beim Build (37), bei den Tests (96) oder beim Deployment (7). Die letzte Spalte nennt die Ursache: instabiler Test, echte Regression, Code-Fehler, Abhängigkeit oder Konfiguration sowie Testumgebung.
Die Erfolgsquote verbirgt die Mischung. Im Beispiel sind 35 der 96 Testfehler instabil, was ein Vertrauensproblem der Suite ist, und 45 sind echte Regressionen, also die Pipeline bei der Arbeit. Gezählt werden Läufe, nicht Commits; eine Wiederholung ist also ein Lauf. Die Review-Stufe davor zeigt /de/sankey/pull-request-review-flow, den weiteren Prozess /de/guides/so-finden-sie-engpaesse-im-software-release-prozess.
So liest man dieses Diagramm
- 760 von 900 Läufen (84 %) bestehen alle Stufen; 140 (16 %) scheitern.
- Die Tests sind die häufigste Fehlerstelle: 96 von 140 Fehlern (69 %).
- 35 Fehler sind instabile Tests, 25 % aller Fehler, und 45 sind echte Regressionen.
- Pull-Request-Läufe bestehen zu 82 % (410 von 500), main zu 90 % (270 von 300).
Die Daten dahinter
Erfundene Zahlen zur Veranschaulichung. Keine Daten eines realen Unternehmens, Teams oder Systems.
| Von | Nach | Menge (Pipeline-Läufe) |
|---|---|---|
| Push auf main | Alle Stufen bestanden | 270 |
| Push auf main | Beim Build gescheitert | 8 |
| Push auf main | Bei den Tests gescheitert | 17 |
| Push auf main | Beim Deployment gescheitert | 5 |
| Pull Request | Alle Stufen bestanden | 410 |
| Pull Request | Beim Build gescheitert | 25 |
| Pull Request | Bei den Tests gescheitert | 65 |
| Nightly | Alle Stufen bestanden | 80 |
| Nightly | Beim Build gescheitert | 4 |
| Nightly | Bei den Tests gescheitert | 14 |
| Nightly | Beim Deployment gescheitert | 2 |
| Beim Build gescheitert | Code-Fehler | 15 |
| Beim Build gescheitert | Abhängigkeit oder Konfiguration | 22 |
| Bei den Tests gescheitert | Instabiler Test | 35 |
| Bei den Tests gescheitert | Echte Regression | 45 |
| Bei den Tests gescheitert | Umgebung | 16 |
| Beim Deployment gescheitert | Abhängigkeit oder Konfiguration | 3 |
| Beim Deployment gescheitert | Umgebung | 4 |
Dieselben Daten als CSV
source,target,value
Push auf main,Alle Stufen bestanden,270
Push auf main,Beim Build gescheitert,8
Push auf main,Bei den Tests gescheitert,17
Push auf main,Beim Deployment gescheitert,5
Pull Request,Alle Stufen bestanden,410
Pull Request,Beim Build gescheitert,25
Pull Request,Bei den Tests gescheitert,65
Nightly,Alle Stufen bestanden,80
Nightly,Beim Build gescheitert,4
Nightly,Bei den Tests gescheitert,14
Nightly,Beim Deployment gescheitert,2
Beim Build gescheitert,Code-Fehler,15
Beim Build gescheitert,Abhängigkeit oder Konfiguration,22
Bei den Tests gescheitert,Instabiler Test,35
Bei den Tests gescheitert,Echte Regression,45
Bei den Tests gescheitert,Umgebung,16
Beim Deployment gescheitert,Abhängigkeit oder Konfiguration,3
Beim Deployment gescheitert,Umgebung,4So funktioniert es
Pipeline-Läufe für einen Zeitraum exportieren
Nehmen Sie den Auslöser, die erste fehlgeschlagene Stufe und das Ergebnis auf. Behalten Sie Wiederholungen als eigene Läufe.
Die Ursache jedes Fehlers kennzeichnen
Nutzen Sie eine kurze Liste: instabil, Regression, Code-Fehler, Konfiguration, Umgebung. Ein Fehler ohne Ursache geht an „Unbekannt“, was sich zu zeigen lohnt.
Auslöser, Ergebnis und Ursache zählen
Zählen Sie jeden Lauf einmal, nach seiner ersten fehlgeschlagenen Stufe.
Die Bilanz prüfen
Jede fehlgeschlagene Stufe muss so viele Läufe abgeben, wie hineinflossen. „Bestanden“ endet in der zweiten Spalte.
Häufig gestellte Fragen
Wie unterscheide ich einen instabilen Test von einer Regression?
Eine gängige Regel: Ein Test, der fehlschlägt und bei Wiederholung ohne Codeänderung besteht, ist instabil. Nutzen Sie die Regel, die Ihr Team schon hat, und behalten Sie sie in jedem Zeitraum bei.
Warum Läufe zählen und nicht Commits?
Läufe sind das, was das CI-System aufzeichnet. Wenn Sie Commits wollen, zählen Sie jeden Commit einmal nach seinem Endergebnis und sagen Sie das in der Datenanmerkung.
Dieses CI-Pipeline-Sankey bearbeiten
Öffnen Sie das Beispiel als eigenes Diagramm und tragen Sie Ihre Pipeline-Zahlen ein.