Sankey des résultats de pipeline CI : du déclencheur à la cause d'échec
Suivez les exécutions de pipeline du déclencheur au résultat et à la cause de chaque échec : tests instables, vraies régressions, configuration et environnement. Remplacez les comptes par votre historique CI.
Un Sankey de pipeline CI montre comment les builds se terminent selon le déclencheur et pourquoi ils échouent. Il sépare les échecs qui signifient quelque chose (une régression) de ceux qui ne signifient rien (un test instable).
L'exemple compte 900 exécutions de pipeline issues de trois déclencheurs : push sur main, pull requests et builds nocturnes. 760 passent toutes les étapes et 140 échouent, au build (37), aux tests (96) ou au déploiement (7). La dernière colonne donne la cause : test instable, vraie régression, erreur de code, dépendance ou configuration, et environnement de test.
Le taux de réussite cache le mélange. Dans l'exemple, 35 des 96 échecs de tests sont instables, ce qui pose un problème de confiance pour la suite de tests, et 45 sont de vraies régressions, ce qui signifie que le pipeline fait son travail. Les comptes sont des exécutions, pas des commits : une nouvelle tentative est une exécution. Pour l'étape de revue qui précède, voir /fr/sankey/pull-request-review-flow, et /fr/guides/comment-trouver-les-goulots-d-etranglement-dans-un-processus-de-publication-logicielle pour le processus plus large.
Comment lire ce diagramme
- 760 des 900 exécutions (84 %) passent toutes les étapes ; 140 (16 %) échouent.
- Les tests sont le point d'échec le plus fréquent : 96 des 140 échecs (69 %).
- 35 échecs sont des tests instables, soit 25 % de tous les échecs, et 45 sont de vraies régressions.
- Les exécutions de pull requests réussissent dans 82 % des cas (410 sur 500), main dans 90 % (270 sur 300).
Les données derrière le diagramme
Chiffres inventés à titre d'illustration. Ce ne sont pas des données sur une entreprise, une équipe ou un système réels.
| De | Vers | Quantité (exécutions de pipeline) |
|---|---|---|
| Push sur main | Toutes les étapes réussies | 270 |
| Push sur main | Échec au build | 8 |
| Push sur main | Échec aux tests | 17 |
| Push sur main | Échec au déploiement | 5 |
| Pull request | Toutes les étapes réussies | 410 |
| Pull request | Échec au build | 25 |
| Pull request | Échec aux tests | 65 |
| Nocturne | Toutes les étapes réussies | 80 |
| Nocturne | Échec au build | 4 |
| Nocturne | Échec aux tests | 14 |
| Nocturne | Échec au déploiement | 2 |
| Échec au build | Erreur de code | 15 |
| Échec au build | Dépendance ou configuration | 22 |
| Échec aux tests | Test instable | 35 |
| Échec aux tests | Vraie régression | 45 |
| Échec aux tests | Environnement | 16 |
| Échec au déploiement | Dépendance ou configuration | 3 |
| Échec au déploiement | Environnement | 4 |
Les mêmes données en CSV
source,target,value
Push sur main,Toutes les étapes réussies,270
Push sur main,Échec au build,8
Push sur main,Échec aux tests,17
Push sur main,Échec au déploiement,5
Pull request,Toutes les étapes réussies,410
Pull request,Échec au build,25
Pull request,Échec aux tests,65
Nocturne,Toutes les étapes réussies,80
Nocturne,Échec au build,4
Nocturne,Échec aux tests,14
Nocturne,Échec au déploiement,2
Échec au build,Erreur de code,15
Échec au build,Dépendance ou configuration,22
Échec aux tests,Test instable,35
Échec aux tests,Vraie régression,45
Échec aux tests,Environnement,16
Échec au déploiement,Dépendance ou configuration,3
Échec au déploiement,Environnement,4Comment cela fonctionne
Exporter les exécutions de pipeline d'une période
Incluez le déclencheur, la première étape en échec et le résultat. Gardez les relances comme des exécutions distinctes.
Étiqueter la cause de chaque échec
Utilisez une courte liste : instable, régression, erreur de code, configuration, environnement. Un échec sans cause va dans Inconnue, ce qui vaut la peine d'être montré.
Compter déclencheur, résultat puis cause
Comptez chaque exécution une fois, selon sa première étape en échec.
Vérifier l'équilibre
Chaque étape en échec doit sortir autant d'exécutions qu'elle en reçoit. Réussie s'arrête à la deuxième colonne.
Questions fréquentes
Comment distinguer un test instable d'une régression ?
Une règle courante veut qu'un test qui échoue puis réussit à la nouvelle tentative sans changement de code soit instable. Utilisez la règle que votre équipe a déjà et gardez-la identique à chaque période.
Pourquoi compter des exécutions et pas des commits ?
Les exécutions sont ce qu'enregistre le système de CI. Si vous voulez des commits, comptez chacun une fois selon son résultat final et dites-le dans la note sur les données.
Modifier ce Sankey de pipeline CI
Ouvrez l'exemple comme votre propre diagramme et saisissez vos comptes de pipeline.