Pourquoi les environnements de test ne fonctionnent-ils que lorsqu'ils appartiennent à la plateforme ?

Les déploiements sont l'un des rares moments où le développement logiciel semble encore risqué.

Les équipes peuvent disposer de tests, d'un environnement de préproduction et de processus de révision minutieux, mais la dernière étape reste incertaine. Ce changement se comportera-t-il de la même manière en production ? Interagira-t-il correctement avec les données, le trafic et l'infrastructure existants ? Introduira-t-il des régressions que personne n'avait anticipées ?

Les environnements de test existent pour réduire cette incertitude. En théorie, ils offrent une promesse simple : voir vos modifications fonctionner dans un environnement similaire à celui de la production avant qu'elles n'atteignent la production.

Dans la pratique, tenir cette promesse est beaucoup plus difficile qu'il n'y paraît.

La question n'est pas de savoir si les environnements de test sont utiles. La question est de savoir qui est responsable de leur fiabilité.

L'attrait des environnements de test

Les environnements de test sont faciles à expliquer.

Chaque branche de fonctionnalité dispose de son propre environnement. L'application, les services, le routage et la configuration reflètent la production. Les développeurs, les testeurs et les parties prenantes peuvent interagir avec un comportement réel plutôt qu'avec des maquettes ou des hypothèses.

Lorsque cela fonctionne bien, cela change la façon dont les équipes livrent les logiciels. Les retours d'information sont plus rapides. Les régressions sont détectées avant que les utilisateurs ne les remarquent. Les conversations passent de la spéculation à l'observation.

L'idée semble si évidente que de nombreuses équipes pensent que les environnements de test ne sont qu'une question de mise en place d'une infrastructure supplémentaire.

Cette hypothèse résiste rarement au premier contact avec la réalité.

Pourquoi « simplement mettre en place un environnement » ne fonctionne pas à grande échelle

Un environnement de test chez Upsun n'est pas simplement un conteneur d'application avec une URL différente.

Pour se comporter comme un environnement de production, il doit avoir la même configuration, les mêmes services et souvent des données similaires à celles traitées en production. 

Elle nécessite un routage, des certificats, des contrôles d'accès et une observabilité. Elle doit être créée automatiquement, détruite proprement et isolée des autres environnements.

Chacune de ces exigences peut être résolue individuellement. La difficulté vient de leur combinaison en un ensemble qui fonctionne de manière cohérente, à chaque fois, sans intervention manuelle.

La plupart des équipes découvrent que la complexité ne réside pas dans la création d'un seul environnement de test. Elle réside dans la création de centaines d'environnements au fil du temps, de manière sûre, prévisible et sans ralentir l'organisation.

Le système caché derrière un aperçu « simple »

Lorsque les environnements de test fonctionnent, ils disparaissent à l'arrière-plan. Lorsqu'ils ne fonctionnent pas, ils deviennent une source de friction et de méfiance.

Pour fonctionner de manière fiable, les environnements de test dépendent d'un système capable de :

• Reproduire l'infrastructure et la configuration de manière déterministe
• Cloner ou approximer les données de production sans exposer les informations sensibles
• Acheminer le trafic et gérer les certificats automatiquement
• Appliquer le même comportement de déploiement et de surveillance dans tous les environnements
• Contrôler l'accès afin que les aperçus puissent être partagés en toute sécurité
• Nettoyer les ressources sans laisser de traces en termes de coûts et de sécurité

Il ne s'agit pas ici de commodité pour les développeurs, mais bien du comportement de l'infrastructure.

Lorsque des environnements de test sont ajoutés à des systèmes existants, les équipes finissent par maintenir une plateforme parallèle uniquement pour les prendre en charge. Au fil du temps, cette plateforme devient fragile, incohérente et coûteuse à faire évoluer.

Pourquoi la propriété est plus importante que les fonctionnalités

C'est là que la distinction entre les outils et les plateformes devient importante.

Vous pouvez assembler des environnements de test à partir de composants individuels. De nombreuses équipes le font. Mais une fois que les environnements de test deviennent essentiels à la livraison, quelqu'un doit en assumer la responsabilité tout au long de leur cycle de vie.

Cette responsabilité consiste notamment à décider comment les environnements sont créés, quelle est leur durée de vie, comment ils accèdent aux données, comment ils sont sécurisés et comment les pannes sont gérées. Elle consiste également à s'assurer que le comportement de l'environnement de test reste aligné sur la production à mesure que le système évolue.

Lorsque cette responsabilité incombe aux équipes applicatives, les environnements de test perdent peu à peu leur crédibilité. Lorsqu'elle incombe à une équipe interne dédiée aux plateformes, elle devient un autre produit à créer et à maintenir.

Une plateforme gérée change la donne en assumant entièrement cette responsabilité.

Les environnements de test en tant que comportement de la plateforme

Lorsque les environnements de test font partie intégrante de la plateforme, ils cessent d'être des cas particuliers.

La création de branches devient le déclencheur de la création d'environnements. L'infrastructure et les services sont définis de manière déclarative. Le routage et les certificats apparaissent automatiquement. L'observabilité se comporte de la même manière partout. Les environnements sont isolés par défaut et supprimés lorsqu'ils ne sont plus nécessaires.

Le changement important n'est pas technique. Il est organisationnel.

Les équipes cessent de débattre pour savoir si un aperçu est « suffisamment proche » de la production. Elles lui font confiance, car la plateforme garantit la cohérence. Les boucles de rétroaction se resserrent. Les déploiements sont considérés comme une routine plutôt que comme un risque.

La valeur ne provient pas de l'environnement lui-même, mais des garanties qui l'entourent.

Ce que cela change pour les équipes

Lorsque les environnements de test appartiennent à la plateforme, les équipes applicatives n'ont plus besoin de :

• Provisionner manuellement l'infrastructure pour chaque branche
• Maintenir une logique de déploiement distincte pour les aperçus
• Copier ou nettoyer les données à la main
• Configurer le DNS et les certificats à plusieurs reprises
• Contrôler l'accès aux environnements à courte durée de vie
• Se soucier du nettoyage après les expériences
• Au lieu de cela, les responsabilités sont clairement réparties.

La plateforme est responsable des environnements, de l'infrastructure et de la gestion du cycle de vie. Les équipes sont responsables de la logique applicative et des décisions de livraison.

Cette répartition permet aux environnements de test d'évoluer sans devenir un goulot d'étranglement.

La véritable raison pour laquelle les environnements de test sont importants

Les environnements de test sont souvent présentés comme une fonctionnalité de productivité. C'est vrai, mais leur véritable valeur est plus profonde.

Ils réduisent les risques sans ralentir les équipes. Ils concrétisent la collaboration. Ils transforment les inconnues en comportements observables avant que les changements n'atteignent les utilisateurs.

Plus important encore, ils créent la confiance.

Cette confiance ne peut être maintenue que si les environnements de test se comportent comme une propriété de la plateforme, et non comme une construction fragile maintenue par des scripts et des conventions.

Les plateformes transforment la confiance en une valeur par défaut

La création d'environnements de test fiables n'est pas une question d'ingénierie intelligente. Il s'agit de déterminer où se situe la responsabilité.

Une plateforme qui possède des environnements peut faire de la sécurité une valeur par défaut. Les équipes avancent plus vite non pas parce qu'elles sont imprudentes, mais parce que le système absorbe la complexité à leur place.

C'est à cela que servent les environnements de test.

En savoir plus

• Découvrez les environnements de développement instantanés sur Upsun
  Découvrez comment Upsun crée automatiquement des environnements isolés, similaires à ceux de production, pour chaque branche.
• Lisez l'article technique approfondi sur les environnements de test
  Pour plus de détails sur la mise en œuvre et les processus des développeurs, consultez l'article original du Dev Center.