Le parcours de Driftrock vers la livraison continue

Au cours de l'année écoulée, Driftrock a suivi un parcours assez classique – vous en avez peut-être déjà entendu parler – : nous sommes passés de déploiements manuels et d'une certaine réticence à mettre en production des logiciels à des déploiements automatisés et reproductibles, en mettant l'accent sur la création de valeur.

Plutôt que de vous ennuyer avec un énième article sur les avantages de la livraison continue – même si j’en ai bien envie –, je vais plutôt essayer de me concentrer sur la manière dont nous avons opéré cette transition. Inspiré par le livre *More Fearless Change* de Mary Lynn Manns et Linda Rising, je vais faire de mon mieux pour retracer les étapes que nous avons suivies et, plus précisément, les modèles que nous continuons d’utiliser pour tenter de faire évoluer les comportements de l’équipe.

Remonter le temps

Pour commencer, un peu de contexte : en juin 2016, toute modification apportée à l'une de nos applications finissait par se retrouver en production. Il était très difficile de savoir si une modification avait bien été déployée ; nous utilisions un modèle de branchement extrêmement répandu mais frustrant, qui alourdissait considérablement la charge cognitive, et les déploiements étaient déclenchés manuellement depuis l'ordinateur d'un développeur via l'interface de ligne de commande (CLI) de Heroku.

Voici à quoi ressemblait un nouveau passage de l'environnement de développement à l'environnement de production :

Vert - étape automatisée.
Orange - étape manuelle inévitable ou étape manuelle que nous n'envisageons pas (encore) de modifier.
Rouge - étape manuelle évitable.

Ce processus de déploiement présentait également un certain nombre d'incohérences selon les applications. Certaines ne disposaient pas d'environnement de préproduction ; celles qui en avaient un pouvaient ou non être déployées automatiquement sur ce dernier, et toutes les applications ne faisaient pas l'objet de tests automatisés sur la branche principale ou sur d'autres branches. En résumé, le processus était inutilement complexe, extrêmement incohérent et ne comportait que très peu, voire aucune automatisation. Il n'est donc pas surprenant que l'équipe ait manqué d'enthousiasme à l'idée de déployer des logiciels.

Tout cela rendait les déploiements irréguliers et risqués. Le plus souvent, un grand nombre de modifications était mis en production d'un seul coup, ce qui augmentait inévitablement le risque de défaillance et empêchait parfois de revenir en arrière en toute sécurité.

Petit à petit

Je vais essayer d'expliquer les mesures que nous avons prises et les modèles pertinents que nous avons utilisés pour améliorer le scénario décrit ci-dessus. Tout en bas de cette page, vous trouverez une liste des modèles mentionnés tout au long de ces étapes. Vous pouvez également consulter ici la liste complète de ces modèles , accompagnée de leurs descriptions.

Étape 1 - Impliquer tout le monde

Contre toute attente, tout a commencé par l'amélioration de nos rétrospectives. L'équipe avait besoin d'un espace pour discuter des problèmes et proposer des améliorations (Impliquer tout le monde). Même si nous avions une réunion hebdomadaire appelée « rétrospective », celle-ci n'avait que peu de points communs avec les rétrospectives que j'avais observées dans plusieurs autres entreprises. À l'origine, cette réunion s'apparentait davantage à un point hebdomadaire sur l'avancement des tâches : elle se concentrait sur les tâches quotidiennes et leur progression plutôt que sur la manière dont nous pouvions améliorer notre façon de travailler. Le fait de proposer puis de mettre en pratique une approche plus structurée des rétrospectives (en animant les premières) a eu un impact significatif sur l’équipe, bien au-delà de la livraison continue ; mais l’un des premiers points de discussion portait sur la manière dont nous déployons nos logiciels (Semez les graines).

Étape 2 - Lancez-vous !

L'équipe étant quelque peu perplexe quant aux avantages que pourrait lui apporter le passage à la livraison continue, la prochaine étape était simple : leur montrer un exemple (Just Do It). J'ai mis au point une application API HTTP simple comportant un seul point de terminaison qui renvoyait « 200 OK », puis j'ai créé un pipeline de déploiement dans Snap CI. J'ai essayé de reproduire la manière dont nous traitons nos applications habituelles et je me suis concentré uniquement sur les problèmes les plus urgents (Pick Your Battles) : les déploiements manuels et la gestion de plusieurs branches lors du déploiement. Ce dernier point permettait également de réduire l'écart entre le développement local et la production. Cela démontrait que notre processus de déploiement pouvait commencer à évoluer vers ceci :

Comme on pouvait s'y attendre (à l'instar d'un logiciel fonctionnel), cela s'est avéré être un excellent outil de référence pour présenter et expliquer l'intérêt du CD, ainsi que pour le comparer à nos anciennes méthodes.

Étape 3 - Essai

Une fois cette idée semée, grâce à un exemple concret et aux problèmes récurrents rencontrés lors de la livraison de logiciels de qualité (qui ne faisaient que souligner la gravité de la situation – un véritable signal d’alarme), l’adhésion du reste de l’équipe n’a cessé de croître. L’étape suivante consistait à engager l’équipe à migrer une ou deux applications réelles vers le nouveau système (phase d’essai). Nous avons sélectionné deux applications problématiques pour valider nos hypothèses le plus tôt possible, créé des pipelines de déploiement pour celles-ci, réussi à les déployer et laissé ce changement s’installer. À ce stade, j’ai heureusement pu compter sur de l’aide (Demander de l’aide), ce qui a permis d’accélérer considérablement les progrès et de mieux gérer les éventuelles réactions négatives.

Étape 4 - Relations publiques continues

Tout au long de ce processus, un thème abordé dans le livre m'a particulièrement marqué : le « Persistent PR ». En y réfléchissant bien, ce concept est apparu de manière subtile à plusieurs reprises, parfois de manière intentionnelle, mais souvent sans que je m'en rende compte. Voici un aperçu des endroits où il est apparu :

• Nous avons modifié notre réunion debout habituelle afin qu’elle se concentre d’abord sur ce qui a été déployé en production, puis sur l’environnement de préproduction et enfin sur le développement en cours — une méthode généralement appelée « Walk the Board ». Bien qu’indirect, ce processus rappelle régulièrement à l’équipe qu’il faut avant tout se concentrer sur la livraison du logiciel et sur la manière de faire passer les tâches en production.
• Lors d'une réunion hebdomadaire de l'entreprise, nous avons brièvement présenté la manière dont nous avons modifié notre approche du déploiement des logiciels. Cela s'est d'ailleurs produit par hasard, mais c'était une occasion à ne pas manquer (Smell of Success).
• Nous avons commencé à collecter et à communiquer des indicateurs relatifs au nombre de déploiements en production.
• Nous avons mis en place quelques boucles de rétroaction afin de faciliter la circulation de l'information concernant les déploiements :
• Notifications Slack : transmission d'informations concernant les échecs de compilation ou les déploiements réussis. Ainsi, les développeurs n'avaient plus besoin de rechercher le statut de leur modification, celui-ci leur était directement communiqué.
• Notes de mise à jour : nous avons commencé à communiquer en interne les changements destinés aux clients au fur et à mesure de leur déploiement. Cela a permis de susciter l'intérêt et de susciter des discussions autour des nouvelles fonctionnalités parmi l'ensemble du personnel de l'entreprise.
• Surveillance : c'est un domaine que nous n'avons pas encore tout à fait maîtrisé, mais nous continuons à tester différentes méthodes de surveillance et à rechercher de meilleurs moyens de recueillir des informations sur nos systèmes de production.

Alors, où en sommes-nous ?

Nous effectuons actuellement environ 15 déploiements en production par semaine, ce qui constitue un rythme soutenu mais viable pour une équipe de notre taille. Nous avons fini par migrer une trentaine de projets vers Snap CI. Nous avons mis en place des pipelines de livraison continue pour divers types d’applications : gemmes Ruby, paquets Elixir, sites statiques hébergés sur AWS, applications web sur Heroku et autres hébergées sur Kubernetes. Chaque membre de l'équipe s'assure que les modifications sur lesquelles il travaille sont déployées en production et collabore étroitement avec les autres membres de l'équipe pour tester les fonctionnalités concernées. Nous nous appuyons de plus en plus sur les tests automatisés, les commutateurs de fonctionnalités et la rétrocompatibilité — des sujets qui ont occupé une place importante dans nos rétrospectives.

Soit dit en passant, Snap CI n’a pas vraiment répondu à nos attentes, mais cette expérience a tout de même eu quelques retombées positives. Après avoir rencontré plusieurs problèmes, nous avons commencé à miser sur Docker pour l’intégration continue (CI) afin d’isoler et de prendre le contrôle de l’environnement de compilation. Cela a eu de nombreuses répercussions, comme l’utilisation de Docker en développement et la transition vers Kubernetes. Cela a également réduit notre dépendance vis-à-vis de notre outil CI/CD, ce qui s’est rapidement avéré crucial lorsque Snap CI a annoncé sa fermeture. Heureusement, nous sommes désormais bien mieux placés pour comprendre nos besoins, et nous sommes donc en train de migrer vers Buildkite(ce sera l'objet d'un autre article !).

J'espère que cela vous donne un aperçu de la manière dont nous poursuivons notre transition vers la livraison continue et des modèles qui nous ont aidés. Notre approche continue d’évoluer à mesure que nous apprenons, et nous reconnaissons qu’il nous reste encore du chemin à parcourir. Résumer tous ces efforts en quatre étapes est certes une simplification excessive ; il a fallu de nombreux mois, même à notre petite équipe, pour en arriver là où nous en sommes aujourd’hui. Ce parcours nous a rappelé qu’un changement comme celui-ci ne se fait pas du jour au lendemain et qu’il nécessite de nombreuses petites étapes, souvent insignifiantes, dans la bonne direction.

Autres ressources utiles

Linda Rising - Mythes et schémas du changement organisationnel
Livraison continue - Jez Humble & Dave Farley
Livraison continue - De la misère à la richesse - Hibri Marzook
Développement basé sur le tronc

Référence sur les modèles de changement

En reprenant librement le livre, voici une sélection des modèles que j'ai mentionnés plus haut :

Petits pas - Avancez pas à pas vers votre objectif.
Impliquez tout le monde - Chacun doit avoir la possibilité d'apporter sa propre contribution.
Semez les graines - Saisissez toutes les occasions qui se présentent pour susciter l'intérêt pour une idée.
Lancez-vous - N'attendez pas le moment idéal, faites plutôt ce premier petit pas et commencez à apprendre.
Choisissez vos combats - Concentrez vos efforts sur les problèmes les plus urgents.
Faites un essai - Lorsqu’il y a une réticence à s’engager dans une idée, proposez une expérience sur une courte période.
Signez l’alerte - Mettez en avant les problèmes qui rendent le changement nécessaire.
Demandez de l'aide - Recherchez des personnes et des ressources pour soutenir vos efforts et encourager la participation.
Communication persistante - Gardez la nouvelle idée sous les yeux de tous, faites-en la promotion de manière constante et variée.
L'odeur du succès - Lorsque vos efforts produisent un résultat positif visible, considérez cela comme une occasion d'apprendre.

‍