Introduction
La livraison continue, ou Continuous Delivery, est une stratégie qui attire de plus en plus l'attention et gagne en reconnaissance dans l'entreprise, autant côté technique que métier.
Celle-ci permet d'apporter rapidement et de façon répétée des améliorations de service sur le marché. Cette capacité s'aligne naturellement avec les initiatives business dans le contexte économique compétitif actuel, en accélérant le time-to-market tout en maintenant le niveau de qualité. Des changements fréquents et incrémentaux aident aussi à satisfaire les attentes de l'utilisateur moderne, "toujours connecté", pour qui l'expérience des services informatiques, dans le cadre du travail comme des loisirs, s'appuie de plus en plus souvent sur des applications s'installant simplement, en un seul clic, et se mettant à jour automatiquement.
Des initiatives telles que la virtualisation, les Clouds privés ou des démarches DevOps sont en marche au sein de nombreuses entreprises, apportant les fondations techniques pour la livraison continue. Avec tout ceci, combiné à la pression compétitive créée par les leaders de l'industrie qui ont réussi dans l'adoption de cette pratique, il n'est pas surprenant de lire des enquêtes mentionnant que l'implémentation de Continuous Delivery fait partie des initiatives actuelles clés dans de nombreuses entreprises.
Où Commencer ?
Le concept de livraison continue n'est pas complètement nouveau ; certains précurseurs le pratiquent depuis plusieurs années. Par conséquent, il existe de nombreux livres et autres références qui en décrivent les principes et les pratiques, certains donnant même une illustration détaillée de ce à quoi la cible de la démarche peut ressembler.
Ces documents peuvent vous apporter des bases théoriques importantes et vous aider à développer une vision vers la livraison continue. C'est plutôt pour répondre à la question du comment s'atteler à la réalisation de cette vision qu'un accompagnement supplémentaire est nécessaire, spécialement dans le contexte d'environnements de développement et de Release préexistants au sein d'une grande entreprise.
Notre expérience, acquise en aidant nos clients à découvrir la livraison continue et l'automatisation correspondante, ainsi que nos partenariats avec d'autres experts en la matière, comme ThoughtWorks, est utile. Nous allons décrire les étapes importantes de la préparation d'une approche structurée de l'implémentation de la livraison continue, qui doit vous mener de là où vous en êtes aujourd'hui à la réalisation de votre projet en suivant des phases bien définies et mesurables.
Avant l'implémentation : identifier les défis potentiels
Comme dans toute implémentation de pratiques, une image claire de la situation est importante. La prise de conscience de l'état de départ, la "baseline", et les défis en résultant sont des prérequis pour une implémentation réussie de la livraison continue.
En nous appuyant sur notre expérience dans des entreprises de tailles diverses, nous pouvons décrire un certain nombre de facteurs qui peuvent impacter une implémentation de la livraison continue.
Tous ces facteurs ne seront pas pertinents dans votre contexte. Pour ceux que vous reconnaitrez, il devrait y correspondre une action dans votre plan projet pour identifier le périmètre des challenges associés, leurs impacts potentiels sur les objectifs de livraison et les étapes possibles de mitigation.
Les défis de l'entreprise
1. Les applications monolithiques
Un aspect essentiel de Continuous Delivery est la nécessité d'apporter des changements de taille réduite, par incréments, à vos applications et services. Les changements de cette nature sont plus simples à tester et, puisque seule une petite partie de l'application change à chaque à fois, l'identification et la correction des sources d'erreurs ou autres problèmes tels que les pertes de performance, sont facilitées.
Chaque changement ayant un impact plus restreint sur vos environnements cibles que les Releases habituelles, type "big bang", celui-ci peut généralement passer aussi plus rapidement à travers le pipeline de livraison. Ceci induit des exécutions plus rapides, des cycles "développement-à-production" plus courts et ainsi, des fonctionnalités sortant plus fréquemment.
Les applications de taille importante, fortement couplées, dans lesquelles un grand nombre de composants doivent être compilés, testés et déployés ensembles sont difficiles à modifier de façon incrémentale ; ce qui conduit à des cycles de développements, tests et déploiements beaucoup plus longs. Le contrôle de qualité, et en particulier l'analyse des causes profondes ("Root Cause Analysis"), est plus compliqué aussi, à cause des multiples changements apportés au même moment.
Le grand nombre de changements et de composants à mettre à jour implique aussi, très souvent, des différences sensibles d'une procédure de livraison à l'autre. Il est ainsi difficile de mettre en place une standardisation du pipeline de livraison et donc d'en tirer un bénéfice de fiabilité.
Comme dans tout processus itératif, s'améliorer en s'appuyant sur des feedbacks rapides est une clé de la réussite de la mise en place de Continuous Delivery. Tirer des conclusions pertinentes à partir d'un énorme paquet d'informations après une release monolithique est très difficile à cause des nombreux changements et autres facteurs spécifiques à considérer.
Des exécutions plus petites, plus rapides, plus standardisées simplifieront le feedback et les cycles d'améliorations.
L'histoire d'une grosse application
Dans le cadre d'une transition vers une méthode de développement plus agile avec des itérations plus courtes, une grande société d'assurance a commencé à mettre en place le pipeline de livraison d'une plate-forme de traitement des déclarations. La plate-forme était constituée d'une application unique, s'appuyant sur un Framework développé en interne. Il fallait plus d'une heure pour une compilation complète avec exécution des tests unitaires.
Initialement, à cause des points de terminaison spécifiques à l'environnement se trouvant dans le code source, il était nécessaire d'effectuer une compilation pour chaque environnement. Ainsi, le cycle build, tests fonctionnels, tests d'intégration prenait presque quatre heures, juste pour sortir les livrables !
La première étape consista à externaliser les valeurs dépendantes des environnements, ce qui permit de ne construire qu'un unique livrable, ce qui est préconisé par les principes de Continuous Delivery. À cause de sa taille, plus d'1 Gb, il fallait encore bien 20 minutes, simplement pour copier cet artefact vers l'étape suivante du pipeline et 30 de plus pour son déploiement et son traitement par le middleware cible.
Le résultat fut que les développeurs se mirent à publier leurs changements plus rapidement que le pipeline pouvait en prendre en charge. Pour répondre à cette situation, le pipeline fut configuré pour ne se lancer qu'une seule fois par jour. Ceci fit disparaitre le goulot d'étranglement, cependant, ceci signifiait que les échecs ne pouvaient plus être rattachés à des changements particuliers et donc, qu'il allait être plus difficile de corriger les erreurs rapidement.
Afin de résoudre cette problématique et bénéficier de feedbacks plus rapides, il fallut initier un chantier pour découper les composants de l'application et faire en sorte que chaque module puisse être construit et déployé indépendamment.
2. Niveaux d'automatisation insuffisants
Si vous faites la revue des diverses activités requises actuellement dans votre environnement pour effectuer la transition d'une version de développement vers la production et que vous identifiez plusieurs étapes manuelles, alors vous pourriez avoir besoin de considérer les moyens d'étendre l'automatisation au sein de votre pipeline.
Le but n'est pas d'automatiser à tout prix : les activités manuelles ne sont pas "bannies" par principe d'un pipeline de livraison continue. Simplement, l'expérience montre que les humains ont tendance à être plus lents et moins précis pour réaliser les tâches répétitives, telles que celles faisant partie du gros des tâches réalisées par un pipeline de livraison.
Une quantité d'étapes manuelles trop importante va vraisemblablement vous empêcher d'étendre votre implémentation de la livraison continue au nombre d'exécutions de pipelines que vous auriez espéré. Pour arriver à vos fins en matière de débit et de consistance, il est généralement requis soit d'automatiser la plupart des étapes manuelles de votre processus, soit de supprimer certaines étapes, dans le cas où des alternatives satisfaisantes existent.
Il est important de traiter cet effort d'automatisation aussi sérieusement que tout autre effort de développement, en appliquant les pratiques de conception, de codage et de test appropriées, afin de ne pas finir avec un ensemble informe impossible à maintenir. Le mouvement prônant l'"Infrastructure As Code" a fait des avancées significatives dans ce domaine, par exemple en faisant la promotion du Test Driven Development pour l'automatisation du provisioning et du déploiement et en fournissant des outils de support.
3. Environnements sous contention
Si votre organisation fonctionne actuellement avec un pool d'environnements de tests limités et partagés, il y a un risque que vous soyez confrontés rapidement à un goulot d'étranglement lors de votre implémentation de la livraison continue.
D'abord, la capacité de "bloquer" ou "réserver" un environnement devient nécessaire si votre pipeline de livraison est déclenché au changement de code : il faut empêcher que deux pipelines s'exécutant côte-à-côte essayent de déployer et exécuter les tests sur un même environnement. Des mesures doivent aussi être prises pour éviter qu'un pipeline ne bloque un environnement sur une période de temps trop longue, ou qu'un pipeline accapare systématiquement un environnement avant un autre, ce qui conduirait à une "famine" pour l'autre projet.
Ensuite, un élément intéressant à relever dans les enquêtes mentionnées plus haut est que les environnements mal configurés ou "cassés", modifiés auparavant par une autre équipe ou l'exécution d'un test, sont une des causes principales d'échec de déploiement. Même si vous avez un pool d'environnements de tests suffisamment important pour éviter les famines, les échecs dus à des mauvaises configurations limiteront votre capacité à livrer de façon fiable de nouvelles fonctionnalités.
Si vous prévoyez d'exécuter des pipelines de livraisons à grande échelle, un pool dynamique d'environnements disponibles et "propres" est nécessaire. Les plates-formes Cloud, privées, publiques ou hybrides, couplées à des outils de gestion du provisioning et de la configuration, vous permettront d'agrandir ou rétrécir le pool automatiquement et à la demande.
L'histoire des environnements limités
Après un effort significatif pour développer des tests automatisés, une entreprise du domaine de la distribution implémenta un pipeline de publication pour un important site Web destiné à ses clients. En plus de permettre des publications plus rapides de nouveaux contenus, un autre bénéfice escompté consistait en une meilleure utilisation des trois environnements de test, qui étaient jusque-là difficiles et coûteux à installer à cause d'une intégration complexe entre le CMS, les serveurs Web et d'autres points de terminaison externes. Afin d'éviter les conflits pour les environnements, un système d'exécution "à tour de rôle" avait été implémenté, dans lequel l'exécution d'un pipeline était bloquée jusqu'à ce que l'environnement suivant soit disponible.
Avec les changements de contenu fréquents, il devint rapidement visible que l'une des suites de tests de longue durée, celle qui vérifiait les sessions d'achat, provoquait un arrêt des pipelines et surchargeait finalement l'orchestrateur. Tout d'abord, un timeout fut ajouté pour permettre aux pipelines de se remettre en route. À la suite de quoi les tests se mirent à se comporter de manière erratique, certaines exécutions se mettant à échouer puis à passer tout de suite après, sans raison apparente.
Des investigations mirent en évidence que le timeout perturbait la procédure de nettoyage de la base de données et induisait une corruption des environnements. Pour éviter cela, la suite de tests de longue durée fut simplement désactivée, au prix d'une dégradation de la couverture des tests. L'équipe dût serrer les dents et mettre en place du provisioning automatique pour leurs environnements de tests et développer des versions mockées des points de terminaison externes.
La mise en place automatisée des environnements de tests est depuis obligatoire pour tous les projets de l'entreprise.
4. Besoins concernant la gestion des Releases
Le diagramme présentant le pipeline de livraison typique, avec ses étapes et ses feedbacks tout au long du chemin vers la production, est attirant par sa simplicité. En pratique, dès lors que l'on approche la QA ou la production dans la plupart des environnements d'entreprise, de plus en plus d'exigences sur la gestion de la release doivent être satisfaites : créer un ticket de changement, prévoir d'intégrer le changement au programme de la prochaine réunion du comité de changement, recevoir l'approbation du comité de changement, confirmer le créneau pour le déploiement, etc., etc.
"Comment intégrer toutes ces exigences au sein de son pipeline" est une question importante à laquelle les implémentations de la livraison continue en entreprise se doivent de répondre. Une option est de simplement limiter les pipelines de livraison à l'étape des tests, c’est-à-dire avant d'être soumis aux contraintes du Release Management. Cependant, l'objectif est généralement d'aller au-delà.
Les différentes étapes du Release Management peuvent-elles être intégrées au pipeline, par exemple en créant et planifiant manuellement un ticket de changement ? Ou encore en positionnant automatiquement le déploiement du pipeline à partir de la date de lancement récupérée du système de gestion des changements ?
Y-aurait-il possibilité de remettre en question le besoin de certaines contraintes liées à la gestion du changement ? À l'origine, la plupart des pratiques de gestion du changement sont là pour s'assurer que seuls les changements satisfaisant un certain niveau de qualité et de stabilité arrivent en production, et ce niveau de qualité et de stabilité est précisément ce que les étapes précédentes du pipeline doivent vérifier.
L'expérience d'entreprises bien connues, compétentes en matière de livraison continue, comme Netflix, Etsy et autres, indique que la qualité, la traçabilité et la fiabilité des releases peuvent être assurées en s'appuyant sur les pipelines, sans recours à des processus lourds de gestion du changement.
5. Vers plus de Jobs
Au sein d'une entreprise de taille importante, avec des portefeuilles de services diversifiés, il y aura un grand nombre de pipelines à gérer lorsque votre implémentation de la livraison continue prendra de l'ampleur. Votre portefeuille de services s'étend vraisemblablement à plusieurs technologies, plates-formes, différents départements, clients internes et externes, différentes équipes de développement, de support, etc.
Si chaque application définit son propre pipeline spécifique, comment est-ce que cela affectera la gestion et la mesure sur votre implémentation de la livraison continue dans son ensemble ? Si les différents pipelines finissent à des points différents du processus de livraison, comment les métriques comme le Cycle Time, le débit ou le pourcentage d'exécutions réussies peuvent-elles être comparées ?
Un grand ensemble de pipelines est plus facile à gérer si chacun s'appuie sur un "template" standard. Les templates peuvent être aussi simples qu'une page Wiki partagée mais peuvent être aussi supportés par des orchestrateurs de pipelines courants comme Jenkins (Templates Plugin), Go (Pipeline Templates) et TFS(Build Process Templates). Les pipelines standardisés permettent des rapports comparatifs plus parlants mais aussi de pouvoir appliquer les enseignements tirés de l'un des pipelines à tous les autres, l'amélioration par feedbacks étant un composant clé de la livraison continue.
Le nombre de templates pour commencer dépend des différences au sein de votre portefeuille de services. Un par pile technologique est souvent un bon point de départ. Avec le temps, vous pouvez espérer être éventuellement à même de pouvoir consolider vers une poignée de pipelines types.
6. Propriété des Jobs et sécurité
Quand tout tourne sans problème, on peut facilement oublier que les pipelines de livraison automatisés s'étendent à beaucoup de parties de l'organisation IT, du développement à la production, en passant par les tests.
Cependant, quand des étapes du pipeline échouent, il est essentiel que des responsabilités claires aient été définies afin que les choses soient réparées et afin de remettre le flux de livraison en route. Chaque étape d'un pipeline devrait avoir un propriétaire, son spécialiste ou une personne ou une équipe responsable, en charge non seulement de réparer mais aussi de contribuer à l'amélioration du pipeline dans son ensemble, toujours en s'appuyant sur les feedbacks.
La visibilité sur l'état global du pipeline étant essentielle pour toutes les parties prenantes, pas seulement pour les propriétaires de chaque étape, il est important que les outils d'orchestration considérés offrent un modèle de sécurité adéquat. Par exemple, les développeurs auront probablement besoin d'examiner les résultats de la phase des tests fonctionnels afin d'aider à identifier les causes d'échec. Toutefois, ils ne devraient pas être à même de désactiver ou modifier la configuration de l'étape des tests fonctionnels.
L'histoire du pipeline orphelin
Un constructeur automobile décida de mettre en œuvre la livraison continue lors du planning d'un tout nouveau projet de développement d'une application mobile et de son backend, dont l'objectif était de permettre aux clients de personnaliser leur véhicule. Une poignée d'ingénieurs expérimentés sur le Build et la Release furent embauchés en tant que consultants pour l'installation des pipelines, le projet fut mené à bien avec succès et les consultants s'en allèrent. Fin du travail.
Pendant un temps, tout se déroula sans accroc. Jusqu'à ce que l'une des branches de la plate-forme mobile ne tombe soudainement. S'ensuivirent colères au téléphone, emails des responsables business et finalement une réparation d'urgence : l'étape en échec du pipeline fut simplement court-circuitée. L'application, à présent plus que partiellement testée, devint à nouveau disponible et l'étape manquante, rapidement oubliée.
Avec le temps, des urgences similaires conduisirent à désactiver ou réduire le périmètre de plus en plus de segments du pipeline. Des petites anomalies commencèrent à apparaitre dans l'application de plus en plus fréquemment. Sans responsable, les personnes à l'origine de la création du pipeline étant parties, la restauration du pipeline n'incombait à personne.
Une nouvelle arrivante dans l'équipe, issue d'une entreprise fortement empreinte de la culture de la livraison continue, souhaita améliorer la situation et pris en charge le pipeline, de façon informelle. En tant que développeur, elle n'avait pas les permissions de changer les étapes de QA du pipeline et se retourna donc vers l'équipe de QA ayant travaillé à l'origine avec l'équipe.
Deux ingénieurs QA furent particulièrement contents de voir le résultat de leur travail de l'époque remis en état de marche, bien que ne pouvant aider que sporadiquement à cause d'un backlog QA déjà bien occupé par d'autres projets.
Les corrections n'étaient pas extrêmement complexes en soi : l'archivage des résultats de tests sur un Wiki était cassé suite à un changement d'API, l'emplacement de publication automatique de la documentation avait été modifié, etc. Mais sans un projet officiel et un code d'imputation associé, les managers de la QA ne souhaitaient pas voir leur équipe occuper son temps sur ces tâches. Seul le recours à l'équipe produit et les efforts continus des membres de l'équipe de développement et de QA permirent finalement d'obtenir l'approbation pour un projet de maintenance.
Depuis, un projet de fond est continuellement dédié à la livraison continue dans l'entreprise.
Conclusion
Pilotés par la pression du business et des clients, les leaders du marché ont implémenté la livraison continue en tant que stratégie pour accélérer le time-to-market, chemin que de nombreuses autres sociétés cherchent à suivre. Bien qu'on trouve beaucoup de publications sur les principes et les processus de Continuous Delivery, les conseils pratiques sur le comment approcher et planifier une implémentation en environnement d'entreprise sont difficiles à trouver.
Une première étape préparatoire de votre implémentation devrait être une analyse des défis courants s'appliquant à votre situation. Apporter une réponse au plus tôt à tout challenge que vous identifierez aidera à progresser en douceur dans l'implémentation. L'expérience de la prise en charge de ces problèmes vous préparera également à répondre plus efficacement aux challenges à venir, au cours de l'implémentation.
En obtenant une bonne image de votre base de travail et en structurant votre implémentation en plusieurs phases mesurables, vous pourrez commencer préparer le terrain pour vos premiers pipelines, avec des rôles et responsabilités pour chaque phase.
Votre implémentation de la livraison continue sera sur le bon chemin, vers des Releases plus rapides, des livraisons de fonctionnalités plus fiables et une amélioration constante, pilotée par des feedbacks plus rapides et une meilleure vision.
Au sujet de l'auteur
Andrew Phillips est Responsable Produits pour XebiaLabs, fournisseurs de solutions d'automatisation pour la livraison d'applications. Andrew, expert du Cloud, du Service Delivery et de l'automatisation, a pris part à l'automatisation de plusieurs plates-formes de livraison applicative. Pendant son temps libre en tant que développeur, il a travaillé sur Multiverse, l'implémentation d'une STM en open-source, contribué à Apache jclouds et participe à la maintenance du site Scala Puzzlers.