Trouver les goulots d'étranglement d'un processus de publication logicielle
Dessinez le processus de publication comme un organigramme, comptez ce qui sort de chaque décision, puis montrez les comptes en diagramme de Sankey. Trouvez la porte où les builds échouent, reviennent ou attendent le plus.
Un goulot d'étranglement de publication est la porte où le travail s'accumule, échoue ou revient. Ce guide dessine d'abord le processus, de sorte que chaque porte soit une décision avec des sorties nommées, puis compte les publications qui empruntent ces sorties.
En bref
- Dessinez le processus sous forme de décisions avec des sorties étiquetées avant de compter quoi que ce soit.
- Comptez les publications (ou les builds) par sortie sur une période.
- Une porte avec une large branche de retour est un goulot d'étranglement, même si elle est rapide.
- Montrez les comptes en diagramme de Sankey et utilisez l'organigramme pour les expliquer.
Commencez par les portes, pas par les chiffres
Les équipes cherchent d'ordinaire l'étape lente en moyennant des durées. Cela révèle les tâches lentes, mais pas les portes qui renvoient le travail en arrière. Une publication peut passer une journée en test et perdre quand même une semaine, parce qu'un test en échec la renvoie vers une étape de correction et que le cycle recommence. Pour le voir, dessinez le processus avec ses décisions et comptez combien de publications prennent chaque sortie.
Un organigramme donne la structure : chaque décision a des branches étiquetées, et chaque branche a un compte. L'exemple est un processus de publication à quatre décisions : tests automatisés, feu vert ou non, santé en production et défauts de production. Une fois les comptes par branche en main, un diagramme de Sankey les montre sous forme de largeurs. Voir /fr/sankey/ci-pipeline-outcomes pour l'étape de build, et /fr/sankey/pull-request-review-flow pour l'étape de revue qui la précède.
Restez modeste dans vos conclusions. Les comptes montrent où le travail quitte une porte, pas pourquoi. La raison vient de la lecture des éléments en échec et des personnes qui font fonctionner la porte.
Un processus de publication, construit par étapes
Vingt étapes et quatre décisions. Chaque décision est un endroit où un Sankey montrerait le travail partant dans deux directions.
Build et tests automatisés
Le processus part de « Code terminé pour la sortie », gèle la portée et exécute les tests automatisés. La première décision, « Les tests automatisés réussissent ? », a une branche Échec qui reboucle par une étape de correction vers le build. Cette boucle est le premier endroit à compter.
Préproduction, validation et feu vert
Un build qui passe va en préproduction, en régression et en UAT, puis le dossier de préparation est assemblé et approuvé. « Feu vert pour la mise en production ? » a une branche Non qui revient à l'étape de correction : une publication peut donc revenir de très tard dans le processus.
La production et le chemin du retour
La publication est déployée dans sa fenêtre puis soumise à des tests de fumée. « Libération saine ? » se divise entre la surveillance et un retour arrière qui renvoie à l'étape de correction. Un retour arrière est la sortie la plus coûteuse, donc son compte compte le plus.
Surveillance et correctif urgent
Après la période de trempage, « Défaut de production détecté ? » envoie la publication vers un correctif, qui rentre au déploiement, ou vers les notes de version et la clôture. Comptez la fréquence de la branche du correctif.
Comment cela fonctionne
Dessiner le processus avec ses décisions
Mettez chaque porte comme une décision avec des sorties étiquetées, comme Passer et Échec. Une porte dessinée comme une simple étape cache la sortie que vous voulez compter.
Choisir une période et une unité
Prenez le dernier trimestre et comptez les publications, ou les builds si vous publiez souvent. Dites lequel dans la note sur les données.
Compter ce qui sort de chaque décision
Pour chaque décision, comptez combien d'éléments ont pris chaque sortie. Prenez les chiffres dans votre système de CI, vos tickets ou votre journal de publication.
Dessiner les comptes en diagramme de Sankey
Utilisez les décisions comme nœuds et les sorties comme flux. Vérifiez que ce qui entre dans chaque nœud égale ce qui en sort.
Lire d'abord la plus large branche de retour
La plus large branche qui pointe vers l'arrière est le goulot probable. Lisez ces éléments pour comprendre pourquoi.
Erreurs à éviter
Ne compter que le résultat final
Si vous ne comptez que ce qui a été livré, les boucles disparaissent. Comptez à chaque décision, sinon le Sankey montrera un processus fluide qui n'a pas existé.
Mélanger les unités
Builds, publications et tickets sont des unités différentes. Choisissez-en une pour tout le diagramme et dites laquelle.
Lire les comptes comme des causes
Une large branche Échec dit que les tests échouent souvent, pas pourquoi. Examinez les éléments en échec avant de changer le processus.
Ouvrir l'organigramme de publication logicielle
Ouvrez le modèle de publication, adaptez les portes aux vôtres et comptez les sorties.
Guides associés
Questions fréquentes
Pourquoi dessiner un organigramme si je ne veux qu'un Sankey ?
Parce que l'organigramme décide de ce que sont les nœuds. Sans lui, le Sankey montre les étapes que votre outil exporte, qui ne sont souvent pas les portes où les gens décident.
De combien de publications ai-je besoin ?
D'assez pour que chaque sortie compte plus que quelques éléments. En dessous d'environ 20, montrez les comptes dans un tableau plutôt que dans un diagramme.
Cela remplace-t-il la mesure du délai de livraison ?
Non. Le délai dit combien de temps ; le Sankey dit où le travail sort ou revient. Utilisez les deux et comparez-les sur la même période.