Close

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

La livraison continue améliore la vélocité, la productivité et la durabilité des équipes de développement.

Portrait de Juni Mukherjee
Juni Mukherjee

Auteur collaborateur

Pourquoi la livraison continue ?


Quelles émotions le mot « livraison » déclenche-t-il en vous ? Soulagement ? Exaltation ? Un vif sentiment d'accomplissement ? Lorsque de nouvelles fonctionnalités sont enfin disponibles pour les clients et que les bugs sont corrigés, tout le monde est heureux, n'est-ce pas ? Mais de nombreuses organisations cachent un terrible secret : la livraison d'une version demande énormément d'efforts. Si votre équipe utilise toujours des tests manuels pour se préparer aux livraisons et des déploiements manuels ou semi-scriptés pour les exécuter, vos sentiments pourraient bien être plus proches de la « crainte » et de la « colère aveugle ».

Capture d'écran du cycle émotionnel de la livraison manuelle

C'est pourquoi le développement de logiciels évolue vers la continuité grâce à des méthodologies comme Agile et DevOps. Dans le paradigme de la continuité, des produits de qualité sont livrés aux clients fréquemment et de façon prévisible. Par conséquent, le caractère cérémonial et le risque lié aux livraisons sont réduits. Si vous utilisez vos pipelines tous les jours, vous remarquerez (et vous résoudrez !) les défaillances beaucoup plus rapidement que si elles apparaissaient par intervalles de quelques semaines ou quelques mois. En d'autres termes, réduisez les difficultés en augmentant la fréquence de vos livraisons de produits. Une culture d'amélioration continue est une métrique DevOps pour les équipes ultra performantes.

L'accent mis sur la livraison continue (CD), notamment l'intégration continue, les tests continus, la surveillance constante et l'analyse des pipelines, reflète une tendance globale dans le secteur des logiciels : aider les équipes à réagir à l'évolution du marché. Ne vous y trompez pas, la CD n'est pas l'apanage des entreprises « licornes » et des cracks de la technologie. Chaque équipe (de la start-up la plus modeste à l'entreprise la moins flexible) peut et doit avoir recours à la livraison continue.

Cet article décrit cette transition, les travaux à accomplir et les avantages qui en découleront pour la livraison de logiciels à l'aide de pipelines CD.

Découvrir la solution

Développez et exploitez des logiciels grâce à Open DevOps

Ressources connexes

Mesurez la fréquence de déploiement

Principaux avantages métier de la livraison continue


La livraison continue améliore la vélocité, la productivité et la durabilité des équipes de développement.

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.

Bug

Ainsi, dans le monde de la livraison continue, la vélocité implique une vitesse responsable, et non imprudente.

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.

Personnages observant un workflow de développement logiciel

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.

Principaux défis de la livraison continue


Bien que nous croyons fermement que la livraison continue est la bonne pratique à adopter, il peut s'avérer difficile pour les organisations de concevoir et de créer des pipelines de livraison continue résilients. Dans la mesure où la CD nécessite une refonte en profondeur des processus techniques, de la culture opérationnelle et de la pensée organisationnelle, on a souvent l'impression qu'il y a de grands obstacles à surmonter avant de se lancer. Le fait que cette méthode nécessite un investissement important dans l'infrastructure de livraison de logiciels d'une entreprise, qui peut avoir été négligée au fil des ans, peut en faire une pilule encore plus amère à avaler.

Les organisations sont confrontées à de nombreux problèmes. Les trois exemples suivants constituent les pièges les plus courants : budget, personnel et priorité.

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 !

Indicateurs de livraison continue


OLTP (Online Transaction Processing) et OLAP (Online Analytical Processing) sont deux techniques bien connues dans le secteur. Ces deux concepts s'appliquent aux pipelines de livraison continue et permettent de générer des données qui orienteront les organisations dans la bonne direction. Voyons comment.

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.

Illustration de deux collègues se regardant et assis à un bureau avec des écrans

C'est une bonne transition vers la section suivante sur l'analyse des pipelines et sur la façon de tirer le meilleur parti de ces 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


Ne perdez pas de temps à vous demander si la livraison continue vous convient, si l'intégration continue est suffisante ou si le déploiement continu est votre paradis. Si vous lancez ce processus, il offrira des perspectives d'amélioration continue pour votre équipe ! Il aidera vos équipes à réaliser des tests sans aucune crainte et à ne pas s'épuiser en raison de livraisons nocturnes.

Découvrez comment créer un pipeline d'intégration, de livraison et de déploiement continus (CI/CD) grâce à nos tutoriels sur la CI/CD dans DevOps. En outre, Atlassian Open DevOps fournit une plateforme de chaîne d'outils ouverte qui vous permet de créer un pipeline de développement de CD avec les outils que vous aimez.

Juni Mukherjee
Juni Mukherjee

Juni is a thought citizen in the DevSecOps space and has made deep investments in the field of Continuous Delivery. She has helped organizations build Continuous Delivery Pipelines, and would love to solve the problems that plague our industry today. She has authored a couple of books.


Partager cet article

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Illustration DevOps

Communauté DevOps

Illustration DevOps

Lire le blog

Illustration d'une carte

Essayez la solution gratuitement

Inscrivez-vous à notre newsletter DevOps

Thank you for signing up