Le Délai de changement indique le temps requis pour déployer un commit en production. Il mesure le temps écoulé entre le premier commit et le déploiement d'une revue de code, donc son intégration. Il peut s’agir de correctifs, d’améliorations ou de nouvelles fonctionnalités.
Faisant partie des métriques de DORA (lien vers la page officielle, anglais), cette mesure ainsi que la Fréquence de déploiement permettent de mesurer la vélocité d’une équipe de développement.
Vous pouvez afficher le délai de changement pour la période du dernier mois, des trois derniers mois ou encore des 6 derniers mois. Vous pouvez également préciser l'environnement à afficher, soit production ou staging.
Il est à noter que vous devez configurer un (ou plusieurs) webhook ainsi que vos environnements de déploiement afin de synchroniser les données nécessaires à la mesure de cette donnée.
Lecture du graphique
Pour le graphique suivant, la période affichée correspond aux trois derniers mois et, dans l’ensemble, nous pouvons voir que l’équipe met 3 jours et 8 heures en moyenne à déployer un commit en production. Selon le rapport sur l'état du DevOps en 2022, ce délai de changement correspond aux critères d'évaluation pour une équipe à haute performance.
Le graphique affiche le temps passé à chaque étape du processus. Dans le cas de cette équipe, nous pouvons voir que le bloquant se situe à l’étape du déploiement.
Un délai de changement court démontre que vos processus sont efficaces, que vous livrez rapidement de la valeur et que vous pouvez obtenir des rétroactions rapides sur votre produit. Dans le cas de l’équipe utilisée dans cet exemple, le goulot d’étranglement au stade du déploiement doit être adressé rapidement, car il empêche la livraison de valeur aux clients.
Psst! Consultez notre article de blogue pour en savoir plus sur les pistes de solutions pour améliorer votre délai de changement!
En cliquant sur les infobulles pour chaque étape, vous obtiendrez les informations suivantes.
- Programmation : La phase de programmation reflète le temps passé entre le premier commit et l'ouverture de la revue de code.
- Prise en charge : La phase de prise en charge représente le temps passé entre l'ouverture de la revue de code et la première interaction reçue (ex: commentaire, réaction, approbation). Cette phase permet d'identifier les goulots d'étranglement dans le flot de travail tels que des revues de code inactives ou bloquées.
- Revue : La phase de revue illustre le temps passé entre la première interaction reçue (ex: commentaire, réaction, approbation) et l'intégration d'une revue de code. Cette phase reflète le temps passé à faire l'évaluation d'une revue de code ainsi que les interactions entre les membres de l'équipe avant l'intégration de celle-ci
- Déploiement : La phase de déploiement représente le temps de l'intégration d'une revue de code jusqu'à son déploiement.
Calcul de la métrique
Lors du calcul, Axify ne considère que les déploiements effectués lorsqu’une pull request est fusionnée.
Si un déploiement survient lors de la phase de « prise en charge » (pickup) ou « révision » (review) d’une pull request, le déploiement est ignoré pour la présente métrique. Cependant, ce déploiement sera considéré dans le calcul de la fréquence de déploiement.
Donc, Axify identifie et mesure les déploiements de la façon suivante :
-
Seuls les déploiements réussis sont comptés.
-
Nous ciblons les déploiements par jour.
- Dans le cas d’un déploiement qui échoue et qui est redéployé plus tard (après rollback), un seul déploiement est considéré.
- Si l'identifiant unique (donc le "Sha", ou "hash") est utilisé dans 2 déploiements, une moyenne est faite de sorte à ne compiler qu'un seul déploiement.
- Tous les déploiements sont considérés pour l'environnement sélectionné.
- Des données de déploiement peuvent provenir de plusieurs sources sur un même webhook et/ou sur plusieurs webhooks.
Pour en savoir plus sur les indicateurs de variation, référez-vous à cet article!