Livraison continue : la référence en matière de développement de logiciels

Toute entreprise essayant de fournir les meilleurs produits et services à ses clients devrait accepter volontiers le changement. Bien sûr, cela peut être difficile. Le changement entraîne souvent de l’incertitude, car les processus et services établis doivent évoluer pour répondre aux nouvelles normes. Et le changement ne peut pas se faire pour le simple plaisir. Les entreprises doivent lier ces nouvelles approches, produits et différentes façons de travailler à des résultats mesurables et spécifiques.

Un cadre très efficace pour mesurer la manière dont ces changements affectent les performances est défendu par DevOps Research and Assessment (DORA), un programme de recherche à long terme qui « cherche à comprendre les capacités qui déterminent la livraison de logiciels et les performances opérationnelles ».

Une mesure de performance qui se démarque dans ce cadre est la « libérabilité ». Cette mesure met l’accent sur la capacité des équipes de développement de logiciels à toujours commercialiser leurs produits et constitue une mesure concrète de l’efficacité du pipeline de livraison continue (CD) d’une entreprise.

En réalité, atteindre un score de release élevé signifie travailler à une qualité élevée et constante, avec une détection et une résolution rapides des incidents, ainsi qu’un retour d’information et une récupération rapides, le tout intégré aux plates-formes sur lesquelles les développeurs travaillent pour fournir des logiciels de haute qualité à leurs clients.

Les métriques de base DORA pour une livraison continue

Dans le cadre DORA, il existe une vaste gamme de mesures qui peuvent être mesurées, ainsi que leur impact sur les performances de développement logiciel d’une organisation. Ces mesures peuvent être des capacités et des processus techniques, tels que l’intelligence artificielle (IA), l’intégration continue (CI) ou la vitesse de révision du code, ou des mesures qui peuvent être plus étroitement liées aux performances.

Ce deuxième groupe est essentiel pour mesurer les performances du CD. Les deux indicateurs clés de ce groupe sont la stabilité et le débit. Le premier est une démonstration du taux d’échec des changements d’une organisation et du temps nécessaire pour se remettre de ces échecs, tandis que le second mesure le délai d’exécution de tout changement et la fréquence de ces changements. Ensemble, ces éléments dressent un tableau des réussites d’une organisation en matière de développement logiciel, ainsi que du temps nécessaire pour récupérer en cas d’échec d’un changement. Alors que les organisations visent la référence en matière de CD, il est essentiel de comprendre leurs performances, en particulier lorsque les changements échouent.

Le défi de savoir pourquoi votre produit est tombé en panne

Dans le contexte du CD, les développeurs doivent être capables de comprendre facilement et rapidement pourquoi un produit ou une mise à jour a échoué. Étant donné qu’entre 50 % et 80 % des mises à jour de logiciels échouent, les développeurs doivent être capables d’identifier rapidement le point exact de l’échec et de le résoudre. Cette réduction du temps de résolution des incidents – ou correction des bugs – est l’un des avantages significatifs des développeurs travaillant constamment vers la métrique de la publiabilité. Cela signifie que lorsque des problèmes surviennent, ils sont faciles à résoudre et les cycles de récupération sont rapides.

Pour atteindre des objectifs de développement de plus en plus rapides, les développeurs doivent trouver des moyens de réduire le temps consacré à la réponse aux incidents et au dépannage. Pour y parvenir, ils ont besoin d’accéder à des informations en temps réel qui leur permettent d’identifier, de diagnostiquer et de résoudre tout incident dès qu’il survient. Ces informations peuvent donner aux développeurs une compréhension instantanée et compréhensible de la façon dont les changements affectent leurs pipelines de développement logiciel, même lorsque les changements ne sont pas suffisamment importants pour provoquer un incident.

Ces « événements de changement » offrent un fil d’Ariane à travers chaque modification apportée à un produit tout au long de son cycle de développement, permettant aux développeurs de voir les effets directs de chaque mise à jour. Celles-ci vont de la manière dont le code d’application est déployé jusqu’à la manière dont la mise à l’échelle d’un service peut affecter ses performances. Ce qui est peut-être le plus utile, c’est qu’ils sont disponibles non seulement tout au long du cycle de développement d’un produit, mais également après sa mise sur le marché. Cela permet de traiter et de résoudre tout incident ou baisse de performance dès qu’il survient.

Modifier la corrélation : La clé d’une livraison continue et de qualité

Même si les informations fournies par les événements de changement sont utiles aux développeurs, la corrélation des changements va encore plus loin dans la résolution des incidents. Cela fournit aux développeurs travaillant sur le retour d’un produit à un état publiable les événements de modification récents les plus pertinents pour un incident. Les données de ces événements peuvent ensuite être introduites dans un modèle d’apprentissage automatique et analysées pour établir des corrélations entre les événements de changement passés et les incidents, permettant ainsi un diagnostic et une résolution rapides des incidents. Pour aller plus loin dans cette stratégie de résolution d’incidents, toutes ces données peuvent être situées sur une plate-forme unique qui suit les événements de changement et aide également à corréler les changements individuels aux ruptures au sein des produits.

Il est possible de détecter l’impact exact d’un changement sur un produit car chaque événement de changement contient des informations contextuelles liées à son heure et au service auquel il a été appliqué. Il s’agit de données très précieuses et, lorsqu’elles sont disponibles en un coup d’œil, elles permettent aux équipes de réponse aux incidents de trier rapidement les incidents et de réduire le temps de résolution, garantissant ainsi la stabilité des services fournis par une organisation.

Les avantages de comprendre le changement

Les informations fournies par les événements de changement permettent aux développeurs d’identifier exactement quels changements ont affecté leurs produits et comment. Le résultat direct en est une réduction significative des travaux imprévus. Grâce à une corrélation intelligente des modifications, le processus fastidieux consistant à identifier exactement les modifications qui ont endommagé un produit peut être automatisé, réduisant ainsi davantage la charge de travail des développeurs dans les moments critiques. Cela permet aux développeurs de se concentrer sur l’innovation et d’apporter de la valeur à leurs clients, plutôt que de devoir simplement réparer des produits défectueux.

Mandi Walls est une défenseure du DevOps chez PagerDuty. Elle intervient régulièrement lors de conférences techniques et est l’auteur du livre blanc d’O’Reilly Media « Building a DevOps Culture ». Elle s’intéresse à l’émergence de nouveaux outils et…

Lire la suite de Mandi Walls