Cet article est paru d'abord dans l'IEEE Software magazine. IEEE Software propose de l'information étayée, revue en comité sur les axes technologiques stratégiques actuels. Pour répondre aux challenges de direction d'entreprises flexibles et sûres, les managers et décideurs techniques IT doivent s'appuyer sur des professionnels du domaine pour des solutions en rapport avec l'état de l'art.
Le Déploiement Continu (DC) est une approche d'ingénierie logicielle dans laquelle les équipes livrent régulièrement des logiciels apportant de la valeur, et s'assurent qu'ils peuvent être livrés à tout moment. Le DC retient de plus en plus l'attention de la communauté, qui en reconnaît la valeur.
Les défenseurs du DC soutiennent que ces pratiques permettent aux entreprises d'apporter rapidement, efficacement et en toute sécurité des améliorations de service, et même de devancer les compétiteurs.1 Cela semble merveilleux. Cependant, l'implémentation du DC peut être délicate - en particulier dans un contexte de grande organisation avec un environnement historique de développement/livraison.
J'expliquerai ici le chemin d'adoption du DC à Paddy Power, une grande société de paris (bookmaking). Je décrirai les possibilités offertes avec le DC et expliquerai les énormes bénéfices et challenges conséquents. Ces expériences peuvent apporter à mes collègues praticiens des éléments de compréhension dans leur adoption du DC, et les challenges identifiés peuvent permettre aux chercheurs de disposer d'un apport précieux pour développer leurs agendas de recherche.
Le Contexte
Paddy Power est une entreprise à forte croissance, avec un chiffre d'affaires d'environ 6 milliards d'euros et 4 000 employés. Elle propose des services sur les marchés régulés de paris, que ce soit en boutique, par téléphone ou sur internet.
L'entreprise s'appuie fortement sur un nombre croissant d'applications maison. Elles incluent des sites web, des applications mobiles, des systèmes de transactions et de pricing, de distribution de paris simultanés, et des logiciels de paris dans les boutiques. Nous développons ces applications sur plusieurs couches techniques, avec du Java, Ruby, PHP et du .Net. Pour le fonctionnement de ces applications, l'entreprise dispose d'une infrastructure IT de milliers de serveurs sur plusieurs localisations.
Ces applications sont développées et maintenues par la DSI, qui emploie environ 400 personnes. La taille des équipes de développement dépend de la taille et de la complexité des applications. Nos équipes peuvent varier de 2 à 26 personnes ; la majorité d'elles étant de 4 à 8 personnes. Les cycles de livraison varient également. Précédemment, chaque application était livrée moins de six fois par an. Pour chaque version, nous rassemblions les besoins au début du cycle. Les développeurs travaillaient dessus pendant des mois. A la fin du cycle, nous avions besoin d'une bonne dose de tests et de corrections. C'est alors que les développeurs passaient la main aux équipes de déploiement pour la mise en production. Le déploiement impliquait beaucoup de tâches manuelles.
Ce modèle de gestion de version retardait artificiellement le déploiement de fonctionnalités finies très tôt durant le cycle. La valeur potentiellement générée était perdue, et des retours précoces sur les fonctionnalités non disponibles.
Beaucoup de livraisons étaient des expériences "terrifiantes" car le processus était peu pratiqué et il y avait beaucoup d'activités manuelles propices aux erreurs. Les incidents critiques dus à des erreurs de configuration manuelle étaient réguliers. De plus, les livraisons n'étaient pas efficaces. La simple mise à disposition d'environnement de tests pouvait prendre jusqu'à trois semaines.
Pour améliorer la situation, Paddy Power débuta une initiative de mise en oeuvre de DC. L'entreprise installa une équipe dédiée de 8 personnes, qui avait travaillé sur le sujet depuis plus de deux ans.
La Chaîne de Production de Déploiement Continu
Puisque nous devions nous occuper de beaucoup d'applications variées, nous avons construit une plateforme permettant de créer une chaîne de production (pipeline) de déploiement continu pour chacune d'entre elles. Notre équipe s'occupe de cette plateforme et la maintient. Quand l'équipe de développement d'une application a besoin d'un nouveau pipeline, nous lui en créons un.
Les pipelines des différentes applications peuvent grandement varier, aussi bien en termes de nombre que de type d'états, pour coller au mieux aux besoins. L'image qui suit montre un exemple de pipeline.
Illustration 1. Un exemple de chaîne de production (pipeline) de déploiement continu (DC). L'avancement dans l'exécution du pipeline d'une étape à la suivante peut être automatique ou manuel. La confiance dans la réactivité de l'outil de construction croît à mesure que les étapes s'enchaînent.
Le Commit de Code
L'étape de commit de code fournit un retour initial immédiat aux développeurs sur le code soumis. Cette étape démarre automatiquement dès qu'un développeur soumet du code au repository du logiciel de gestion de configuration. Il compile le code source et exécute les tests unitaires. Quand il y a une erreur lors de cette étape, le pipeline s'arrête et informe le développeur. Il modifie son code, le fait vérifier par un tiers et le renvoie. Cela réenclenche l'étape de commit et relance l'exécution de la chaîne. Si tout va bien, le pipeline l'envoie vers l'étape suivante.
Construction (Build)
La phase de construction (build) exécute les tests unitaires à nouveau pour produire un rapport de couverture de code, réalise les tests d'intégration et diverses analyses statiques de code, puis construit les éléments de la version. Il monte les éléments sur le repository qui gère le déploiement ou la distribution. Tous les pipelines ultérieurs travailleront à partir de cet ensemble d'éléments. Avant de passer en Déploiement Continu, les binaires poussés en production pouvaient différer de ceux testés. Cela venait d'une construction manuelle du binaire, à chaque étape. Chaque fois que nous le consolidions, nous introduisions un risque de différences. Nous avons vu les bugs que cela impliquait. Il était frustrant de les résoudre car le logiciel marchait pour les développeurs et testeurs, mais pas en production. Le pipeline de DC les a tous éliminés. Si quelque chose ne va pas, le pipeline s'arrête et informe les développeurs. Autrement, il pousse automatiquement à l'étape suivante.
Tests d'Acceptation
La phase de tests d'acceptation garantit surtout que le logiciel correspond aux exigences spécifiées. Le pipeline crée l'environnement pour les tests d'acceptation, similaire à celui de la production avec le déploiement du logiciel. Cela implique l'approvisionnement de serveurs, leur configuration (par exemple sur les aspects réseau et sécurité), le déploiement et la configuration du logiciel. La chaîne de production réalise alors l'ensemble des tests d'acceptation sur cet environnement.
Précédemment, l'installation de l'environnement était manuelle, ce qui pouvait prendre jusqu'à deux semaines aux développeurs pour nos applications complexes. Même pour des applications plus petites, il fallait compter une demi-journée.
Pour les projets nouveaux, l'installation était encore plus longue. Les développeurs devaient demander à l'équipe d'infrastructure de nouvelles machines, à l'équipe Windows ou Unix de les configurer, aux ingénieurs réseau d'ouvrir les connexions entre les machines, etc. Cela pouvait prendre un mois.
Les développeurs n'ont plus besoin de faire tout cela avec le pipeline DC. C'est lui qui installe automatiquement l'environnement en quelques minutes.
De même que pour les autres étapes, si des erreurs surviennent, le pipeline s'arrête et notifie les développeurs. Autrement, il pousse à l'étape suivante.
Tests de Performance
La phase de tests de performance mesure l'impact des changements de code sur la performance. Le pipeline installe l'environnement de tests de performance, lance l'ensemble des tests et envoie les résultats à l'outil centralisant l'information sur la qualité des logiciels.
Précédemment, étant donné l'effort considérable requis pour installer un environnement de tests de performance, ceux-ci ne se faisaient pas durant le développement. Nous ne les faisions qu'avant les versions majeures. Avec le pipeline, les tests de performance se font à chaque envoi de code qui a passé les étapes précédentes. Les développeurs savent immédiatement si les changements ont dégradé la performance. Diagnostiquer et régler les problèmes à ce moment est bien moins cher que de le faire pour une version majeure.
Tests Manuels
Bien que nos tests automatisés soient plutôt fiables, il faut parfois tester manuellement (par exemple, quand les testeurs font du test exploratoire et que les utilisateurs réalisent les tests d'acceptation).2
Précédemment, les testeurs devaient installer un environnement de tests, ce qui leur donnait la migraine. Ces étapes étaient souvent manuelles et sources d'erreurs.
Avec le Déploiement Continu, il n'y a plus d'inquiétude. La chaîne de mise en production installe seule les environnements de tests et envoie par mail aux testeurs toutes les informations pour se connecter à l'application déployée.
Quand les tests sont finis, l'ensemble des éléments passe de "release candidate potentielle" à "release candidate". A ce moment, le logiciel a subi tous les tests qualité et est prêt à passer en production. Il faut juste un clic pour passer du "déploiement en production" à la production. Avant, le déploiement ratait souvent du fait d'erreurs dans le processus et les scripts de déploiement. Le DC n'a pas d'étapes de déploiement manuel et le processus et les scripts ont été testés plusieurs fois dans les étapes précédentes.
Bénéfices
Jusqu'ici, nous avons passé 20 applications en Déploiement Continu. Elles sont développées par l'un des groupes de développement les plus importants. Leurs utilisateurs principaux sont des gens du métier de l'entreprise. Toutes les équipes de développement ont utilisé une approche appelée Kanban pour passer en DC. 3
Sur ces applications, le DC a engendré les six bénéfices suivants.
Illustration 2. Avantages du Déploiement Continu. Motivée par ces bénéfices, l'entreprise a augmenté l'investissement en DC.
Time To Market plus Rapide
La fréquence des versions a radicalement augmenté. Avant, il n'y avait qu'une version tous les un à six mois. Maintenant, il y a en moyenne une version par semaine. Quelques-unes sont livrées plusieurs fois par jour si besoin.
Le temps de cycle d'une user story, de sa conception à sa mise en production, est passé de plusieurs mois à quelques jours.
Le DC permet de livrer beaucoup plus vite la valeur business de chaque nouvelle version du logiciel à nos clients. Cette capacité permet à l'entreprise de garder une longueur d'avance sur la concurrence, dans l'environnement économique actuel.
Construire le Bon Produit
Les versions fréquentes permettent aux équipes de développement un retour utilisateur plus rapide. Ceci leur permet de ne travailler que sur les fonctionnalités utiles. Si elles en voient des inutiles, elles ne se fatiguent plus dessus. Ceci aide à construire le bon produit. Jusque là, les équipes travaillaient sur des fonctionnalités inutiles mais ne le découvraient qu'après une version majeure. A ce moment, elles avaient déjà gaspillé des mois dessus.
Amélioration de la Productivité et de l'Efficacité
La productivité et l'efficacité se sont aussi fortement améliorées. Par exemple, les développeurs passaient 20% de leur temps à installer et réparer leurs environnements de tests. Maintenant, le chaîne de mise en production le fait toute seule. De même pour les testeurs qui consacraient également beaucoup de temps et d'efforts à mettre en place leurs environnements de tests. Maintenant, ils n'ont plus besoin de le faire.
Les ingénieurs d'exploitation avaient besoin de quelques jours pour déployer l'application en production. Maintenant, ils ont seulement besoin d'appuyer sur un bouton ; le pipeline installe automatiquement l'application en production.
De plus, les développeurs et spécialistes de la production passaient beaucoup de temps à corriger et régler des problèmes causés par les anciennes pratiques de déploiement. Le pipeline de DC a éliminé ces difficultés. L'effort dépensé à les faire disparaître peut être utilisé pour des activités plus utiles.
Versions Fiabilisées
Les risques associés au lancement d'une version ont significativement diminué, et le processus de livraison est devenu plus fiable.
Comme mentionné plus haut, avec le DC, le processus et les scripts de déploiement sont testés plusieurs fois avant le déploiement en production. Donc, la majeure partie des erreurs ont déjà été levées.
Avec des versions plus fréquentes, le volume de changement de code de chacune décroît. Ceci rend la recherche et la résolution des problèmes plus faciles, réduisant la durée d'impact.
De plus, le pipeline peut automatiquement revenir à la version précédente en cas d'échec. Ceci réduit d'autant le risque d'échec de version.
Comparé à avant, les ingénieurs disent ressentir un niveau de stress moindre le jour du lancement. Les jours de livraison deviennent juste des jours comme les autres.
Amélioration de la Qualité Produit
La qualité du produit a considérablement augmenté. Le nombre de bugs ouverts pour les applications a chuté de plus de 90%.
Avec le Déploiement Continu, juste après le commit de code, toute la base de code passe par des séries de tests. S'ils remontent un problème, les développeurs les règlent avant de passer à une autre tâche. Ceci en élimine beaucoup, qui autrement auraient dû être ouverts dans le système de suivi d'anomalies. Précédemment, le système de gestion de bugs enregistrait beaucoup d'anomalies ouvertes. Environ 30% de l'effort se tournait vers la résolution des bugs. Maintenant, le plus souvent, il n'y a personne travaillant sur des bugs trouvés par les clients. Les bugs sont si rares que les équipes n'ont plus besoin d'outil de suivi d'anomalies.
Dans les rares cas où un bug est trouvé en production, il est ajouté au tableau Kanban de l'équipe et est réglé en quelques jours. Avant, les clients devaient attendre la version suivante pour leur résolution. Cela se comptait plutôt en mois.
De plus, les incidents de priorité 1 en production ont clairement diminué. Outre les raisons listées ci-dessus, ceci est dû au fait que le pipeline de DC a éliminé les erreurs qui peuvent provenir de configurations manuelles et d'autres pratiques propices à celles-ci.
Amélioration de la Satisfaction Client
Avant de passer au DC, méfiance et tensions existaient entre le département utilisateurs et les équipes de développement en raison de problèmes de qualité et de release. Les managers soulignent que les relations se sont nettement améliorées. La confiance s'est rétablie.
Challenges
Motivée par ces énormes avantages, l'entreprise a augmenté ses investissements en Déploiement Continu. L'extension du DC à toute l'entreprise et l'amélioration de la plateforme sont les priorités principales. Néanmoins, l'implémentation du DC implique des défis considérables.
Challenges Organisationnels
Les défis les plus importants ont été organisationnels. Les activités de mise en production impliquent plusieurs divisions de l'entreprise. Chacune a ses propres intérêts, sa manière de travailler et sa perception sur son périmètre de contrôle. Des tensions existaient entre les divisions du fait d'objectifs divergents. Par exemple, il nous fallait des accès "root" sur les serveurs, dont les droits étaient contrôlés par une autre équipe. Il nous a fallu plus de six mois de concertations et de négociations afin d'aboutir à une solution.
Pour gérer les enjeux organisationnels, l'équipe dirigeante mit à plat l'organisation afin de briser les silos entre les équipes et promouvoir une culture de collaboration. La situation s'est améliorée depuis.
Bien qu'il existe une littérature sur le changement organisationnel4, peu, si ce n'est aucune, se concentre sur l'introduction du Déploiement Continu dans les organisations. Davantage de recherches sur ce sujet - par exemple, une compréhension approfondie des challenges, et des stratégies ou pratiques à développer pour les gérer correctement - aiderait clairement à une adoption plus fluide du DC.
Challenges sur les Processus.
Beaucoup de processus traditionnels gênent le DC. Par exemple, une fonctionnalité prête au déploiement doit normalement passer par une commission de changement. Cela peut retarder la livraison jusqu'à 4 jours. S'il faut uniquement quelques jours entre la conception et le moment où une fonctionnalité est prête au déploiement, cette période est beaucoup trop longue dans son temps de cycle total.
Il faut plus de recherches afin d'identifier ces processus (couvrant les aspects business, développement, exploitation, etc) et de développer et vérifier des alternatives opérationnelles pour le Déploiement Continu.
Challenges Techniques
Il n'existe pas encore de solution robuste, sur étagère, exhaustive et aussi fortement paramétrable, de DC. Donc, nous avons développé la nôtre, ce qui fut coûteux. Des outils comblant cette lacune feraient économiser beaucoup de ressources aux entreprises.
En construisant notre plateforme, nous avons utilisé beaucoup d'outils et de technologies différents comme blocs de construction. Eviter le verrouillage des fournisseurs est un défi. Travailler sur des standards largement acceptés, définir des APIs ouvertes et construire un écosystème de plugins actifs permet de réduire ces difficultés.
Gérer des applications non compatibles avec le DC (par exemple, des grosses et monolithiques) est également un challenge. Il en existe un grand nombre dans le monde du SI. Il faut des recherches pour comprendre leurs caractéristiques et afin d'identifier et développer les meilleures stratégies et pratiques pour s'en occuper.
Nous aimerions résoudre les challenges décrits au travers d'une collaboration étroite avec des chercheurs et des entreprises, pour que plus d'organisations puissent disposer des avantages du DC.
Je remercie mes collègues, Klaas-Jan Stol, les relecteurs de cet article et les éditeurs pour leur aide et leurs commentaires éclairés. Cet article ne représente que mon point de vue et ne correspond pas forcément à celui de mon employeur.
Références
- J. Humble and D. Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley Professional, 2010.
- C. Kaner, J. Falk, and H.Q. Nguyen, Testing Computer Software, 2nd ed., John Wiley & Sons, 1999.
- D.J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010.
- R. Todnem By, “Organisational Change Management: A Critical Review,” J. Change Management, vol. 5, no. 4, 2005, pp. 369–380.
- A. Rob, Effective IT Service Management: To ITIL and Beyond!, Springer, 2007.
Au Sujet de l'Auteur
Lianping Chen est un ingénieur développement senior chez Paddy Power et un doctorant à temps partiel à Lero - le Centre de Recherche Irlandais d'Ingénierie Logicielle de l'Université de Limerick. Ses centres d'intérêt incluent les besoins et l'architecture logiciels, le déploiement continu, DevOps et les lignes de produits logiciels. Il possède un MS en ingénierie logiciel de l'Université Polytechnique de Northwestern. Pour le contacter lchen@paddypower.com.