Description

Le Dark Launching (DL) est un pattern de livraison [Cartwright 2022] et consiste à déployer le code "invisible pour tout le monde, à l'exception des employés internes et de petites cohortes d'utilisateurs réels, ce qui nous permet de tester et de faire évoluer la fonctionnalité jusqu'à ce qu'elle atteigne l'objectif commercial souhaité" [Kim 2016]. Le terme a été inventé en 2008 lorsque Facebook a révélé la technique utilisée pour lancer le Facebook Chat [Limoncelli 2014]. 

Pour permettre la DL, il faut introduire des "Feature Toggles" (FT) pour désactiver le feedback de l'utilisateur et laisser la transaction se comporter différemment [Limoncelli 2014] pour faciliter le débogage. Un FT est implémenté avec un mécanisme clé/valeur (disons un fichier XML) ; le code vérifie la valeur d'une clé qui peut être l'identifiant de la fonctionnalité, la valeur indique si le nouveau code doit être exécuté ou non. Comme le code est protégé par un FT, il évite principalement d'attendre une version big bang [Kim 2016]. Il permet un développement basé sur le tronc [Hammant 2021] avec un état d'esprit "tout le monde commite sur le tronc au moins une fois par jour" [Ford 2016].

Les lancements sombres diffèrent des lancements canariens car ils ne nécessitent pas l'exécution simultanée de plusieurs versions d'une application dans un environnement, ce que vous devez faire pour un lancement canari.

Impact sur la maturité des tests

En se basant sur l'exemple de Facebook, Martin Fowler propose à titre d'exemple, une feuille de route d'implémentation de fonctionnalités qui pourrait être [Fowler 2020] : développer toutes les fonctionnalités back-end et l'IU sera retenue et serait ensuite une clé de voûte dans le processus de livraison de nouvelles fonctionnalités. L'interface utilisateur est un moyen de faciliter les tests de bout en bout (E2E) [Kim 2016]. Le fait de disposer d'une interface utilisateur permet de réaliser des tests E2E par les propriétaires d'entreprise et des tests internes. Par conséquent, "retenir" ne signifie pas "développer à la fin", car cela se traduirait par une mauvaise expérience pour l'utilisateur. Le DL doit être considéré comme un " modèle d'étrangleur " [Fowler 2004] qui consiste à créer quelque chose de nouveau qui déprécie une petite partie de quelque chose d'ancien ; puis, après quelques itérations, la nouvelle fonctionnalité complète est livrée et remplace toute ancienne fonctionnalité [Harmmant 2013].

DL permet également de simuler des tests de charge sur l'ensemble du produit. Il s'agit d'un test de charge participatif pour l'utilisateur qui donne confiance dans le fait que le système sera capable de faire face à des charges réalistes. Il fournit également des informations pour la planification de la capacité [Limoncelli 2014].

Étant donné que la DL est fortement liée à la conception, la DL est un modèle de qualité intégré qui doit être introduit rapidement dans le processus d'idéation. Il faut également que des personnes de l'exploitation prennent part à cette décision de conception afin qu'elles soient conscientes des contraintes de déploiement (par exemple, une nouvelle configuration dans un nouveau fichier XML qui doit être déployé pour que les choses fonctionnent).

Le point de vue d'Agilitest sur cette pratique

DL est un modèle très utile pour permettre la création de scripts de test dès que possible. Il évite clairement d'attendre la livraison finale pour coder des scénarios de test. Bien que la technologie #nocode impliquée dans agilitest permette un scriptage rapide et stable (pas d'algorithme délicat à coder et à tester en même temps que l'entreprise), elle facilite le flux de livraison et empêche les testeurs de générer un autre mur de confusion [Kawaguchi 2020] qui créera des problèmes de qualité.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍