Durant le printemps, nos experts OCTO vous proposent un cycle de contenus autour du Cloud. Le sujet vous intéresse ? Pour découvrir le programme et ne rien rater, inscrivez-vous sur notre page Cloud, DevOps & Plateformes.
Vous devez impérativement réduire le time to market des fonctionnalités de votre backlog pour répondre aux besoins croissants des utilisateurs, conserver la confiance et rester compétitif. Pour répondre à ces enjeux, vous devez passer à l’échelle et surtout réussir ce passage à l’échelle à la maille de votre organisation.
Dans le même temps, vous faites le difficile constat que votre backlog de bug n’arrête pas de croître, que vos 3 dernières livraisons en production se sont mal passées et ont généré beaucoup de stress, que des problèmes de performance sont apparus suite à la dernière livraison, que des tensions naissent entre les équipes de développement et d’infrastructure…bref, il est temps de prendre du recul sur votre processus actuel de delivery et de s’intéresser aux leviers techniques, méthodologiques et culturels derrière la mise en place du Continuous Delivery.
C’est au début des années 2000 que le Continuous Delivery a émergé, en parallèle de l’Agile, pour répondre aux nouveaux défis de l’industrie du développement logiciel. Les longues périodes de développement suivies de tests et de déploiements manuels n’étaient plus adaptées à la vitesse attendue et à la complexité croissante des projets. Pire que cela, la valeur in-fine livrée tardivement ne correspondait plus aux besoins des utilisateurs avec ce fonctionnement tunnelisé et cloisonné.
Jez Humble et David Farley ont publié en 2010 un livre intitulé “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation” dans lequel ils présentent et fournissent un cadre complet pour mettre en place - et surtout maintenir dans la durée - cette fameuse livraison continue. Aujourd’hui, ce livre demeure une référence pour trouver le bon niveau d’automatisation, pour construire son processus d’intégration et de déploiement (Continuous Integration / Continuous Deployment), pour définir sa politique de release management ou poser sa stratégie de tests.
Les pratiques techniques ont parfois été mises au second plan avec des investissements concentrés sur les pratiques d’équipes et de management alors que c’est bel et bien un équilibre à trouver pour atteindre les objectifs de performance et pour avoir des livraisons plus fréquentes, de meilleure qualité et moins risquées.
La sortie du livre Accelerate en 2018 (Accelerate, la vitesse conditionne l’excellence : un nouveau paradigme dans le développement logiciel) est venue enfoncer le clou sur les apports du Continuous Delivery. Suite à plusieurs années de recherche itérative portées par DORA (DevOps Research & Assessment), il a été démontré que les organisations qui avaient adopté les pratiques et les composantes du Continuous Delivery avaient une performance meilleure et des bénéfices sur d’autres dimensions, notamment humaines, sociales et culturelles.
L’adoption du Continuous Delivery joue donc un rôle clé catalyseur sur bon nombre de dimensions. Mais le chemin à parcourir pour y parvenir et pour le maintenir dans la durée n’est pas tout tracé. Ce n’est effectivement pas un ensemble de pratiques / composantes qu’on met bout à bout mais c’est bel et bien toute une organisation qui va devoir embrasser et apprendre de nouveaux automatismes et modes d’interactions.
Cela nécessite bien souvent de repenser la façon dont les équipes travaillent, la façon dont les équipes interagissent ainsi que les outils et les processus utilisés. Il faut des efforts et des investissements continus pour automatiser les tests, automatiser les déploiements et former les équipes. Et le dernier point clé, c’est le travail continu et permanent de simplification de l’architecture pour faire en sorte que l’automatisation ne soit pas trop chère à créer et à maintenir dans le temps.
À partir de là, il faut intégrer et voir le Continuous Delivery comme un processus apprenant dans lequel il faut continuellement investir pour garantir des livraisons d’incréments de valeurs jusqu’en production en toute sécurité, rapidement et durablement.
Sans mesure pour définir et créer de l’alignement sur la situation actuelle et la situation désirée d’une équipe ou d’une organisation, toute tentative de résolution de problèmes ou d’amélioration se fait à l’aveugle avec le risque de ne pas prendre les bonnes décisions et la bonne trajectoire. La mesure est donc un prérequis pour prendre conscience de la situation de départ et pour suivre l’évolution de la situation en validant, pas à pas, la pertinence des actions d’amélioration lancées.
Lorsque les indicateurs mis en place et la façon de les calculer sont compris et partagés, il n’y a plus de remise en cause et c’est le collectif qui se mobilise pour lancer des initiatives et prendre des actions concrètes d’amélioration continue.
Un bon indicateur doit présenter les 3 caractéristiques suivantes :
Il doit être global et non local : l’indicateur doit s’inscrire à l’échelle de l’organisation et favoriser la collaboration entre les équipes.
Il doit être centré sur l’impact, le résultat et non sur la productivité.
Il doit être stable et répétable, dans le temps, pour pouvoir mesurer son évolution (progression, stabilisation ou régression).
L’étude Accelerate ainsi que la publication annuelle des rapports State of DevOps par DORA (DevOps Research Assessment) nous pointe les 5 indicateurs de performance qu’il faut suivre sur le volet du delivery (4 indicateurs de Software Delivery Performance) et sur le volet opérationnel (1 indicateur sur l’Operational Performance)
Extrait du State of DevOps 2021 listant les 5 indicateurs
Côté Software Delivery Performance, on trouve :
2 indicateurs de débit/vitesse
Lead time for changes : cet indicateur mesure la rapidité de mise à disposition en production du code finalisé. Combien de temps me faut-il pour envoyer une modification de code en production ?
Deployment frequency : cet indicateur mesure la capacité à mettre en production avec la cadence et le débit des mises en production. A quelle fréquence le code est-il déployé en production ?
2 indicateurs de stabilité
Time to restore service : cet indicateur mesure le temps nécessaire pour restaurer un service métier qui ne fonctionne plus. Combien de temps me faut-il pour restaurer un service inopérant ?
Change failure rate : cet indicateur mesure la stabilité et la qualité du code livré. Quel est le ratio de déploiement considéré comme des échecs ?
Côté Operational Performance, on trouve l’indicateur de Reliability. Cet indicateur reflète la capacité d’une équipe à tenir ses engagements sur le ou les produits qu’elle exploite (tenue des promesses sur les assertions concernant la disponibilité, la latence, la performance ou encore la scalabilité). Pour en savoir plus, nous vous invitons à suivre le prochain épisode de la campagne Cloud, intitulé SRE is the NEW RUN.
Dans l’article ci-dessous, vous pourrez découvrir comment nous avons amélioré le processus de delivery d’une plateforme digitale d’un acteur mondial de l'énergie pour passer le déploiement d’une release de 100 jours à 1 semaine. 2 chantiers ont été lancés en parallèle : le Domain Driven Design sur un périmètre de l’application et la mise en place de la démarche Accelerate. ➡️ Ma rencontre avec Accelerate et son impact au sein des équipes
Pour aider à l’analyse et à l’audit de votre processus de delivery, OCTO a développé un outil spécifique OctoBench Freemium qui permet de questionner les pratiques et les résultats de performance autour de 5 thématiques distinctes : Continuous Delivery, Product & Process, Architecture, Lean Management & Monitoring, Culture. L’outil est alors en capacité de formuler une liste de recommandations en pointant explicitement les leviers à activer pour améliorer la performance de delivery. ➡️ Réalisez le test pour vous faire une idée : quelques minutes suffisent 🙂
Accelerate© : adopter les bonnes pratiques pour un delivery plus performant, rapide et stable
GitLab CI et CD : Gestion des sources et Intégration continue avec GitLab
Continuous discovery et continuous delivery pour construire l'assurance de demain. Nos experts vous présenterons ici une démarche liant expérimentation et déploiement via les outils du DDD permettant de faire pivoter un produit rapidement. Rendez-vous le mardi 16 mai de 9h15 à 10h pour Le Comptoir OCTO x Wakam : infos et inscriptions ici.
Pour tout savoir sur les enjeux Cloud, DevOps et Plateformes, cliquez ici.