Mesure des performances de CI/CD grâce aux métriques DevOps

Lorsque vous abordez la création du pipeline de CI/CD, tout est à faire, de l'écriture de tests automatisés à l'actualisation automatique de vos environnements de préproduction. Si vous recherchez des idées sur la façon d'améliorer le processus à ce stade, consultez notre guide des bonnes pratiques de CI/CD.

Une fois votre pipeline automatisé en place, il est temps d'explorer les différentes possibilités d'optimisation. Cette phase intervient lorsque le cycle d'amélioration continue commence, à l'aide de vos métriques de pipeline de CI/CD.

Selon Peter Drucker, « Vous ne pouvez pas gérer ce que vous ne mesurez pas ». Les métriques sont essentielles pour l'amélioration continue. Les données aident à identifier les points où ajouter de la valeur et fournissent une base de référence pour mesurer l'impact des modifications que vous apportez.

En surveillant les métriques DevOps importantes, telles que l'extension de la couverture des tests automatiques, l'amélioration du rendement ou la distribution des tâches de développement, vous pouvez identifier celle qui aura le plus d'impact sur les performances de votre pipeline de CI/CD.

À chaque fois que vous optimisez une phase de votre pipeline de CI/CD, vous amplifiez l'effet de cette boucle de rétroaction. Vous pouvez ainsi publier vos modifications plus souvent tout en maintenant la qualité et en conservant un taux de défaut très faible.

Des publications plus fréquentes permettent d'améliorer constamment les fonctionnalités clés, de mener des expériences pour valider des hypothèses et traiter rapidement les problèmes qui se présentent. À mesure que le marché évolue et que la demande de fonctionnalités change, vous êtes en mesure de réagir rapidement, vous permettant ainsi de rester au même niveau ou même de devancer la concurrence.

De plus, la surveillance de vos métriques de CI/CD est un excellent moyen de démontrer la valeur de votre pipeline au reste de l'entreprise, notamment aux parties prenantes et aux autres équipes de développement.

La fréquence des déploiements enregistre le nombre de fois où vous utilisez votre pipeline de CI/CD pour déployer en production. DORA a choisi la fréquence de déploiement comme proxy pour la taille des lots, car une fréquence de déploiement élevée implique moins de modifications par déploiement.

Déployer un plus petit nombre de modifications réduit le risque associé aux déploiements, car moins de variables peuvent se combiner pour produire des résultats inattendus. Un déploiement plus fréquent permet également d'obtenir des retours plus immédiats sur votre travail.

Une faible fréquence de déploiement peut signifier que la fréquence des commits dans le pipeline n'est pas assez régulière, probablement parce que les tâches ne sont pas suffisamment décomposées. Le développement d'une culture DevOps dans laquelle tous les membres de l'équipe comprennent les avantages du CI/CD peut aider votre équipe à s'adapter à travailler en plus petits incréments.

Parfois, une faible fréquence de déploiement peut résulter de modifications regroupées dans des versions plus importantes, dans le cadre d'une stratégie de livraison continue. Si vous devez regrouper les modifications pour des raisons métier (telles que les attentes des utilisateurs), envisagez de mesurer la fréquence des déploiements sur les sites de préproduction à la place.

Le délai d'exécution, parfois appelé délai de livraison ou de commercialisation, désigne la période séparant le début des travaux sur une fonctionnalité et sa publication. Toutefois, le temps consacré à la définition du concept, à l'étude de marché et au prototypage peuvent varier considérablement.

Par conséquent, DORA mesure le temps séparant le dernier commit de code du déploiement. Cette période permet de se focaliser sur les phases couvertes par votre pipeline de CI/CD.

Un délai d'exécution élevé signifie que les modifications du code sont rarement visibles par les utilisateurs. Par conséquent, vous ne pouvez pas profiter des statistiques d'utilisation et des autres formes de retours d'expérience pour affiner ce sur quoi vous travaillez.

Les temps d'exécution excessifs sont courants dans les pipelines ayant plusieurs étapes manuelles. Il peut s'agir d'un grand nombre de tests manuels ou d'un processus de déploiement qui nécessite l'actualisation manuelle des environnements.

Investir dans des tests automatisés et un serveur de CI pour coordonner les tâches de build, de test et de déploiement réduit le temps de livraison des logiciels. Par ailleurs, vous pouvez utiliser un serveur de CI pour collecter des métriques démontrant votre retour sur investissement.

Supposons que vous ayez commencé à automatiser vos processus d'intégration continue et de déploiement, mais que leurs différentes phases sont lentes et peu fiables. Dans ce cas, vous pouvez utiliser la métrique de durée de build pour identifier les goulots d'étranglement.

Si votre organisation impose des comités d'évaluation des risques ou du changement avant chaque nouvelle version, cela risque de retarder le déploiement de plusieurs semaines. Les métriques qui démontrent la fiabilité du processus suscitent la confiance et évitent d'avoir à recourir à des étapes d'approbation manuelle.

Le taux d'échec des modifications se réfère à la proportion de modifications déployées en production qui entraînent une interruption ou des bugs, et nécessitent une restauration ou un correctif. Il n'inclut pas les problèmes découverts avant la mise en production des modifications apportées au code.

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 publié.

Si votre taux d'échec des modifications est élevé, il est temps d'examiner la couverture des tests automatisés. Vos tests couvrent-ils les cas d'utilisation les plus courants ? Vos tests sont-ils fiables ? Êtes-vous en mesure d'enrichir votre régime de test avec des tests automatisés de performances ou de sécurité ?

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. En mettant l'accent sur le MTTR, on 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 de se priver de l'avantage de publications fréquentes, la priorité est de pouvoir répondre rapidement aux problèmes.

Pour maintenir votre MTTR à un faible niveau, vous devez à la fois surveiller de manière proactive les versions en production pour identifier les problèmes dès qu'ils apparaissent, et être en mesure d'annuler les modifications ou de déployer 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 nécessitent une intervention pour réduire votre MTTR.

Les tests automatisés dans un pipeline de CI/CD doivent assurer la majorité de la couverture des tests. 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, pensez à investir dans cette première série de retour d'information.

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é. L'analyse du temps passé à chaque étape du processus permet d'identifier les problématiques ou les goulots d'étranglement qui risquent de retarder les résultats des tests ou de la mise en production.

Le taux de réussite du test désigne 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 ces données pour déterminer la fréquence des bugs induits par les modifications du code.

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 temps d'examiner la cause profonde de ces échecs.

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 faible reflète une utilisation efficace de votre pipeline. La correction des problèmes au fur et à mesure qu'ils apparaissent est plus efficace, car il est plus facile de s'en souvenir. En corrigeant les problèmes rapidement, vous avez, vous et vos collègues, l'assurance d'ajouter des fonctionnalités sur une base stable.

Les échecs des déploiements créent des interruptions imprévues, impliquent l'annulation des déploiements précédents ou appellent des correctifs urgents. Le nombre de déploiements qui ont échoué est utilisé pour calculer le taux d'échec des modifications.

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.

Toutefois, n'oubliez pas qu'une cible de zéro échec (ou d'une valeur très faible) n'est pas nécessairement réaliste et risque de pousser les équipes à privilégier la certitude à la livraison continue d'un produit de qualité. Cet état d'esprit peut introduire des retards importants et créer des déploiements plus lourds, dans la mesure où les modifications sont groupées. Enfin, parce que les grands déploiements contiennent davantage de variables, le risque d'échecs en production difficiles à corriger est également plus élevé (car il y a plus de modifications à traiter).

Contrairement à la métrique portant sur les échecs de déploiement, le nombre de défauts correspond au nombre de tickets ouverts classés en tant que bugs dans votre backlog. Cette métrique de CI peut être elle-même subdivisée en fonction des problèmes trouvés au cours des phases de test, de préproduction et de production.

La mesure du nombre de défauts permet de repérer les tendances à la hausse qui peuvent pointer une perte de contrôle des bugs. 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.

En raison de la fréquence de déploiement, 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 surveiller la taille des lots au sein d'une équipe particulière.

Maintenir des déploiements mineurs montre que votre équipe effectue régulièrement des commits de modification, 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.

Ces métriques DevOps permettent de mieux comprendre les performances de votre pipeline de CI/CD en termes de vitesse de déploiement et de qualité des logiciels.

En suivant ces métriques, vous pouvez identifier les zones de votre processus qui demandent le plus d'attention. Une fois que vous avez effectué des modifications, continuez à surveiller les métriques pertinentes pour vérifier si elles ont eu l'effet escompté.

Toutefois, si les métriques sont des indicateurs utiles des performances, il est important de ne pas perdre le contexte de vue et d'avoir conscience des comportements qui risquent d'être induits par une métrique donnée.

N'oubliez pas que l'objectif n'est pas les chiffres en eux-mêmes, mais la rapidité et la fiabilité de votre pipeline afin de continuer à créer de la valeur pour les utilisateurs et d'atteindre ainsi les objectifs de votre organisation.