Le besoin d’accélération des cycles de livraison logicielle pousse les entreprises à mettre en place des pipelines de déploiement automatisées pour rationaliser les diverses activités par l’automatisation et la répétabilité.
Néanmoins, 47% des entreprises considèrent les tests de non-régression comme l’un des enjeux majeurs non résolus, avec des problématiques sous-jacentes d’environnements de tests (55%) et de couverture de tests insuffisante (39%).
Bon nombre de ces pipelines peinent donc à remplir leur objectifs, se retrouvant plus fragiles et plus rapidement obsolètes face aux divers stimulis qu’une organisation subit, comme l’évolution du produit ou la rotation des collaborateurs.
Cet article explore comment l’approche systémique supportée par le modèle MAMOS peut non seulement résoudre ces problèmes, mais également favoriser une durabilité à long terme du système de production logicielle.
Les tests de non-régression, un défi d’équilibriste
Les tests de non-régression sont peu attractifs pour beaucoup d’équipes : automatiser des scénarios répétitifs soit inexistants ou réalisés manuellement, résoudre des problèmes de fond comme des données de tests ou les environnements, et les maintenir.
Les arguments énoncés face aux tests de non-régression sont de ne pas justifier leur investissement. Accusés de ralentir les cycles de livraison et d’être coûteux à maintenir, apportant finalement peu d’améliorations pour toute l’équipe, du produit aux opérations.
La solution passe donc souvent par des approches locales de ce type :
- L’équipe produit définit les exigences et cas d’usages
- Les développeurs font des tests unitaires et d’intégration avec leur outil
- Un profil de testeur si présent met en place des campagnes de tests
- L’équipe produit fait de l’exploratoire et utiliser de l’analytique en production
- Les opérations mettent en place le monitoring qui leur semble pertinent.
Dans un tel scénario, les inefficiences sont nombreuses :
- Des exigences sont testées plusieurs fois par plusieurs personnes
- Les référentiels finissent désynchronisés sans mesure globale
- Chaque équipe optimise sa vision locale sans considérer le global.
Ces organisations ont localement optimisé les tests de non-régression avec une performance axée sur des indicateurs tels que le nombre de tests mis en place, sans contrebalance d’effets négatifs comme l’augmentation du temps d’exécution, la duplication de tests, ou un fort taux de faux positif.
Le résultat? À chaque changement logiciel, le coût d’analyse initiale devient plus élevé par les multiples impacts dilués sans consolidation, et le coût d’exécution augmente drastiquement, chaque équipe ayant une charge manuelle forte d’adaptation.
Une solution durable nécessite une approche intégrée
Une livraison logicielle oú les tests de non-régression sont apporteurs de valeur, robustes, et efficients nécessité une approche plus intégrée pour trouver un juste équilibre oú l’investissement justifie les résultats, tout en apportant une réelle satisfaction à l’équipe.
En voulant aller trop vite, les symptômes suivants se matérialisent:
- L’équipe ne sera pas alignée sur le sujet, continuant en partie comme avant
- Le management ne supportera pas la démarche ni les ressources nécessaires
- Les tests seront difficiles á maintenir, finissant souvent lents et instables
- Les résultats des tests ne seront utilisés que par une partie de l’équipe
- Avec le temps ou un stress de livraison, les tests seront ignorés.
Une approche intégrée passe par considérer l’ensemble du système de production logicielle pour que la démarche de tests de non-régression permette une amélioration globale de la performance, au-delà des silos techniques et organisationnels.
Cette approche intégrée est décrite dans le modèle MAMOS:
Figure 1: The software production system defined in MAMOS.
MAMOS décrit le système de production logicielle d’une organisation au travers des 5 domaines (Methods, Architecture, Management, Organization, Skills) et de 50 capacités de production logicielles au cœur desquelles les acteurs peuvent ou non performer.
Ces capacités sont à développer et aligner pour résoudre des problèmes systémiques par des solutions systémiques. Voyons comment l’utiliser pour implémenter des pipelines de déploiement avec des tests de non-régression pérennes.
L’architecture de pipeline de déploiement systémique
Des pipelines de déploiements de valeur, pérennes et optimisées sont la conséquence d’un système de production ayant (i) un alignement des capacités du système, (ii) des processus systématiques, et (iii) des forces de renforcement positives et négatives.
Nous nous appuyons ici sur la méthodologie AAA (Assess, Architecture, Accelerate) en se focalisant sur les deux étapes Architect et Accelerate étant celles applicables en faisant abstraction du contexte.
L’étape Architect consiste à organiser le système et le processus :
- Aligner la structure du système
- Assurer les capacités minimales
- Définir un processus systématique.
Aligner la structure du système
Cette première étape consiste à aligner les éléments structurants du système de production logiciel pour accélérer la mise en place des pipelines, et également réduire les forces qui pourraient au contraire ralentir ou inhiber la dynamique.
Dans notre cas, ces 3 capacités sont à aligner :
- Vision pour assurer un sponsor exécutif et un alignement transverse
- Structure organisationnelle clarifiant les responsabilités
- Focus définissant les périmètres à adresser en priorité.
Le support exécutif est á aller chercher à un niveau ayant un capacité d’action et d’influence de bout-en-bout pour optimiser la vue globale et résoudre des problèmes structurels, au-delà des équipes produits, d’ingénierie ou d’opérations d’un périmètre donné.
Cette vue d’ensemble permettra de définir par rapport à des enjeux d’entreprises quels périmètres ont une besoin d’une accélération pérenne de leur produits digitaux pour maintenir l’énergie dans le temps, partageant régulièrement la création de valeur.
Assurer les capacités minimales
Aller trop vite sans fondations, c’est la garantie de devoir résoudre des problèmes prévisibles qui seront une perte de ressources pour l’organisation, et une source de démotivation pour une équipe venant tout juste de démarrer.
Il convient donc d’identifier et assurer le minimum de capacités de production requises en fonction de l’objectif poursuivi. Pour nos pipelines de déploiement, il faut analyser à réaliser des tests focalisés, robustes, et maintenus par des profils dans l’équipe.
Ces 3 capacités de MAMOS entrent donc en jeu:
- Modularity pour évaluer la bonne cohésion fonctionnel des composants
- Integration afin d’assurer les environnements, jeux de données et disponibilité
- Skills mapping garantissant les compétences requises à chaque étape.
L’application de cette grille peut vous faire premièrement développer les capacités d’un périmètre applicatif souffrant d’un couplage trop fort entre ses composants, avec des environnements instables sans jeux de données rafraîchis, sans compétences pour définir les tests, ni les concevoir et les maintenir correctement.
Définir un processus systématique
Le système aligné, il est temps d’architecturer un processus systématique permettant (i) d’intégrer la mise en place des pipelines de déploiements dans le processus de production existant et (ii) de mesurer la concrétisation des livrables de non-régression.
Les points d’intégration dans le processus de production sont les suivants :
- Specify pour identifier les exigences à couvrir par les tests de non-régression
- Deploy afin d’exécuter à chaque déploiement les tests de non-régression
- Operate forçant à créer un test de non-régression pour chaque incident.
Ces 3 étapes permettent de systématiser les activités nécessaires au cycle de vie des tests de non-régression au sein des pipelines de déploiement. La difficulté est d’en faire une réalité en changeant les habitudes des équipes par la pratique et l’accompagnement.
L’accélération du déploiement de pipelines systémiques
La phase Accelerate fait suite à la celle d’Architect ayant défini le système, ses pré-requis et le processus à mettre en place. La priorité est ici d’implémenter le processus de manière efficiente, solide, et durable.
Ces 3 actions sont nécessaires et se complémentent :
- Tester et rapidement adapter
- Développer les capacités de support
- Étendre tout en contenant la complexité.
Tester et rapidement adapter
La pratique concrète du processus permet de confronter l’alignement du système et la définition du processus dans la dynamique réelle du système. L’objectif n’est pas de forcer le processus, mais d’adapter nos mesures ou le système par l’action.
Chacune des étapes est pour cela mesurée par des métriques de mise en place, qui ne sont en aucun cas des métriques de performance; elles visent à suivre l’implémentation effective des pipelines sur les périmètres définis, et à clarifier les attentes pour chacun.
Les métriques à suivre pour rapidement tester et itérer sont:
- La couverture d’exigence par des tests de non-régression
- Le résultats des tests exécutés par pipeline dans le temps
- Le nombre de défauts ouverts par environnement et criticité.
À ce niveau, 3 capacités de production sont à utiliser dans le cycle de développement:
- Measurement afin de développer les mesures factuelles définies
- Fail-fast pour aider les équipes à la rapide confrontation et surpasser l’échec
- Development en animant des sessions permettant de trouver des solutions.
En complément, des rétrospectives systématiques sont à mettre en place pour garantir la résolution des problèmes structurels rencontrés. Les capacités à actionner dans ce cas sont celles de Learn, Improve, Plan.
Développer les capacités de support
Une fois que les itérations ont pu développer un modèle fonctionnel dans un système de production logicielle donné, il faut assurer que les fondations soient suffisamment solides avant de déployer plus largement les nouvelles pratiques.
Les capacités de support du système de production logicielle sont celles qui permettent de rendre le processus répétable tout en garantissant le respect d’un cadre grâce à l’observabilité, le self-service, et la réplication des mécanismes d’apprentissages.
MAMOS identifie ces capacités de support de trois ordres:
- Observability de l’architecture standardiser la visualisation
- Self-service pour fournir un portail clé en main à d’autres équipes
- Organizational learning favorisant le partage inter-équipes des pratiques.
L’observabilité passe ici par l’automatisation des métriques standards définies en amont, directement collectées à l’exécution des processus qui, doivent être accessibles et activables à la demande via un portail pour les profils autorisés.
Étendre tout en contenant la complexité
La complexité a la fâcheuse tendance à grandir dans les systèmes complexes, et à s’accélérer sans contre-forces mises en place. Leur but est de contenir l’accumulation de complexité et d’éviter des sur-optimisations locales à effet négatif sur l’ensemble du système.
Les métriques de processus sont donc complémentées par des indicateurs de performance permettant d’équilibrer efforts et impacts, ainsi que d’étendre le déploiement des pipelines par la gestion du risque et la décentralisation progressive de l’autonomie des équipes.
Les 3 capacités á activer et développer sont :
- Performance afin de définir et mesurer les indicateurs de performance
- Risks pour ajuster le niveau de risque tolérable dans les itérations
- Empowerment pour développer l’autonomie des équipes.
La performance mesurée doit idéalement être raccrochée à la dynamique globale de transformation de production logicielle. Le modèle MAMOS en propose 3 pertinentes dans notre cas : deployment frequency, CFR, automation rate.
La fréquence de déploiement est ici l’indicateur pivot permettant de mesurer la bonne accélération de changements supportés par des tests non-régression, qui s’ils deviennent trop importants ralentissent la fréquence de déploiement et doivent être revus.
Le Change Fail Rate (CFR) permet quant à lui d’identifier les pipelines ayant besoin d’un renfort de tests de non-régression si le taux dépasse les plafonds définis. En complément, le taux d’automatisation permet de graduellement supprimer les activités manuelles.
Un exemple de pipeline systémiques à l’échelle
Les différentes étapes permettent de développer les capacités de production principales et celles en support pour des pipelines de déploiement résilientes et efficientes. La cartographie MAMOS s’approchera de la résultante suivante.
L’exemple suivant est extrait d’une expérience personnelle de mise en place de pipelines de déploiement systémiques à l’échelle. Les pratiques partagées ont permis de répliquer le modèle dans l’organisation, même si cet exemple se focalise sur un périmètre digital.
Le périmètre digital couvre les applicatifs clés aux mains des clients : le site e-commerce et l’application mobile, connectés à une myriade de solutions internes (référentiel produits, offres, client, paiement, gestion de la commande) et externes (principalement marketing).
L’application de la méthodologie a permis de passer d’une livraison en production toutes les 12 semaines, suivies de 2 semaines de correctifs, à une livraison par jour en production à 96% réussie, supportée par une centaine de tests et jusqu’à plus de 7000.
Un prochain article viendra détailler les différentes étapes et pratiques mises en place dans cette démarche d’industrialisation des pipelines de déploiement avec leurs tests de non-régression pour plus de valeur, de solidité, et de rapidité de livraison.
Maximiser l’impact avec l’approche systémique
L’approche systémique offre une solution holistique pour relever les défis complexes de production logicielle comme celui des pipelines de déploiement, réussissant à surpasser des paliers de performance restant trop souvent inachevés pour beaucoup d’entreprises.
Le paradigme se résume au travers du mantra “Build Better, Build Faster”, reconnaissant le besoin de création de valeur globale soutenue par des acteurs engagés et des capacités de production antifragiles, dont la vitesse durable d’itération en est une conséquence.
La méthodologie partagée AAA (Assess, Architect, Accelerate) s’étend au-delà des pipelines de déploiement en fournissant un modèle prêt à l’emploi en trois étapes, adaptables à d’autres contextes et problématiques de production logicielle.
Cette première étape d’analyse permet de prendre un recul complet sur votre système de production face à des problématiques récurrentes de qualité, vitesse, et d’efficience que des approches traditionnelles n’arrivent pas à adresser.
D’ailleurs, assurez-vous que les tests de non-régression de vos pipelines soient face à des exigences de qualité, car l’étude State of Software Quality 2023 a trouvé que 70% des défauts découlent de spécifications insuffisantes, et sont peut-être, votre première priorité.
Prenez du recul et maximisez votre impact avec AAA.
References
2023. Software Testing Statistics – 2023. Magnitia.
Antoine Craske (2021). 96% Successful Daily Web Production Deployments. La Redoute.io.