Environnements de test éphémères : Parfois, vous devez simplement tuer vos créations

SECTION 1

Introduction

Que se passe-t-il lorsque vous devez mettre à l'échelle vos tests ? Un environnement de test partagé est généralement le premier choix, offrant aux équipes un lieu unique pour déployer du code et créer un contexte commun. Cependant, à mesure que la complexité augmente, plus de développeurs, composants supplémentaires et davantage de microservices, un seul environnement de test ne suffisait plus. C'est là que les environnements de test éphémères entrent en jeu.

SECTION 2

Qu'est-ce qu'un environnement de test éphémère ?

Un environnement de test éphémère est une pile d'infrastructure isolée et de courte durée où le code peut être testé rapidement et facilement. Ils sont isolés en ce sens qu'ils sont complètement indépendants de toute autre partie de votre infrastructure (sans dépendances), et de courte durée en ce qu'ils n'ont pas besoin de persister plus longtemps que ne l'exige une tâche discrète, ils peuvent simplement être provisionnés à la demande. Ils simplifient le processus et l'automatisation associés à votre orchestration existante, ce qui rend incroyablement facile à la fois leur création et leur destruction.

SECTION 3

Pourquoi les environnements éphémères sont-ils nécessaires ?

### Le goulot d'étranglement de l'environnement partagé unique

« À mesure que vous continuez à vous développer, que les systèmes vieillissent et que davantage de développeurs arrivent », explique l'expert en infrastructure d'Adservio, « vous commencez à rencontrer des tensions en ayant un seul environnement de test auquel tout le monde se déploie avant la production, car vous déployez quelque chose là pour le tester. »

Dans ces instances, l'environnement de test devient un goulot d'étranglement.

« Chaque équipe a besoin que l'environnement soit exactement comme la production, sauf pour son composant, ce qui devient impraticable. »

### La tentation des environnements dédiés par équipe

Occasionnellement, les organisations tentent de contourner ce goulot d'étranglement en créant plusieurs environnements de test, où chaque équipe dispose de son propre environnement dédié dans lequel, « elle peut déployer ce sur quoi elle travaille, le tester et partager le contexte sans perturber les autres équipes. »

Cependant, cela crée un tout nouvel ensemble de défis. « Vous vous retrouvez alors avec le problème suivant : 'J'ai déployé la nouvelle version sur l'environnement de test de mon équipe et je l'ai déployée en production. Mais les autres équipes ont une ancienne version, dois-je déployer ma nouvelle version sur leur version ? Et vais-je me souvenir de le faire ? Est-ce que cela m'intéresse ?' »

Cela signifie « soit chaque équipe est responsable de maintenir à jour toutes les parties de son environnement avec le statut réel de la production, soit chaque équipe publiant quelque chose de nouveau doit s'assurer que cela revient à tous ces autres environnements de test. »

Bien qu'il soit possible d'utiliser l'automatisation pour maintenir les services à jour, cela comporte un risque : lorsqu'une équipe fait quelque chose de nouveau, par exemple, en construisant un microservice dans Kubernetes, l'automatisation d'infrastructure que vous avez mise en place peut ne plus suivre.

> Cela nécessite un changement dans notre façon de penser les choses... il y a un compromis à un moment donné entre la douleur subie par les équipes en raison d'environnements hautement partagés que tout le monde essaie de maintenir en vie, par rapport à une approche en libre-service.

SECTION 4

Environnements de test éphémères en pratique

### Repenser complètement son approche

Nos experts soulignent que lorsque nous parlons d'environnements de test éphémères, nous parlons vraiment d'éphémérité. Citant un exemple de mise en œuvre d'environnements éphémères lors du travail avec un client, ils insistent sur le fait que « nous essayions vraiment d'encourager une courte durée de vie... vous le provisionnez pour cette carte Jira particulière, ou pour tester ce bug ou apporter cette modification. Ce n'est pas 'créer un environnement éphémère pour mon équipe', car plus longtemps ils vivent, plus ils deviennent désynchronisés et plus ils peuvent dériver. »

En d'autres termes, il est important de repenser complètement votre approche. « Cela nécessite un changement dans notre façon de penser les choses. Et je pense qu'il y a un compromis à un moment donné entre la douleur subie par les équipes en raison d'environnements hautement partagés que tout le monde essaie de maintenir en vie, par rapport à une approche en libre-service. »

### L'automatisation et le libre-service, clés de voûte

@cite:pipelines-cicd-auto-reparants-self-healing

Un autre élément critique des environnements éphémères est de disposer du niveau d'automatisation approprié pour que les équipes puissent provisionner rapidement et facilement des environnements de test. Nos experts donnent l'exemple d'une plateforme d'automatisation développée pour un client, spécifiquement conçue pour alléger ce fardeau.

Le processus manuel, expliquent-ils, prenait généralement quelques semaines et avait lieu généralement tous les six mois environ. Le résultat était généralement quelque chose « très lent, rempli d'erreurs ». Mais avec la plateforme d'automatisation, c'était massivement réduit ; le provisionnement d'un nouvel environnement est passé de semaines à quelques secondes.

« Vous pouviez cliquer sur un bouton et en avoir un prêt en 37 minutes. Cela a vraiment aidé à transformer le processus de publication, en passant de 'réserver votre créneau de publication et devoir aller tester et espérer que cela fonctionne là', à quelque chose où 'vous pouvez avoir confiance que lorsque vous cliquez sur publication, cela va se déployer pour tester et les tests seront complétés avec succès'. »

Nos experts expliquent également comment cette plateforme d'automatisation particulière a été construite. « C'était une approche très tactique consistant à construire une légère automatisation pour prendre tous les bits manuels et les lier ensemble », disent-ils. Spécifiquement, « une pile de fonctions lambda provisionnerait un cluster Kubernetes et déploierait les éléments dans un cluster Kubernetes partagé. Elle provisionnerait également une pile CloudFormation ayant une instance avec tous les anciens éléments monolithiques. Un orchestrateur intégré au CI/CD qui gère tous ces différents éléments en parallèle. »

SECTION 5

Quand les environnements de test éphémères ne sont-ils pas appropriés ?

Bien que les environnements de test éphémères puissent être très efficaces dans certaines circonstances, cela ne signifie pas qu'ils sont toujours la bonne option. « Si vous construisez quelque chose de brillant et nouveau qui n'est pas fortement couplé et a une limite de domaine très claire, vous pourriez ne pas en avoir besoin », explique-t-on.

Ils sont plus appropriés pour « tout ce qui touche aux brownfields ou à la dette technique ». Si vous tentez de scinder un monolithe, par exemple, « vous allez devoir disposer d'un environnement de test cloud assez lourd, par opposition à pouvoir exécuter les choses localement. »

SECTION 6

Environnements éphémères et aperçus continus

Les environnements de test éphémères partagent de nombreuses similitudes avec un autre concept qui commence à être plus largement discuté dans l'industrie : les aperçus continus.

Selon nos experts, les deux concepts ont un « chevauchement important », mais il est important de distinguer les deux. Les aperçus continus sont, selon eux, « avoir un lieu partagé pour que la fonctionnalité et les nouvelles fonctionnalités soient visibles et testables ». Cela ne signifie pas seulement les tests automatisés, mais aussi les tests humains, en d'autres termes, les aperçus continus, en exploitant les environnements de test éphémères, peuvent permettre aux responsables AQ (et à d'autres) d'essayer rapidement de nouvelles choses.

### Un aperçu déployé pour chaque pull request

Nos experts expliquent comment cela fonctionne : « Je crée une demande de tirage avec une nouvelle fonctionnalité sur une branche et vous obtenez automatiquement une version de celle-ci déployée en ligne à une URL distincte. Je peux ensuite aller réellement voir la nouvelle application, et n'importe qui d'autre peut cliquer et la visualiser et elle s'exécute dans un contexte partagé. Et puis, lorsque je prévisualise réellement les modifications pour moi-même... vous obtenez ce déploiement d'aperçu. »

Il y a des avantages significatifs à une telle technique. « Cela rend vraiment facile pour quelqu'un d'autre de pouvoir regarder le travail que vous faites sans avoir à extraire votre code et l'exécuter localement. » Cela pourrait aider les membres de l'équipe qui ne sont pas particulièrement techniques à aller réellement jouer avec les nouvelles fonctionnalités avant qu'elle ne soit réellement en direct. À son tour, cela signifie plus d'efficacité dans le processus de développement et de test et, finalement, un logiciel de meilleure qualité.

@cite:shift-left-testing-benefices

SECTION 7

Simplifier les tests lors du traitement des défis complexes de développement

Les environnements de test éphémères, et les techniques connexes comme les aperçus continus, peuvent fournir des avantages significatifs en matière de productivité et de qualité. C'est vrai, cela nécessite un changement de mentalité, l'idée de créer des environnements qui sont vraiment, dans tous les cas pratiques, hautement jetables peut sembler étrange. Cependant, du point de vue logiciel, une telle façon de travailler peut clairement délivrer un impact à long terme. Et dans une industrie qui est aujourd'hui obsédée par ne voir l'IA que comme la route vers l'amélioration, exploiter d'autres techniques et approches pourrait bien être tout aussi critique que d'adopter ce qui reçoit le plus d'attention et de battage médiatique.

Avertissement : Les déclarations et opinions exprimées dans cet article sont celles de l'auteur(s) et ne reflètent pas nécessairement les positions d'Adservio.

FAQ

Questions fréquentes