L’objectif des équipes de développement et de DevOps est de livrer constamment plus de valeur aux utilisateurs — plus fréquemment et avec plus de qualité. Différentes pratiques ont été introduites pour rendre les équipes d’ingénierie logicielle plus efficaces et plus agiles dans le processus de développement. Pour les équipes de développement, il est très important d’identifier les obstacles dans le processus de livraison logicielle et d’optimiser le flux de valeur.
Dans cet article, nous étudions la fréquence de déploiement, l’une des métriques clés de DORA.
À la suite de l’enquête sur l’accélération du DevOps, Google a créé en 2015 le programme DORA (DevOps Research and Assessment). En 2018, ils ont publié leur étude Accelerate introduisant les métriques DORA — un concept qui définit 4 métriques clés qui peuvent distinguer les équipes de développement très performantes des équipes moyennes :
Fréquence de déploiement — mesure la fréquence à laquelle le code est déployé avec succès dans un environnement de production. Les équipes de développement ont tendance à livrer de nouvelles fonctionnalités aux clients dès que possible, et cette mesure est donc utile pour comprendre la fréquence à laquelle cela se produit.
Délai nécessaire aux changements — cette mesure indique le temps nécessaire pour qu’un changement apparaisse dans l’environnement de production, en examinant le temps moyen entre la première validation effectuée dans l’environnement de développement et le moment où cette fonctionnalité fonctionne avec succès dans la production.
Délai de récupération après un échec de déploiement — mesure le temps nécessaire au système pour se rétablir d’un incident survenu en production. Pour améliorer le délai de rétablissement du service, les responsables DevOps doivent surveiller en permanence l’environnement de production.
Taux d’échec des changements — mesure le pourcentage de déploiements provoquant un échec en production, et se calcule en divisant le nombre d’échecs par le nombre total de déploiements.
Les métriques DORA donnent aux responsables de l’ingénierie des informations véridiques, car ils peuvent analyser les métriques pour évaluer les performances de l’équipe. Ils peuvent ensuite améliorer leurs processus internes. En examinant le taux d’échec des changements et le temps de rétablissement du service, les responsables peuvent s’assurer que leur code est robuste et stable, tout en réduisant le nombre de défaillances. D’autre part, le suivi de la fréquence de déploiement et du délai nécessaire aux changements permet de s’assurer que l’équipe travaille à un bon rythme. Combinées, les mesures DORA fournissent des informations cruciales sur la qualité et la rapidité de livraison de l’équipe.
Comme mentionné ci-dessus, la fréquence de déploiement mesure la fréquence à laquelle le code est déployé avec succès dans un environnement de production. Il s’agit de l’une des métriques DORA les plus suivies. Dans le domaine des logiciels, la fréquence de déploiement est une approximation de la taille des lots (selon le paradigme LEAN). La réduction de la taille des lots réduit les temps de cycle et la variabilité du flux, accélère la rétroaction, réduit les risques et les frais généraux, et améliore l’efficacité.
Ainsi, la fréquence des déploiements correspond essentiellement à la taille du lot en production. Par exemple, moins de déploiements peuvent signifier des changements plus importants, alors que des déploiements plus fréquents signifient des changements plus petits. Il est préférable que les changements soient plus fréquents et plus petits, pour accélérer le flux et réduire la variabilité.
En déployant fréquemment un petit nombre de changements, les risques associés au déploiement sont réduits : des changements plus petits signifient moins de risques de conséquences involontaires et non désirées. De plus, cela vous permet d’obtenir des réactions plus rapidement. Les petits problèmes seront traités plus tôt, ce qui permettra d’augmenter la fréquence des déploiements.
Une fréquence de déploiement plus élevée signifie qu’il y a plus de changements dans le produit, ce qui apporte plus de valeur plus tôt et plus souvent. Il en résultera une meilleure rétroaction et, par conséquent, de meilleurs produits et des revenus plus importants.
Mathématiquement, la fréquence de déploiement est le nombre total de déploiements dans un environnement au cours d’une période donnée.
Par exemple, si au cours d’un mois, votre équipe effectue 3 déploiements la première semaine, 9 la deuxième semaine, 7 la troisième et 5 la dernière, votre fréquence de déploiement est de six déploiements par semaine. Ou, approximativement, un déploiement par jour.
Vous pouvez également calculer la fréquence de déploiement en configurant votre outil CI/CD pour qu’il vous avertisse lorsqu’il exécute un travail de déploiement avec succès et qu’il enregistre ces données quelque part. Cette surveillance automatique et cette collecte de données sont moins sujettes à l’erreur qu’un humain. Pour une approche plus rapide et plus fiable de la mesure de la fréquence de déploiement, vous pouvez utiliser un outil spécialisé, tel qu’Axify. Cet outil fait tout le travail pour vous — il collecte les données de votre outil de gestion de pipeline (GitLab CI, Jenkins, etc.), garde une trace de tous vos déploiements réussis, et calcule rapidement votre fréquence de déploiement.
Les applications SaaS conçues sur le nuage ont tendance à être plus faciles à déployer et à être déployées plus fréquemment.
Les applications mobiles sont dépendantes du magasin d’application, il est donc possible de limiter la fréquence de leur déploiement.
Les applications sur site ont tendance à être déployées moins fréquemment (il est plus difficile de les déployer automatiquement et de gérer les versions).
Comme indiqué ci-dessus, une fréquence de déploiement faible signifie un déploiement une fois par mois à une fois tous les six mois. Si votre fréquence de déploiement est faible, il est nécessaire de découvrir les problèmes cachés de l’entreprise. Les causes potentielles d’une faible fréquence de déploiement peuvent être les suivantes :
Procédure de déploiement complexe — si votre processus de déploiement est plutôt complexe, il peut entraîner des erreurs et ralentir le processus, ce qui se traduit par une faible fréquence de déploiement. Lorsque vous apportez des modifications importantes au code, cela peut entraîner de nouveaux bogues et des problèmes de compatibilité, ce qui ralentit le processus de déploiement et la fréquence des déploiements.
Communication et coopération déficientes — généralement, si une équipe distincte est responsable des déploiements, des goulots d’étranglement apparaissent pour les autres équipes, ce qui peut ralentir le processus de déploiement.
Manque d’automatisation — pour déployer régulièrement des logiciels, vous devez automatiser les opérations de déploiement, ce qui accélérera le processus. Une bonne automatisation aidera votre équipe à livrer moins de services défectueux. Si votre processus de déploiement est manuel, il peut entraîner des retards et une faible fréquence de déploiement.
Changements importants — pour gérer des changements importants, il est nécessaire de consacrer du temps à l’examen et à l’assurance qualité des changements et d’impliquer un plus grand nombre de personnes. L’approbation d’un changement prend plus de temps, donc le déploiement prend plus de temps, donc il est moins fréquent.
Les équipes d’ingénierie logicielle ont tendance à être très performantes et à déployer rapidement. L’objectif est de déployer plus souvent, afin d’apporter plus de valeur à vos utilisateurs. Voici quelques conseils pour améliorer la fréquence de vos déploiements :
Réduire la dépendance entre les équipes — chaque équipe devrait avoir la responsabilité de coder et de déployer ses changements. C’est vous qui l’avez construit, c’est vous qui le pilotez. Il est important que votre équipe soit autonome, interfonctionnelle et qu’elle ne dépende pas (ou très peu) des autres équipes pour apporter des modifications. Cela permettra de réduire les délais et d’améliorer l’efficacité globale (et la fréquence des déploiements).
Réduire la dette technique — la dette technique se produit lorsque le logiciel est développé rapidement sans prendre le temps de maintenir et de refactoriser correctement le code. Selon l’étude de CodeScene, les entreprises perdent en moyenne environ 25 % de leur temps de développement à cause de la dette technique. En réduisant la dette technique, les organisations diminueront le nombre de bogues et autres problèmes dans le code, et rendront le processus de développement logiciel plus efficace, permettant à l’équipe de déployer de nouvelles fonctionnalités et des mises à jour plus fréquemment.
Réduire le travail en cours (WIP) — éviter de le répartir sur plusieurs projets/caractéristiques, se concentrer sur un changement à la fois (pour optimiser la chaîne de valeur, accélérer le flux d’achèvement des tâches et leur déploiement). Cette approche est plus efficace, car les développeurs se concentrent sur une tâche à la fois. Si les développeurs partagent leur journée entre plusieurs projets, l’équipe s’oriente dans une mauvaise direction.
Tests automatisés — l’objectif des tests automatisés est de confirmer rapidement que l’application logicielle fonctionne comme prévu, sans intervention manuelle. Les outils de tests automatisés permettent aux organisations de mettre en œuvre des pratiques de livraison continue. Ils permettent de gagner du temps, de réduire les erreurs humaines et de déployer fréquemment des mises à jour logicielles, car les modifications sont automatiquement testées et validées dès qu’elles sont intégrées au code base.
Automatisation du déploiement — avec l’intégration continue, le code est scripté, les tests sont en cours d’exécution et réussissent, les changements d’infrastructure sont spécifiés dans le code et les migrations de bases de données peuvent être exécutées à l’aide d’une ligne de commande (scriptées ou automatisées).
Ces deux métriques DORA mesurent la rapidité de livraison de l’équipe. Alors que la fréquence de déploiement mesure le rythme auquel le nouveau code est déployé, le délai nécessaire aux changements mesure le temps qui s’écoule entre la validation et la mise en production.
Des changements plus petits permettent d’accélérer le flux de travail et de réduire les risques.
Si un incident survient, comme il s’agit d’un changement de moindre importance, il est plus facile de le trouver et de le réparer. Plus le délai nécessaire aux changements est faible, plus l’équipe DevOps est efficace, ce qui signifie une automatisation plus efficace et de bonnes pratiques d’ingénierie. Le délai nécessaire aux changements permet de visualiser la rapidité avec laquelle le travail est livré aux utilisateurs. Au fil du temps, le délai nécessaire aux changements devrait diminuer, tandis que les performances de votre équipe devraient augmenter.
Axify est une plateforme unique permettant d’observer tous les indicateurs clés de performance qui vous aideront à améliorer vos processus de développement et de livraison. Elle est dotée de tableaux de bord de qualité supérieure et permet un suivi constant des métriques DORA en temps réel, ce qui simplifie l’ensemble du processus et permet aux équipes de se concentrer sur les améliorations à apporter.
Axify peut suivre en temps réel les quatre métriques DORA :
Fréquence de déploiement — mesure la fréquence à laquelle une organisation réussit à déployer en production. Cette mesure importante facilite les tests, les déploiements, les rétroactions et les retours en arrière, tout en augmentant la valeur perçue par les utilisateurs.
Délai nécessaire aux changements — temps écoulé entre la première validation et l’exécution réussie du code en production. Cette mesure nous permet d’évaluer l’efficacité des cycles et des initiatives de développement de logiciels. Il tend à entraîner des changements organisationnels, humains et techniques.
Taux d’échec des changements — mesure le pourcentage de déploiements entraînant un échec en production, et se calcule en divisant le nombre d’échecs par le nombre total de déploiements.
Temps de rétablissement du service — mesure le temps nécessaire au système pour se rétablir d’un incident dans la production.
Les calculs manuels peuvent vous fournir des informations utiles, mais un outil automatisé comme Axify peut modéliser le comportement du système de manière prévisionnelle et suivre la fréquence de déploiement sans effort. Garder un œil sur la fréquence de déploiement peut vous donner des indications sur le rythme global de l’équipe. En améliorant l’efficacité de votre équipe, vous obtiendrez un processus fluide, une bonne expérience pour les développeurs et une équipe de développement motivée.
Pour en savoir plus, lisez l’article | Comprendre les indicateurs DORA : un guide complet
