Description

La libération des canaris (RC) fait référence à l'époque où les mineurs testaient de nouvelles zones pour éviter d'être empoisonnés par des poches de gaz. En 1895, John Scott Haldane a proposé d'utiliser des canaris maintenus dans des cages pour détecter les zones potentiellement empoisonnées [Haldane 1895] ; si les oiseaux mouraient, les travailleurs évitaient ces zones. Heureusement, cette pratique a pris fin en 1987 [Baldwin 2014], bien qu'elle ait été ressuscitée dans le contexte DevOps.

Dans le cadre de DevOps, la RC est un moyen de réduire le risque d'une nouvelle version en la déployant à un petit sous-ensemble d'utilisateurs avant de la déployer à tous [Sato 2014].

CR, comme Dark Launches, est également un moyen de tester votre logiciel sans bloquer le processus de livraison, même avec des cycles de vie lents [Humble 2011]. De plus, la RC fournit un environnement de test qui peut être particulièrement difficile avec de très grands systèmes sans une solide architecture basée sur le partage.

CR, comme le déploiement Blue/Green [Fowler 2010], est basé sur deux ensembles (environnements) de serveurs :

• un environnement "N" avec tous les serveurs configurés avec tous les composants à la version N
• un autre environnement "N+1" avec tous les serveurs configurés avec des composants à la version N+1

Un routeur ouvre l'environnement "N+1" à quelques utilisateurs qui contribueront à l'effort de test en utilisant le nouveau système. Ce mécanisme permet de maintenir la satisfaction globale des utilisateurs puisque la plupart d'entre eux sont affectés à l'environnement stable "N".

‍

Le routeur sélectionne généralement des "utilisateurs puissants" pour atteindre l'environnement "N+1", comme les testeurs, les zones géographiques ou les bêta-testeurs [Lee 2020]. Cette technique permet [Humble 2011] :

• Déploiement des utilisateurs de l'environnement "N" à "N+1" en augmentant le nombre d'utilisateurs dans le "N+1" éventuellement combiné avec des bascules de fonctionnalités intelligentes pour sélectionner la catégorie d'utilisateurs.
• Annulation d'une mauvaise version en arrêtant simplement de router les utilisateurs vers la mauvaise version.
• Fournir une saveur de test A/B pour que les utilisateurs évaluent une mise en œuvre différente de leur utilisation [Young 2014] [Moustier 2019-1].
• Vérifier si l'application répond aux exigences de capacité en augmentant progressivement la charge.

CR facilite également la mise en place du Blue/Green Deployment (BGD) en ajoutant plus de serveurs (microservices ou composants si la solution est trop petite) dans le " N+1 " à mesure que le nombre d'Utilisateurs augmente. En raison de ces similitudes, le CR est souvent mélangé avec le BGD en raison de la fonctionnalité de déploiement en continu mais, alors que le CR propose une construction progressive de la solution, le BGD fait migrer les Utilisateurs vers une version entière de la solution [Bryant 2018].

Impact sur la maturité des tests

Derrière ce tableau idyllique, la RC n'est pas à la portée de tous en raison de l'infrastructure nécessaire et des mises à niveau des ressources telles que les bases de données [Humble 2011] ou les dispositifs distants. La RC implique donc l'utilisation de paradigmes architecturaux forts tels que le grid computing, les serveurs immuables [Morris 2013] ou une approche "share nothing". 

Un autre point d'attention est la quantité d'environnement. Une fois compris, il peut y avoir plus de deux versions travaillant en parallèle, mais cela serait difficile à gérer [Humble 2011] [Sato 2014] [Lee 2020].

De même, combiner le CR et le test A/B peut s'avérer délicat car les objectifs ne sont pas les mêmes : alors que le CR est conçu pour détecter les problèmes et les régressions, le test A/B est conçu pour choisir de manière statique entre les options [Sato 2014].

CR est applicable lorsque la solution [Bryant 2018].

• est composé de microservices, avec éventuellement des taux de publication indépendants.
• exige une grande disponibilité et la satisfaction des clients
• repose sur un composant tiers qui ne peut pas ou difficilement être intégré ou simulé en dehors d'un environnement de production et qui nécessite une version déployée pour fonctionner.

Cependant, la RC n'est pas recommandée lorsque [Bryant 2018].

• la solution ne tolère pas les défaillances car la vie des personnes ou les biens essentiels seraient mis en danger
• Les utilisateurs finaux sont sensibles au CR en raison des contraintes liées aux données (par exemple, les transactions financières).
• le nouveau stockage des données est incompatible avec le stockage actuel

Le point de vue d'Agilitest sur cette pratique

Si l'automatisation des scripts de test est confiée à des personnes spécifiques, la RC implique une bonne coordination entre les Devs & Ops qui fournissent la solution et les personnes qui automatisent les scripts ; sinon, des faux positifs seront générés notamment si le routage n'est pas effectué en conséquence. Pour réduire la quantité de risques générés par la RC, les développeurs sont impliqués dans l'automatisation des tests et fournissent généralement des scripts avec la technologie qu'ils connaissent : Les développeurs Java utiliseront probablement Java + Selenium pour automatiser leurs tests. Malheureusement, ces scripts basés sur Selenium présentent des problèmes dans le code, ce qui génère des faux positifs et les surcoûts qui vont avec.

Agilitest est un outil #nocode basé sur Seleniumless dont les seuls problèmes sont localisés uniquement dans le scénario. Le script est linéaire et ne contient ni instruction IF ni boucles qui sont sources d'erreurs. En raison de la culture des développeurs, ils considèrent cela comme un manque de fonctionnalité alors qu'il s'agit en fait d'une fonctionnalité. Cet état d'esprit introduit un silo qui pousse l'utilisation de l'agilité principalement au niveau de l'entreprise, créant ainsi de possibles problèmes de coordination...

‍

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

‍