Livraison continue : valeur métier, avantages, défis et métriques

1. Vélocité

Les pipelines de distribution de logiciels automatisés aident les organisations à mieux répondre à l'évolution du marché. Le besoin de vitesse est de la plus haute importance pour réduire le délai de mise en service des nouvelles fonctionnalités. Avec un délai de commercialisation (time-to-market) court, les organisations ont plus de chances de surpasser leurs concurrents et de rester à flot.

Rappelez-vous que la vitesse en soi n'est pas une métrique de réussite. Sans qualité, la vitesse est inutile. Il est inutile de disposer de pipelines de livraison continue qui envoient à grande vitesse du code erroné en production.

2. Productivité

La productivité se traduit en bonheur, et des équipes heureuses sont plus impliquées.

La productivité augmente lorsque des tâches fastidieuses et répétitives, comme remplir un rapport de bug pour chaque défaut découvert, peuvent être effectuées par des pipelines plutôt que par des humains. Les équipes peuvent ainsi se concentrer sur la conception pendant que les pipelines s'occupent de l'exécution. Qui ne souhaiterait pas déléguer le gros du travail à des outils ?

Les équipes enquêtent sur les tickets créés par leurs pipelines et, une fois qu'ils ont committé le correctif, les pipelines s'exécutent à nouveau pour vérifier si le problème a été résolu et si de nouveaux problèmes ont été introduits par inadvertance.

3. Durabilité

Les entreprises cherchent à gagner des marathons, pas seulement des sprints. Nous savons qu'il faut du courage pour devancer le peloton. Garder constamment une longueur d'avance peut même s'avérer encore plus difficile. Il faut de la discipline et de la rigueur. Travailler dur 24 heures sur 24 et 7 jours sur 7 entraînera un épuisement professionnel précoce. Au lieu de cela, travaillez intelligemment et déléguez le travail répétitif à des machines qui, soit dit en passant, n'ont pas besoin de pauses café et ne répondent pas !

Chaque organisation, qu'elle soit ou non une entreprise de technologie, utilise la technologie pour se différencier. Les pipelines automatisés réduisent le travail manuel et permettent de réaliser des économies dans la mesure où le personnel est plus coûteux que les outils. L'investissement initial est considérable et peut inquiéter les équipes de direction peu expérimentées. Toutefois, des pipelines bien conçus permettent aux organisations d'innover mieux et plus rapidement pour répondre aux besoins de leurs clients. La CD offre plus de souplesse à l'entreprise dans la façon dont elle fournit des fonctionnalités et correctifs. Des ensembles de fonctionnalités spécifiques peuvent être mis à la disposition de certains clients ou livrés à un sous-ensemble de clients, pour s'assurer qu'ils fonctionnent et évoluent comme prévu. Les fonctionnalités peuvent être testées et développées, mais laissées inactives dans le produit, ce qui permet de préparer plusieurs versions. Votre service marketing souhaite faire sensation lors de la convention annuelle du secteur ? Avec la livraison continue, c'est possible et c'est même une demande futile.

Budget : est-il trop faible ?

La création de pipelines de livraison continue mobilise vos meilleures ressources. Il ne s'agit pas d'un projet parallèle dont le coût peut être dissimulé. J'ai toujours été surpris de voir comment certaines organisations commencent par affecter des membres subalternes et par faire des économies sur l'achat d'outils modernes. À un moment donné, elles changent de cap et confient à leurs architectes expérimentés le soin d'investir dans le découplage de l'architecture et la création de pipelines de livraison continue résilients.

Ne sous-estimez pas les efforts nécessaires. En fonction de votre vision, réservez des fonds appropriés pour vous assurer que l'exécution est ininterrompue. Livrez un pipeline de livraison continue MVP (produit minimum viable) et déployez-le dans l'ensemble de votre organisation.

Avez-vous des avant-gardistes dans vos rangs ?

Même si vous avez le budget, au bout du compte, l'exécution pourrait poser un problème de personnel.

Les équipes doivent automatiser sans crainte leurs tâches pour pouvoir passer à de nouveaux projets. Si certains employés redoutent que des agents automatisés effectuent les tâches qu'ils réalisaient manuellement, vous avez embauché les mauvaises personnes.

Si vous vous sentez bloqué, changez de vitesse. Quand les membres de votre équipe demandent simplement un cheval plus rapide, apprenez comment leur fournir une voiture ! Lancez-vous en vous appuyant sur des champions expérimentés qui vous aideront à passer ce premier obstacle. Après tout, les membres de votre personnel constituent votre meilleur atout, donc formez-les à faire ce qu'il faut. Faites en sorte qu'il soit facile de faire ce qu'il faut et difficile de faire ce qu'il ne faut pas, et vous serez agréablement surpris du résultat.

Manque de priorité

Aucun product owner n'a jamais dit : « Arrêtons la ligne et créons des pipelines de livraison continue ! ».

À leur décharge, ils sont concentrés sur le fait de garder une longueur d'avance sur la concurrence avec de nouvelles fonctionnalités qui impressionnent le monde. En même temps, vous savez que vous avez un problème si dans chaque planificateur de sprint, les pipelines sont comparés aux fonctionnalités du produit et sont abandonnés.

Dans certains backlogs produit, les pipelines, lorsqu'ils y apparaissent, figurent en bas de la hiérarchie pour tenter de rester en vie. Les dirigeants adoptant une vision à court terme classent les travaux liés aux pipelines dans la catégorie des dépenses plutôt que dans celle des investissements qui seront utiles aux équipes. Ils restent dans le déni des dommages à long terme qu'ils créent et, malheureusement, s'en tirent parfois impunément.

Les pipelines sont un peu comme l'hygiène. Si vous voulez rester à flot, demandez-vous si l'hygiène est importante. Bien évidemment qu'elle l'est !

Les pipelines voient des montagnes de données transactionnelles

Imaginez la journée type d'une équipe de développement. L'équipe commite une fonctionnalité priorisée par l'entreprise, commite les tests pour cette fonctionnalité et intègre les déploiements au pipeline de livraison continue, de sorte que chaque changement se déploie automatiquement. Elle note un ralentissement de l'app après l'ajout de cette nouvelle fonctionnalité et commite une correction pour résoudre le problème de performance. Elle ajoute également des tests de performance pour s'assurer que les délais de réponse inadéquats sont détectés avant de faire passer l'app de l'étape de test à celle du staging.

Considérez chacun de ces commits comme une transaction. C'est ainsi que les équipes de développement procèdent, une transaction après l'autre, jusqu'à ce qu'un produit qui impressionne le monde entier voie le jour. Ensuite, elles recommencent. Multipliez ces transactions entre tous les ingénieurs et toutes les équipes de votre organisation, et vous obtenez des montagnes de données transactionnelles.

Analysons les données transactionnelles du pipeline

Pourrions-nous analyser les données transactionnelles pour en extraire des fragments d'information ? Bien sûr que oui !

Comme pour toutes les données transactionnelles, le simple volume nous empêche de dégager une logique. C'est pourquoi nous devons regrouper et effectuer des analyses pour recueillir des informations sur notre organisation. Les analyses empêchent que les arbres ne cachent la forêt. Voici trois exemples d'améliorations apportées à nos pratiques sur la base des informations et des analyses de pipeline.

Sur les centaines de déploiements réalisés chaque semaine, nous avons constaté que les défaillances de déploiement de l'app A étaient trois fois plus nombreuses que pour l'app B. Cette découverte nous a amenés à étudier les choix de design de l'app A en matière de stabilité de l'environnement et de gestion des configurations. Nous avons appris que l'équipe utilisait des machines virtuelles peu fiables dans son data center pour le déploiement, tandis que l'app B était conteneurisée. Nous avons priorisé l'investissement dans une infrastructure immuable et nous avons vérifié un mois plus tard que le retour sur investissement était au rendez-vous. Il l'était. Ce qui peut être mesuré peut donc être corrigé.

Autre exemple : nous avons appris que les erreurs d'analyse du code statique de l'application B avaient augmenté de façon constante au cours des derniers trimestres. Ceci pouvait indiquer que l'équipe en charge de l'application B devait être (re)formée pour programmer un code de meilleure qualité. Nous avons également découvert que les analyseurs du code statique signalaient les faux positifs et indiquaient donc des violations de code alors qu'il n'y en avait pas. Par conséquent, nous avons mis à niveau leur analyseur vers un outil de référence très connu, et les faux positifs ont été réduits dans une certaine mesure. Nous avons organisé un atelier de programmation durant lequel nous avons discuté et résolu les erreurs légitimes d'analyse statique. À la fin, tout marchait à nouveau comme sur des roulettes.

Autre fait intéressant : les tests unitaires de l'application A avaient une couverture de code inférieure à celle des applications B et C, et pourtant l'application A est celle qui a rencontré le moins de tickets de production au cours de l'année passée. La programmation des tests unitaires et la mesure de la couverture du code sont satisfaisantes. Exécuter ces deux tâches de manière excessive est improductif pour l'équipe et inutile pour les clients. Nous avons retenu la leçon.

Indicateurs de performance clés (KPI)

Nous ne pouvons pas nous fier à des opinions lorsqu'il s'agit de guider l'organisation dans la bonne direction. Tout d'abord, nous devons définir les indicateurs de performance clés (KPI) en fonction de critères de réussite. Deuxièmement, nous devons prendre des décisions fondées sur des données en analysant les KPI sur plusieurs mois, trimestres et années.

KPI organisationnels et KPI des services

Nous avons souvent vu des services définir leurs propres critères de réussite. C'est une bonne chose que les services comprennent les critères de leur réussite, dans la mesure où ces indicateurs sont liés aux objectifs de l'organisation.

Échecs aux tests, staging et production

Certaines organisations exigent que l'équipe de développement soit responsable de l'environnement de test, que l'équipe de QA soit responsable du staging et que l'équipe opérationnelle soit responsable de la production. Plutôt que de s'immerger dans les rapports de couverture du code pour les tests unitaires qui s'exécutent dans l'environnement de test, il est important que les développeurs prennent du recul et envisagent les environnements dans leur ensemble, qu'ils en soient responsables ou non.

Dans l'environnement de staging, le pourcentage de défaillances dues aux tests de performance pourrait être élevé et résulter de benchmarks de performance incorrects ou d'un code lent. Une analyse comparative pourrait montrer que les pipelines échouent le plus souvent lors des smoke tests d'intégration en production, ce qui justifierait une enquête. La cause profonde ? De vrais bugs dans le produit ou un code de test rempli de bugs, des données de test inexactes, une configuration de test incorrecte, ou encore des malentendus entre les équipes de produit et d'ingénierie.

Des recherches plus approfondies pourraient révéler que les configurations de test incorrectes prolifèrent, et vous pourriez prioriser la résolution de ces tickets afin de corriger les échecs d'intégration fréquents. De plus, les développeurs qui sont responsables de leur code jusqu'à la production sont également en accord avec le paradigme DevOps.

Indice de stabilité

Après avoir défini les indicateurs de performance clés (KPI), nous devons absolument comprendre si un KPI a tendance à s'orienter fortement dans une direction spécifique. Si c'est le cas, nous devons l'équilibrer avec d'autres KPI qui permettent de trouver un juste milieu. La stabilité est l'un d'eux.

Les développeurs mesurent la stabilité avec FeatureLeadTime, qui correspond au temps nécessaire à la mise en production d'une fonctionnalité. Une fonctionnalité comprend plusieurs commits, et donc une mesure plus granulaire de FeatureLeadTime est CheckIn2GoLive, qui correspond au temps nécessaire pour qu'une vérification soit mise en production.

Évaluez Checkin2GoLive via les pipelines. Vous pouvez calculer cette métrique approximativement en estimant le temps nécessaire à un pipeline pour promouvoir le code de la phase de test au staging et à mis en production. En outre, Checkin2GoLive reflète également les défauts de MTTR (durée moyenne de résolution), puisque la correction de bug passe par le même pipeline, du test à la production en passant par le staging.

Il est intéressant de noter que lorsque j'ai posé la question aux membres de l'équipe opérationnelle, la vitesse a souvent une connotation négative dans leurs réponses, puisqu'elle incite à rejeter les risques. Ils mesurent le nombre de défauts non détectés pour tenir compte des défaillances et ils définissent la stabilité en fonction du pourcentage de défauts détectés par le pipeline par opposition aux défauts non détectés.

L'entreprise définit la stabilité en fonction de la satisfaction client ou du nombre de clients réguliers. Bien que cela puisse paraître subjectif, vous pouvez estimer cette métrique grâce au nombre de défauts signalés par les clients ou aux enquêtes de satisfaction réalisées auprès de ces derniers.

L'indice de stabilité est l'exemple type d'un sujet à propos duquel les équipes de développement, opérationnelles et métier campent sur leur point de vue, alors qu'il est préférable pour l'organisation de s'appuyer sur plusieurs points de vue plutôt que sur un seul. Il convient donc de créer un indice organisationnel de stabilité qui soit impartial.

Indice de qualité du code

Autre exemple dans lequel différents points de vue doivent être pris en compte : la qualité du code. Certains affirment que la qualité de notre code est reflétée par la couverture du code mesurée par des tests unitaires, tandis que d'autres estiment qu'il s'agit d'une complexité cyclomatique. Les analyseurs statiques standard signalent les duplications de code, les failles de sécurité et les fuites de mémoire potentielles. Tous ces signaux sont de réels indicateurs de la qualité du code et créent donc un indice dans lequel toutes ces mesures, et éventuellement d'autres, jouent un rôle.

KPI opérationnels et KPI techniques

Autre KPI populaire que les organisations aiment surveiller : la valeur livrée dans un sprint. Une mauvaise pratique courante consiste à enregistrer le nombre de versions qui, en elles-mêmes, n'apportent aucune valeur ajoutée. Vous pourriez déplacer des bits d'un point A à un point B sans changer les choses pour votre entreprise, mais ce ne serait pas suffisant. Certaines organisations mesurent le nombre de tests nouvellement ajoutés au sprint ou le nombre total de tests exécutés, mais ceux-ci ne reflètent pas non plus les résultats métier, seulement les efforts d'ingénierie. La valeur délivrée dans un sprint doit être pertinente pour l'entreprise.

Le nombre d'acquisitions de clients au cours du dernier trimestre et le nombre de clics publicitaires au cours du dernier mois pourraient être des exemples d'indicateurs clés de performance de l'entreprise. Les pipelines n'influencent pas directement ces paramètres opérationnels. La seule raison pour laquelle nous essayons d'établir une correspondance entre les KPI opérationnels et les KPI techniques est de comprendre la relation entre le savoir-faire technique et les objectifs métier.

Les KPI opérationnels, lorsqu'ils sont mis en correspondance avec les pipelines, nous aident également à calculer le ROI (retour sur investissement) des pipelines. Les équipes de direction utilisent ces métriques pour comprendre les domaines d'amélioration possibles et pour planifier en fonction du budget.

Entamez votre transition