Fréquence de déploiement
Comme son nom le suggère, la Deployment Frequency (fréquence de déploiement) désigne la fréquence des mises en production réussies des logiciels. En d’autres termes, cette métrique mesure la fréquence à laquelle une entreprise déploie le code pour une application donnée.
Cet indicateur, qui se base sur le nombre total de déploiements par jour, a été développé à partir de concepts de fabrication qui mesurent et contrôlent la taille des lots de stocks qu’une entreprise livre.
Naturellement, les entreprises les plus prospères ont tendance à effectuer des livraisons plus petites et beaucoup plus fréquentes ; ou, dans le monde de DevOps, des déploiements plus fréquents, mais plus petits.
En général, un déploiement par semaine est la norme, tandis qu’une entreprise performante peut atteindre jusqu’à sept déploiements par jour. Bien entendu, le nombre standard de déploiements varie d’un produit à l’autre.
Par exemple, les applications qui demandent aux utilisateurs de télécharger la dernière Mise à jour sortent généralement une ou deux versions par trimestre tout au plus, alors qu’une solution SaaS peut être déployée plusieurs fois par jour.
| Question |
Très bon performeur |
Bon performeur |
Performeur moyen |
Mauvais performeur |
| À quelle fréquence votre organisation déploie-t-elle du code en production ou le met-elle à la disposition des utilisateurs finaux ? |
Sur demande (plusieurs déploiements par jour) |
Entre une fois par jour et une fois par semaine |
Entre une fois par semaine et une fois par mois |
Entre une fois par mois et une fois tous les six mois |
Source: 2019 Accelerate State of DevOps, Google
Lorsque les équipes DevOps se rendent compte qu’elles font partie d’une catégorie peu performante, elles peuvent mettre en place des processus plus automatisés pour tester et valider le nouveau code, ainsi que réduire le délai entre la rectification des erreurs et la livraison du code modifié.
Délai d’exécution des changements
Cette métrique mesure le temps qui s’écoule avant que le code validé n’atteigne la production. Alors que la fréquence de déploiement mesure la cadence de publication du nouveau code, le Lead Time for Changes (délai d’exécution des changements) mesure la rapidité de la livraison des logiciels. Il sert à mieux comprendre la durée de cycle DevOps et à savoir comment une augmentation des demandes est gérée. Plus le délai d’exécution des modifications est court, plus l’équipe DevOps est efficace pour déployer le code.
Pour mesurer les délais d’exécution des changements, deux données (ou horodatages) sont nécessaires : l’heure exacte de la réception de la demande et l’heure exacte du déploiement, soit la durée entre début et fin de produit. Le temps moyen est ensuite utilisé comme indicateur de la performance globale.
| Question |
Très bon performeur |
Bon performeur |
Performeur moyen |
Mauvais performeur |
| Combien de temps faut-il pour passer d’un code validé à un code fonctionnant avec succès en production ? |
Moins d’une journée |
Entre un jour et une semaine |
Entre une semaine et un mois |
Entre un mois et six mois |
Source: 2019 Accelerate State of DevOps, Google
Si l’on constate que les délais d’exécution des changements sont longs, les équipes DevOps peuvent mettre en place des processus de déploiement et d’examen plus automatisés et diviser les produits et les fonctionnalités en unités beaucoup plus compactes et faciles à gérer.
Temps moyen de récupération
Le Mean Time to Recover (temps moyen de récupération) mesure le temps qu’il faut à un service pour rebondir après un échec. Peu importe les performances de l’équipe DevOps, des pannes ou des incidents imprévus peuvent survenir. Et comme les défaillances ne peuvent être évitées, c’est le temps nécessaire pour restaurer ou récupérer un système ou une application qui fait la différence.
Si une entreprise dispose d’un temps de récupération court, les dirigeants se sentent généralement plus à l’aise pour expérimenter et innover. En retour, cela crée un avantage concurrentiel et améliore les revenus de l’entreprise.
Cet indicateur est important dans le sens où il incite les ingénieurs à développer des systèmes plus robustes. Il est généralement calculé en suivant le temps moyen entre le signalement d’un bogue et le moment où la correction du bogue est déployée.
| Question |
Très bon performeur |
Bon performeur |
Performeur moyen |
Mauvais performeur |
| Combien de temps faut-il pour rétablir le service après un incident de service ou un défaut ayant un impact sur les utilisateurs ? |
Moins d’une heure |
Moins de 24 heures |
Moins de 24 heures |
Entre une semaine et un mois |
Source: 2019 Accelerate State of DevOps, Google
Afin d’améliorer leurs performances en matière de temps moyen de récupération, les équipes DevOps doivent pratiquer une surveillance continue et donner la priorité à la récupération lorsqu’une défaillance se produit. Il est également utile d’établir un plan d’action pour réagir immédiatement à toute défaillance.
Taux d’échec des changements
Cette métrique mesure le pourcentage de changements qui ont été apportés à un code et qui ont ensuite entraîné des incidents, des retours en arrière ou tout autre type d’échec de production. Ainsi, le Change Failure Rate (taux d’échec des changements) est un véritable indicateur de la qualité et de la stabilité alors que les métriques précédentes, la fréquence de déploiement et le délai d’exécution des changements, n’indiquent pas la qualité du logiciel, mais juste son rythme de livraison. Selon le rapport DORA, les plus performants se situent entre 0 et 15 %.
Le taux d’échec des changements est calculé en comptant le nombre d’échecs de déploiement et en le divisant par le nombre total de déploiements. Lorsqu’il fait l’objet d’un suivi régulier, cet indicateur donne une idée assez précise du temps consacré à la correction des erreurs et des bogues par rapport à la livraison d’un nouveau code. Il va sans dire qu’une équipe DevOps doit toujours s’efforcer d’obtenir la moyenne la plus basse possible.
| Question |
Très bon performeur |
Bon performeur |
Performeur moyen |
Mauvais performeur |
| Quel est le pourcentage de modifications apportées au code entraînent une dégradation du service ? |
0-15% |
0-15% |
0-15% |
46-60% |
Source: 2019 Accelerate State of DevOps, Google
Afin de réduire les taux d’échec élevés, les équipes doivent réduire les échecs de déploiement et les pertes de temps dues aux retards.
En savoir plus
/FR/Poster/FR-17-Metrics-Poster-Resource-Page-Thumbnail.png?width=360&height=255&name=FR-17-Metrics-Poster-Resource-Page-Thumbnail.png)
/FR/Poster/FR-Cloud-Microservice-Catalog-Poster_Resource_Page_Thumbnail.png?width=260&height=171&name=FR-Cloud-Microservice-Catalog-Poster_Resource_Page_Thumbnail.png)
/EN/Video/Speaker-Live-Recording-Dominik-Per.png?width=260&height=171&name=Speaker-Live-Recording-Dominik-Per.png)
.svg)
/FR/Poster/FR-17-Metrics-Poster-Resource-Page-Thumbnail.png?width=300&name=FR-17-Metrics-Poster-Resource-Page-Thumbnail.png)