Mesure et suivi des performances de CI/CD
L'amélioration continue est l'un des piliers de la philosophie DevOps.
Elle s'étend à tous les aspects du développement logiciel, du produit ou service que vous créez à la culture et aux processus de votre organisation.
L'amélioration continue implique de recueillir et d'analyser les retours d'information concernant votre projet ou votre méthode de travail afin de comprendre les éléments qui fonctionnent et ceux qui pourraient être améliorés. Après avoir exploité ces informations, vous recueillez d'autres retours d'information pour voir si les modifications que vous avez apportées ont fait avancer le projet dans la bonne direction, puis vous continuez à apporter les ajustements nécessaires.
Un pipeline de CI/CD joue un rôle central pour permettre l'amélioration continue de votre logiciel. En réduisant le délai entre le développement et le déploiement, vous pouvez publier plus fréquemment des modifications auprès des utilisateurs et obtenir ainsi un retour d'information sur l'utilisation en production, ce qui vous permet de définir les priorités suivantes. De même, les retours d'information rapides fournis à chaque étape des tests automatisés facilitent la correction des bugs et vous aident à maintenir la qualité de votre logiciel.
Mais l'amélioration continue ne s'arrête pas là. En appliquant les mêmes techniques au pipeline de CI/CD lui-même, vous pouvez affiner le processus de build, de test et de publication de votre logiciel, ce qui amplifie les boucles de feedback que vous utilisez pour améliorer votre produit.
Comprendre les métriques du pipeline
D'après l'adage, « vous ne pouvez pas gérer ce que vous ne mesurez pas ».
Les métriques sont un outil essentiel pour améliorer les performances du système : elles permettent d'identifier les domaines où vous pouvez apporter une valeur ajoutée et offrent une base de référence pour mesurer l'impact de toute amélioration apportée.
Les performances en matière de CI/CD englobent à la fois vitesse et qualité. En effet, il ne devrait pas y avoir de compromis entre le déploiement rapide des modifications et la livraison d'un produit robuste et fiable. Un pipeline de CI/CD très performant vous permet d'atteindre les deux objectifs.
En mesurant et en surveillant la vitesse des activités, la qualité de votre logiciel et la mesure dans laquelle vous utilisez l'automatisation, vous pouvez identifier les domaines à améliorer et confirmer ensuite si les modifications que vous avez apportées ont eu un effet positif.
Métriques de performances DevOps de premier niveau
Les quatre métriques suivantes ont été identifiées par DevOps Research and Assessment (DORA) comme métriques de premier niveau qui donnent une indication précise des performances d'une organisation dans le contexte du développement logiciel.
You can learn more about the research that informed these choices in the book Accelerate.
Délai d'exécution
Bien que le délai d'exécution (également appelé délai de livraison ou délai de commercialisation) puisse être mesuré comme le temps écoulé entre le moment où une fonctionnalité est évoquée pour la première fois et celui où elle est mise à la disposition des utilisateurs, le temps consacré à l'idéation, à la recherche relatives aux utilisateurs et au prototypage a tendance à être très variable.
C'est pourquoi l'approche adoptée par DORA consiste à mesurer le temps écoulé entre la validation du code et le déploiement, ce qui vous permet de vous concentrer uniquement sur les étapes comprises dans votre pipeline de CI/CD.
Un long délai d'exécution signifie que vous ne présentez pas régulièrement les modifications du code aux utilisateurs et que vous ne bénéficiez donc pas des retours d'information nécessaires pour améliorer votre produit. Cette situation peut être due à plusieurs facteurs.
Un pipeline de publication qui implique des étapes manuelles, telles qu'un grand nombre de tests manuels, d'évaluations des risques ou de tableaux de révision des modifications, peut allonger le processus de plusieurs jours ou semaines, ce qui compromet les avantages des publications fréquentes.
Si investir dans l'automatisation des tests permet de répondre au premier point, le second nécessite de dialoguer avec les parties prenantes pour comprendre comment répondre plus efficacement à leurs besoins. Par ailleurs, si les étapes automatisées sont lentes ou peu fiables, les métriques de durée de build peuvent être utilisées pour identifier les étapes qui prennent le plus de temps.
Fréquence de déploiement
La fréquence des déploiements enregistre le nombre de fois où vous utilisez votre pipeline de CI/CD pour déployer en production. La fréquence de déploiement a été choisie par DORA comme proxy pour la taille des lots, car une fréquence de déploiement élevée implique moins de modifications par déploiement.
Le déploiement d'un petit nombre de modifications fréquentes réduit le risque associé à la publication (moins de variables peuvent se combiner pour donner des résultats inattendus), et fournit des retours d'information plus rapide.
Une faible fréquence de déploiement peut signifier que le pipeline n'est pas alimenté par des commits réguliers, peut-être parce que les tâches ne sont pas décomposées ou que les modifications sont regroupées dans des publications plus importantes.
Lorsque les modifications doivent être groupées pour des raisons commerciales (par exemple, pour répondre aux attentes des utilisateurs), la mesure de la fréquence des déploiements vers les sites de préproduction vous permet de contrôler la taille des lots et d'évaluer si vous tirez profit du travail par petits incréments.
Taux d'échec des modifications
Le taux d'échec des modifications se réfère à la proportion de modifications déployées en production qui entraînent un échec, tel qu'une panne ou un bug nécessitant un retour en arrière ou un correctif. Cette métrique a l'avantage de replacer les échecs de déploiement dans le contexte du volume de modifications effectuées.
Un faible taux d'échec des modifications peut vous donner confiance dans votre pipeline. En effet, cela signifie que les premières étapes du pipeline fonctionnent correctement et identifient la plupart des défauts avant que votre code ne soit déployé en production.
Temps moyen de récupération
Le délai moyen de récupération ou de résolution (MTTR) mesure le temps nécessaire pour remédier à un échec de production. La métrique MTTR reconnaît que, dans un système complexe comportant de nombreuses variables, certains échecs de production sont inévitables. Plutôt que de viser la perfection (et donc de ralentir les publications et de renoncer aux avantages des publications fréquentes), il est préférable de corriger rapidement les problèmes.
Pour maintenir votre MTTR à un faible niveau, vous devez à la fois surveiller de manière proactive votre système en production pour vous signaler les problèmes dès qu'ils apparaissent, et être en mesure d'annuler les modifications ou de déployer rapidement un correctif via le pipeline.
Une métrique connexe, le temps moyen de détection (MTTD), mesure le temps entre le déploiement d'une modification et la détection par votre système de surveillance d'un problème introduit par cette modification. En comparant le MTTD et la durée de build, vous pouvez déterminer si l'un ou l'autre domaine mériterait un travail pour réduire votre MTTR.
Métriques opérationnelles et de CI
En plus de ces mesures de premier ordre, il existe une série de métriques opérationnelles que vous pouvez utiliser pour mieux comprendre les performances de votre pipeline et identifier les domaines dans lesquels vous pourriez améliorer votre processus.
Couverture du code
Dans un pipeline de CI/CD, les tests automatisés doivent fournir la majorité de votre couverture de test, permettant ainsi à vos ingénieurs AQ de se concentrer sur les tests exploratoires et la définition de nouveaux cas de test. La première couche de tests automatisés doit être constituée de tests unitaires, car ils sont plus rapides à exécuter et fournissent des retours d'information plus immédiats.
La couverture de code est une métrique fournie par la plupart des serveurs de CI qui calcule la proportion de votre code couverte par les tests unitaires. Il est intéressant de surveiller cette métrique pour s'assurer que vous maintenez une couverture de test adéquate au fur et à mesure que vous écrivez du code. Si votre couverture de code a tendance à diminuer au fil du temps, pensez à investir dans cette première série de retour d'information.
Durée du build
La durée de build ou le temps de build mesure le temps nécessaire à la réalisation des différentes étapes du pipeline automatisé. Analyser le temps passé à chaque étape du processus est utile pour repérer les problèmes majeurs ou les goulets d'étranglement qui pourraient ralentir le temps global nécessaire pour obtenir des retours d'information à partir des tests ou pour déployer en production.
Taux de réussite du test
Le taux de réussite du test est le pourcentage de cas de test qui ont réussi pour un build donné. Tant que vous disposez d'un niveau raisonnable de tests automatisés, cette métrique offre une indication fiable de la qualité de chaque build. Vous pouvez utiliser cette métrique pour comprendre à quelle fréquence les modifications du code entraînent l'échec des tests.
Bien qu'il soit préférable de détecter les échecs à l'aide de tests automatisés plutôt que de s'appuyer sur des tests manuels ou de découvrir les problèmes en production, si un ensemble particulier de tests automatisés échoue régulièrement, il peut être utile d'examiner la cause profonde de ces échecs.
Temps de correction des tests
Le temps de correction des tests est le temps qui s'écoule entre le moment où un build signale l'échec d'un test et celui où le même test réussit lors d'un build ultérieur. Cette métrique vous donne une indication de la rapidité avec laquelle vous êtes en mesure de répondre aux problèmes identifiés dans le pipeline.
Un temps de résolution faiblemontre que vous utilisez votre pipeline au mieux. En effet, en traitant les problèmes dès qu'ils sont découverts, vous pouvez travailler plus efficacement (puisque les modifications sont encore récentes dans votre esprit) et vous évitez de développer plus de fonctionnalités sur un code instable.
Déploiements échoués
Les déploiements échoués qui entraînent un temps d'arrêt involontaire nécessitent un retour en arrière du déploiement ou la publication urgente d'un correctif. Le nombre de déploiements qui ont échoué est utilisé pour calculer le taux d'échec des modifications (voir ci-dessus).
Surveiller la proportion d'échecs par rapport au nombre total de déploiements permet de mesurer vos performances par rapport aux contrats de niveau de service.
Cependant, gardez à l'esprit qu'un objectif de zéro (ou très peu) de déploiements échoués n'est pas nécessairement réaliste, et peut au contraire encourager les équipes à privilégier la certitude. Il en résulte des délais d'exécution plus longs et des déploiements plus importants, car les modifications sont regroupées, ce qui augmente la probabilité d'échecs en production (avec plus de variables) et les rend plus difficiles à corriger (avec plus de modifications à examiner).
Nombre de défauts
Contrairement aux échecs, le nombre de défauts correspond au nombre de tickets ouverts classés en tant que bugs dans votre backlog. Il peut être subdivisé en deux catégories : les problèmes rencontrés en phase de test ou de préproduction et ceux rencontrés en phase de production.
Comme pour la couverture du code, le suivi du nombre de défauts est utile pour vous alerter sur une tendance générale à la hausse, qui peut indiquer que les bugs deviennent incontrôlables. N'oubliez pas, cependant, que faire de cette mesure un objectif peut amener votre équipe à se concentrer davantage sur le classement des tickets que sur leur résolution.
Taille du déploiement
En corollaire à la fréquence de déploiement (voir ci-dessus), la taille du déploiement, mesurée par le nombre de points de récit (« story points » en anglais) inclus dans un build ou une publication, peut être utilisée pour contrôler la taille du lot au sein d'une équipe particulière.
Maintenir des déploiements mineurs montre que votre équipe effectue régulièrement des commits, avec tous les avantages qui en découlent. Cependant, comme les estimations de récit ne sont pas comparables entre les équipes de développement, cette métrique ne doit pas être utilisée pour mesurer la taille globale du déploiement.
Conclusion
Le suivi de ces métriques vous permet de mieux comprendre les performances de votre pipeline de CI/CD et de savoir si la tendance est à la hausse ou à la baisse.
Vous pouvez utiliser les métriques pour identifier les domaines de votre processus qui mériteraient une plus grande attention. Une fois que vous avez effectué une modification, il est recommandé de continuer à surveiller les paramètres pertinents pour vérifier si elle a eu l'effet escompté.
Toutefois, si les métriques peuvent fournir des indicateurs de performance utiles, il est important de considérer les chiffres dans leur contexte et d'examiner quels comportements pourraient être encouragés en se concentrant sur une métrique particulière. N'oubliez pas que l'objectif n'est pas les chiffres eux-mêmes, mais la rapidité et la fiabilité de votre pipeline, afin que vous puissiez continuer à offrir de la valeur aux utilisateurs.