Le développement de logiciels en 2020 est un environnement qui évolue rapidement. Il devient plus clair de jour en jour que si nos organisations veulent survivre à cette période d’incertitude politique et économique, elles doivent être capables d’évoluer avec rapidité et adaptabilité. Mais comment contrôler la sécurité à la vitesse ? Si votre objectif est de passer d’un cycle de livraison de logiciels qui a été construit avec beaucoup de garde-fous et des déploiements peu fréquents, à une méthodologie plus moderne qui soutient la réactivité via des versions fréquentes pour faire circuler la valeur à vos clients aussi rapidement et sûrement que possible, alors qui vous mettez en charge des décisions de gestion du changement importe, beaucoup.

Traditionnellement, dans de nombreuses organisations, ces décisions sont prises de manière centralisée par un gestionnaire de changement qui conduit des réunions périodiques du conseil consultatif du changement (CAB). Le CAB lui-même est une collection de représentants de diverses fonctions à l’intérieur et à l’extérieur de l’informatique d’entreprise, chargés d’examiner les changements proposés et d’aider le gestionnaire de changement dans l’évaluation, la priorisation et la programmation des changements. Par conception, il s’agit d’un groupe qui n’est pas directement impliqué dans la conception ou la mise en œuvre du changement proposé, ce qui explique pourquoi le processus qu’il mène est connu sous le nom d’examen  » externe « .

Mais, qui doit être responsable ? Afin de mieux soutenir à la fois la vitesse et la sécurité, ainsi que l’impact commercial, vous voulez que vos équipes de développement et vos clients dirigent votre prise de décision. D’un point de vue technique, vos développeurs ont une meilleure idée du contenu d’une version, de l’existence d’interdépendances et de l’existence de tests, que n’importe quel comité consultatif sur les changements. D’un point de vue commercial, il est temps que nous réalisions que le client est l’arbitre final de ce qui fonctionnera et ne fonctionnera pas, pas un quelconque cadre supérieur, et très certainement pas votre conseil consultatif sur les changements.

Un conseil consultatif sur le changement peut être plus lent, mais au moins c’est plus sûr, n’est-ce pas ?

Le conseil consultatif sur le changement (et une grande partie de ce que vous trouverez dans ITIL), pourrait sembler être des moyens raisonnables de réduire les risques et d’ajouter de la rigueur, en particulier dans les environnements complexes à évolution lente. Si vous n’avez qu’une seule chance tous les 30 ou 90 jours de changer la production, maintenir les choses en dehors des versions avec des barrières de qualité et des approbations de la direction semble être un bon moyen de gérer le risque. Personne ne discutera que c’est un processus plus lent (qui peut ajouter des semaines ou des mois au temps entre un développeur écrivant du code et sa mise en production), mais c’est plus sûr, non ?

En fait, non. Ce n’est pas le cas.

Une étude pluriannuelle portant sur une grande variété d’industries et d’environnements a révélé que le fait d’avoir un CAB ou un processus similaire d' »approbation externe » donnait de moins bons résultats que de ne pas avoir de processus d’approbation du tout. Voici ce que l’auteur principal, le Dr Nicole Fosgren, avait à dire sur les résultats :

Nous avons constaté que les approbations externes étaient négativement corrélées avec le délai d’exécution, la fréquence de déploiement et le temps de restauration, et n’avaient aucune corrélation avec le taux d’échec des changements. En bref, l’approbation par un organisme externe (tel qu’un responsable ou un CAB) ne permet tout simplement pas d’augmenter la stabilité des systèmes de production, mesurée par le temps de restauration du service et le taux d’échec des changements. En revanche, elle ralentit certainement les choses. C’est, en fait, pire que de n’avoir aucun processus d’approbation des changements du tout.

Qu’est-ce qui est mieux que pas de gestion du changement du tout ?

Le Dr Fosgren et son équipe ne suggèrent pas réellement que vous n’ayez pas de processus d’approbation, mais étant donné la mauvaise performance des CAB dans le monde réel, nous devrions repenser le type de processus qui vous gardera réellement en sécurité.

Voici une autre citation de l’étude Accelerate :

Notre recommandation basée sur ces résultats est d’utiliser un processus d’approbation de changement léger basé sur la revue par les pairs, comme la programmation par paire ou la revue de code intrateam, combiné à un pipeline de déploiement pour détecter et rejeter les mauvais changements. Ce processus peut être utilisé pour tous les types de changements, y compris les changements de code, d’infrastructure et de base de données.

Les revues de code par les pairs combinées avec What Now?

Lorsque j’ai lu cette recommandation en mars 2018, je n’ai eu aucun problème à visualiser la première moitié : les revues de code par les pairs et les démonstrations d’équipe hebdomadaires étaient déjà les normes chez BlazeMeter. La deuxième moitié ? Pas tant que ça ! Nous étions une application SaaS cloud-native « moderne », mais je n’avais jamais entendu parler d’un « pipeline de déploiement qui détecte et rejette les mauvais changements. »

Pour gérer le risque lors des versions à l’époque, nous utilisions une combinaison de déploiements bleu/vert et de versions canari. La plateforme faisait le « pushing » mais pas le « detecting » ou le « reject » – c’était à nos SRE les plus brillants, qui vérifiaient manuellement la santé de dizaines de choses avant que nous ne passions à 100% d’utilisateurs. En lisant « détecter et rejeter les mauvais changements », on ne voyait que l’image d’une boîte noire sur un tableau blanc portant la mention « la magie opère ici ». Flashbacks des études de cinéma à l’université, où j’ai appris ce que signifiait « deus ex machina ».

Détecter et rejeter : Les exemples sont là si vous regardez

Beaucoup de choses peuvent changer en deux ans. Depuis que j’ai rejoint Split en tant qu’évangéliste CD, j’ai regardé Lukas Vermeer décrire comment le pipeline de déploiement de Booking.com peut détecter et revenir sur un mauvais changement en l’espace d’une seule seconde. J’ai écouté Sonali Sheel de Walmart Labs expliquer comment ils utilisent leur plateforme Expo pour arrêter un déploiement à mi-chemin avant qu’il ne fasse des dégâts sur leurs métriques clés, quelque chose qu’ils appellent Test to Launch.

La plateforme Split Feature Delivery a été créée par des personnes ayant des visions similaires de la gestion moderne du changement, basées sur des expériences vécues chez LinkedIn, Salesforce.com et Yahoo. Les fondateurs ont obtenu des conseils de personnes qui avaient abordé la complexité, la vitesse et l’échelle de systèmes similaires chez Amazon et Microsoft.

Quand j’ai entendu parler de Split et découvert les exemples qu’ils commercialisaient, j’ai sauté sur l’occasion de les rejoindre. Construire une telle plateforme en interne était quelque chose que seuls quelques géants avaient le temps et les ressources pour s’y attaquer. Si le même genre d’exposition à grain fin et de détection d’impact automatisée était disponible en tant que SaaS, alors la livraison de logiciels axée sur l’impact pourrait être débloquée pour chaque équipe, et pas seulement pour les startups à licorne.

C’est incroyable, mais ça ne marchera pas ici

Une chose amusante s’est produite à maintes reprises lorsque j’ai voyagé dans des conférences sur la technologie, donnant des conférences sur les premiers pionniers qui avaient construit ces plateformes en interne. Les auditoires répondaient d’abord avec étonnement, puis avec résignation. « C’est plutôt cool, mais nous ne sommes pas Booking.com, LinkedIn ,ou Facebook. Nous ne pouvons pas faire ça dans notre environnement. »

Dans mes efforts pour être « neutre vis-à-vis des fournisseurs » en évitant les spécificités de la mise en œuvre de Split, j’avais pratiquement redessiné cette image floue d’une boîte noire marquée « la magie se passe ici ».

Et si ce n’était pas si difficile ?

Si vous n’avez jamais vu une plateforme qui fournit un contrôle à grain fin de l’exposition et un mécanisme automatisé rigoureux pour détecter et rejeter les mauvais changements dans votre environnement, on ne peut pas vous reprocher de penser que c’est de la science-fiction.

Il s’avère qu’il n’y a que quatre problèmes principaux à résoudre ici :

1. Découpler le déploiement de la libération, de sorte que le code peut être poussé jusqu’à la production mais empêché d’être exécuté jusqu’à ce qu’il soit prêt. Cela facilite la véritable intégration continue, les petites tailles de lots, le développement de fonctionnalités incrémentielles et la ramification par abstraction, qui sont tous critiques pour tirer la livraison continue où le flux est la norme.
2. Exposer sélectivement le nouveau code, en commençant par de petites audiences internes et en travaillant vers l’extérieur. Cela facilite les tests en production, le dogfooding, les programmes d’accès anticipé et le regroupement des changements pour les clients réfractaires au changement.
3. Ingérer les données de comportement du système et des utilisateurs et les aligner avec les données d’exposition indiquant qui entre et sort de chaque cohorte d’utilisateurs. L’objectif est de rendre le processus d’attribution (alignement de « Qui a obtenu quoi ? », avec « Ensuite, ceci s’est produit ») automatique et continu.
4. Comparer les modèles de métriques entre les personnes incluses et exclues de chaque cohorte pour identifier (et éventuellement alerter sur) les différences significatives. Vous avez peut-être déjà vu ce schéma dans le contexte des  » tests A/B  » qui suivent généralement l’impact des changements sur une métrique de conversion, mais ici nous parlons de suivre largement l’impact de tout le travail d’ingénierie et d’avoir une surveillance toujours vigilante des impacts sur toutes les métriques valorisées par l’organisation, que l’impact sur ces métriques soit attendu ou non.

La livraison progressive : Une fondation facilement établie

Découpler le déploiement de la version et exposer sélectivement le nouveau code deviennent connus sous le nom de livraison progressive, un terme inventé par l’analyste RedMonk James Governor. De multiples fournisseurs commerciaux de drapeaux de fonctionnalités fournissent ces capacités hors de la boîte et un consensus émerge sur le fait que les drapeaux de fonctionnalités ont rejoint la liste des outils de développeurs qu’il est plus logique d’acheter que de construire et de maintenir en interne.

Les feature flags sont une base essentielle pour atteindre le flux, mais en soi, ils n’accélèrent pas la détection de l’impact. La plupart des implémentations de drapeaux de fonctionnalités facilitent le flux, mais ne font rien pour indiquer si tout va bien ou si vous obtenez des résultats significatifs.

Head’s Up : Data Scientists Don’t Scale

Ingérer le système et le comportement des utilisateurs et l’aligner automatiquement sur les cohortes exposées est rare parmi tous les systèmes internes, sauf les plus sophistiqués. La plupart des équipes qui tentent cette pratique font beaucoup de travail manuel et ad-hoc en science des données. Comme elles sont limitées par les ressources humaines plutôt que par la capacité informatique, elles sont obligées de choisir quand et où prêter attention.

La charge cognitive n’est pas votre amie lorsque vous visez le flux, c’est pourquoi la conception de Split n’exige même pas que les équipes choisissent les événements à associer à chaque déploiement de drapeaux de fonctionnalités ; tous les événements ingérés, une fois liés aux métriques organisationnelles, sont continuellement attribués aux cohortes actives et inactives de chaque déploiement, sans aucune intervention. Split facilite également le travail d’identification et d’ingestion des données d’événements grâce à des intégrations avec Segment, Sentry, mParticle et Google Analytics.

Semper Fi pour les pipelines de livraison continue

Comparer les modèles de métriques entre les personnes incluses et non incluses dans chaque cohorte de manière rigoureuse pour déterminer automatiquement les différences significatives est encore plus rare dans la nature que l’attribution. C’est exactement le problème que les modules Monitor et Experimentation de Split résolvent. Monitor se concentre sur l’identification et l’alerte sur les impacts sur les métriques lorsqu’un déploiement est en cours (également connu sous le nom de  » limiter le rayon d’explosion des incidents « ), tandis que Experimentation, comme les tests A/B, cherche à fournir une source continue de données non biaisées, non limitées par la disponibilité d’un analyste, pour indiquer si chaque fonctionnalité a atteint un impact souhaité ou non.

Mieux ensemble : Examen par les pairs, livraison progressive et prise de sens automatisée

Pourquoi nous efforçons-nous d’obtenir un flux ? Il ne s’agit pas de rendement. Il s’agit de résultats. Nous recherchons le flux afin de pouvoir itérer la boucle de rétroaction idée -> mise en œuvre -> observation avec moins de friction en moins de temps. Que vous l’appeliez « développement axé sur l’impact » ou « développement axé sur le client », cette approche visant à aller plus vite avec une conscience accrue (et plus rapide) des résultats va bien au-delà du « pipeline de déploiement pour détecter et rejeter les mauvais changements » que l’équipe DORA nous a recommandé de combiner avec les pratiques d’examen par les pairs. Oui, nous pouvons détecter et rejeter automatiquement les mauvais changements, mais plus important encore, nous pouvons construire un processus reproductible pour trianguler vers des résultats commerciaux significatifs.

En savoir plus sur la réalisation de la gestion du changement et du flux, ensemble, dans la livraison continue

• Voyez une vidéo de quatre minutes sur la définition de la livraison continue pour voir pourquoi la petite taille des lots est essentielle pour obtenir un flux cohérent.
• Piquez des conseils auprès de plusieurs équipes qui expédient quotidiennement en production dans le livre électronique d’O’Reilly, Continuous Delivery in the Wild
• Voyez une vidéo approfondie avec Craig Sebenik (LinkedIn, Crunchbase, Matterport) sur les avantages de passer à un développement basé sur le tronc.

Vous cherchez d’autres contenus intéressants sur l’obtention de résultats significatifs avec la livraison de fonctionnalités à l’échelle ? Mettez le blog Split en signet, regardez-nous sur YouTube ou suivez-nous sur Twitter @splitsoftware.