Établir un rythme de changement convivial sans compromettre les pratiques DevOps – L’histoire d’AlayaCare 

Author: Jean-Philippe Boudreault, Directeur du Développement Logiciel, AlayaCare

Cet article raconte le parcours d’AlayaCare et démontre qu’il est possible de ralentir le rythme des déploiements sans compromettre les pratiques DevOps. Bien que chaque situation soit unique, nous espérons que d’autres entreprises pourront s’identifier aux défis rencontrés par AlayaCare et appliquer les principes généraux présentés dans cet article. 

L’internet ne manque pas d’études de cas mettant en évidence les avantages de la rétroaction rapide et de l’innovation continue pour les entreprises logicielles. Depuis près d’une décennie, le rapport annuel State of DevOps souligne la valeur de pratiques telles que le CI et le CD. 

La transition vers le déploiement continu est tumultueuse 

De nombreuses équipes font face à des frustrations à la fois chez les dirigeants et les clients lorsqu’elles passent au déploiement continu. Ce défi survient souvent lors de la transition d’une architecture monolithique à une architecture à microservices. Le monolithe bénéficie généralement d’un calendrier de déploiement bien établi, complété par un ensemble complet de tests automatisés et manuels. Toutefois, lorsque les équipes commencent à livrer des services de façon indépendante, même quelques erreurs peuvent attirer l’attention et exercer des pressions pour revenir aux anciennes méthodes de déploiement. Malheureusement, cette situation mène souvent à une complexité accrue et résulte en un monolithe distribué. 

La croissance d’AlayaCare a été substantielle, et son monolithe a bien servi l’entreprise pendant plusieurs années. Cependant, au fil du temps, il est devenu évident que les équipes ne pouvaient pas faire évoluer le monolithe suffisamment rapidement pour répondre aux besoins de l’entreprise. Les changements avaient des impacts imprévisibles, la mise à jour des dépendances était une tâche ardue, et il était presque impossible de corriger les goulots d’étranglement en termes de performance. Donner aux fournisseurs de soins les outils technologiques nécessaires pour améliorer leurs services en santé était devenu inatteignable sans un changement d’architecture. 

Les tests de régression du monolithe sont une illusion de securité 

Au début de 2023, le monolithe d’AlayaCare était déployé chaque semaine. Un lancement de fonctionnalités majeures avait lieu toutes les quatre semaines, entrecoupé de correctifs hebdomadaires. Les clients avaient accès à ces versions majeures une semaine à l’avance sur les environnements de pré-production, accompagnées de la documentation correspondante. Malgré des calendriers de déploiement réguliers, les équipes continuaient d’effectuer des correctifs à chaud pour répondre à des besoins clients, corriger des bogues urgents, et ce parfois à chaque jour. Les tests de régression étaient un processus long principalement axé sur les déploiements majeurs du monolithe.  

À la mi-année, environ dix équipes déployaient leurs microservices de façon autonome, et l’équipe de documentation produit avait du mal à maintenir les notes de version à jour. Sans surprise, le calendrier mensuel de lancement ne pouvait pas suivre les déploiements constants des multiples composants de la plateforme AlayaCare. Malgré les longs tests de régression effectués chaque mois, on pouvait se demander quelles garanties ils fournissaient aux équipes déployant leurs microservices en dehors du calendrier du monolithe. 

Les clients étaient insatisfaits de la qualité de la plateforme et trouvaient difficile d’assimiler les changements assez rapidement pour former leur personnel. En interne, les équipes étaient de plus en plus frustrées par la coordination nécessaire pour mettre à jour le monolithe. L’ajout et la modification de tables de base de données devaient être échelonnés sur plusieurs déploiements, et les tâches de maintenance telles que la suppression de balises de code obsolètes étaient difficiles. Les déploiements mensuels avaient atteint le point critique et nous avions une pression accrue pour ralentir le rythme.

Rythme de changement lent ou innovation rapide? 

Avions-nous atteint un point de rupture? Aucune entreprise logicielle peut innover et déployer son produit lentement. Est-ce que les besoins des affaires et de l’ingénierie étaient opposés? 

Ces besoins ne sont pas incompatibles si l’on sépare les concepts de déploiement et d’activation. Le terme « déploiement en douceur », introduit par le Silicon Valley Product Group, a trouvé un écho chez AlayaCare et a été adopté dans l’organisation. 

L’accord obtenu est le suivant: les équipes peuvent déployer du code à tout moment tant que cela a peu d’impact pour les clients. 

Cette approche permet aux équipes de déployer des éléments relatifs à des événements clients à tout moment, à condition que les changements ne soient pas activés. En fait, toutes les activations sont regroupées dans un événement mensuel qui peut être prévisualisé sur un environement spécifique. Un groupe de discussion, composé de représentants des équipes produit, ingénierie et relation client, a été chargé de déterminer quels changements constituaient des événements clients et lesquels ne l’étaient pas. 

Définition standardisée des événements clients 

Chez AlayaCare, nous regroupons l’activation des changements. Les nouvelles versions des applications iOS, Android, web et du portail familial sont déployées à différents moments, mais l’activation de nouvelles fonctionnalités se produit simultanément. 

Chaque contexte d’entreprise est unique, il n’existe donc pas d’approche universelle. L’important est d’établir des politiques claires autour des capacités de versionnage des technologies utilisées. 

Les non-événements n’exemptent pas les équipes de leurs responsabilités de qualité et de suivi des changements en production. En fait, les équipes activent souvent des non-événements en utilisant des balises d’activation individuels. 

Il est crucial de pouvoir d’innover et d’itérer rapidement en fonction de la rétroaction client. C’est la principale raison pour laquelle les modifications des flux personnalisés et des fonctionnalités en accès anticipé sont considérées comme des non-événements. Les meilleures pratiques dictent que les chefs de produit collaborent avec le marketing produit et les équipes en contact avec les clients pour gérer les changements destinés aux premiers adopteurs et aux flux personnalisés, en travaillant directement avec les clients impactés. 

Gérer les commutateurs de fonctionnalité avec LaunchDarkly

Un bon système de gestion de commutateurs de fonctionnalité aide grandement les équipes à effectuer des déploiements fluides. Bien qu’AlayaCare ait adopté LaunchDarkly à la fin de 2019, ce n’est que récemment que nous avons commencé à exploiter ses prérequis et ses flux de travail pour gérer les événements de release avec une activation échelonnée. 

À haut niveau, tous les commutateurs de fonctionnalité des événements clients sont liés à un même commutateur parent. Nous appelons ces commutateurs parents des «monthly release flags». Ils sont associés à un flux de travail spécifique qui les active dans les environnements de prévisualisation client durant la première semaine du mois et échelonne l’activation à travers nos régions clients la semaine suivante. Parce que les commutateurs parents agissent comme prérequis, les flags d’événements clients sont préparés en avance. 

Les équipes gèrent leurs commutateurs de fonctionnalité de manière autonome pour les non-événements et utilisent des segments préconfigurés de LaunchDarkly pour tester en production et réduire l‘impact client si un changement ne fonctionne pas comme prévu.

Le mieux est l’ennemi du bien

Les pratiques de déploiement progressif ne sont pas destinées à être immuables, et à mesure qu’une entreprise mûrit, des changements sont attendus. Chez AlayaCare, nous nous sommes engagés dans un parcours d’amélioration continue et avons établi un panel de révision mensuel avec les équipes en contact avec les clients pour réfléchir sur chaque mois. Nous n’avons pas attendu pour développer des outils complexes autour de la gestion des flags ou de la documentation automatisée des notes de version. 

Cette décision s’est avérée judicieuse, car nous avons rapidement constaté des améliorations dans la qualité des versions et acquis des connaissances sur les outils qui auraient le plus d’impact pour nos équipes et nos clients. Par exemple, nous avons réalisé la nécessité de donner aux équipes davantage de responsabilité sur leur documentation produit et de rationaliser la gestion des flags. Pour nos clients, nous avons reconnu l’importance d’intégrer la documentation des versions au sein de l’application et d’offrir plus de temps de test en UAT. Il n’est pas irréaliste d’envisager qu’AlayaCare adopte un modèle de release plus flexible dans les années à venir. 

Notre mission est de permettre aux personnes de recevoir les soins que nous souhaitons pour nos proches, dans l’endroit qu’elles appellent chez elles. Cela ne peut être réalisé que par un équilibre entre l’innovation et un rythme de changement adapté aux fournisseurs de soins.