Ton environnement de test te trompe

Un client m'a demandé un jour, en plein milieu d'une démo : « C'est quoi, le lorem ipsum ? »

C'est ce moment-là. L'URL de prévisualisation s'est chargée. Toutes les pages se sont affichées. La fusion s'est bien passée, la compilation a réussi, les tests ont été validés. Et le client à qui j'essayais de vendre le produit lisait à voix haute le texte de remplacement sur un écran partagé.

J’ai beaucoup repensé à ce moment. Pas à cause de l’embarras, même si je l’avais bien mérité. Mais pour ce qu’il m’a appris sur ce qu’est réellement un environnement de test, qui n’est pas ce que la plupart d’entre nous pensent qu’il est.

Le problème de l’aperçu qui n’a rien à voir avec le code

La plupart des discussions sur les environnements de test s’arrêtent à la question « est-ce que la build fonctionne ? ». Toutes les plateformes axées sur le front-end de ces cinq dernières années ont résolu ça proprement. Pousse une branche, obtiens une URL, partage l’URL, fusionne ou pas. Le chemin du code, ça va.

C'est le chemin des données qui est trompeur.

Sur les plateformes que la plupart d’entre nous utilisons, l’application est mise en branche à chaque push, mais pas la base de données. L’URL de prévisualisation pointe vers des données de staging, ou des données de départ pour le dev, ou un fixture écrit par un collègue pendant sa première semaine et que personne n’a touché depuis. La couche UI se comporte correctement, affichant tout ce qui se trouve dans la table. Le réviseur, en regardant un aperçu, n’a aucun moyen de savoir si la fonctionnalité fonctionne avec des données de production, car l’aperçu n’a jamais vu de données de production.

Le résultat, c'est une catégorie de bugs qui passe la revue et meurt devant un client. Le moment « c'est quoi ce lorem ipsum » est l'une des versions les plus sympas. Les pires, c'est quand des requêtes qui marchaient bien avec une centaine de lignes plantent avec un million, des états de l'interface qui n'existent qu'une fois que l'utilisateur a trois ans d'historique, et des intégrations dont les identifiants sont valides en préproduction mais faux en production.

Pourquoi ce décalage est structurel, et non accidentel

Un environnement de test avec des données factices, c’est comme une maison témoin. Les canapés sont superbes. Les interrupteurs fonctionnent tous. Personne n’y a jamais vécu, ce qui veut dire qu’on ne peut pas savoir si la plomberie tiendra le coup une fois qu’une famille emménagera.

Ce que personne ne te dit : ce n’est pas un bug que l’industrie ignore. C’est un problème que les équipes ont choisi de contourner plutôt que de résoudre.

Tu peux configurer une base de données gérée qui prend en charge la création de branches par prévisualisation. Tu peux écrire un générateur de données de test. Tu peux copier chaque semaine des instantanés de production anonymisés vers l’environnement de préproduction. Beaucoup d’équipes le font, et la plupart du temps, ça marche.

Chacune est une configuration qui réside en dehors de l’application. Chacune est un deuxième système, avec sa propre date d’expiration, ses propres autorisations d’accès, son propre modèle de coûts et sa propre façon de se désynchroniser. Chacune représente du temps que ton équipe passe à se concentrer sur l’infrastructure plutôt que sur les fonctionnalités. 

Les plateformes « frontend-first » qui ont popularisé les aperçus Git-push ont construit ce processus autour du code. Le reste de l’aperçu, les services et les données, réside dans l’intégration que l’équipe a mise en place, généralement via une marketplace ou une action GitHub que quelqu’un a ajoutée au dernier trimestre.

Un réviseur, face à une pull request, doit se poser une question qui ne devrait pas être de son ressort : la base de données de cet aperçu correspond-elle à la configuration réelle, ou s’agit-il simplement de ce que le fixture m’a fourni ?

Ce qu’un environnement de test pourrait signifier à la place

Je gère quelques projets parallèles. Ils sont suffisamment petits pour que chaque choix de plateforme soit un pari sur ce que mon futur moi me remerciera d’avoir fait. La seule chose sur laquelle je ne fais jamais de compromis, c’est la parité des aperçus. Chaque fois que je l’ai fait, mon futur moi s’est retrouvé à fixer du lorem ipsum sur ma propre démo, ce qui est une façon bien humiliante de réviser ses propres pull requests.

Sur Upsun, chaque branche Git reçoit un clone octet par octet de la production. Application, services, données. Ça prend environ une minute. Les bases de données qui tournent dans ton environnement de prévisualisation sont les mêmes que celles en production, avec les mêmes lignes, les mêmes index, les mêmes clés étrangères, tout est identique. Si tu ne veux pas que les relecteurs voient les données clients, tu définis un hook de nettoyage dans ton .upsun/config.yaml qui supprime les informations personnelles lors du déploiement, et les relecteurs obtiennent des données réalistes mais non sensibles.

Ce n’est pas une intégration de marketplace que tu configures par projet. C’est ainsi que fonctionnent les environnements.

Le terme pour cela est « clonage d'environnement octet par octet ». Ce n'est pas l'expression la plus accrocheuse. Ce que cela permet en réalité, c'est qu'un réviseur puisse répondre « est-ce que ça marche ? » sans avoir à deviner.

Ce qui change au quotidien

Je parle à des clients chaque semaine et je déploie du code sur des projets parallèles avec le même processus. Deux métiers différents, le même schéma vu sous des angles différents.

Du côté client, l’aperçu cesse d’être l’endroit où les bugs se cachent jusqu’à la démo. Les réviseurs repèrent la requête qui ne sera pas évolutive. Les chefs de produit cliquent sur la fonctionnalité et remarquent que le langage de l’état vide est incorrect, car ils voient de véritables états vides. Les ingénieurs commerciaux lancent la démo sur le clone et rien n’affiche de texte factice.

Du côté de la livraison, le bouton « fusionner » commence à signifier ce qu’il dit. Quand j’approuve une pull request sur un clone de production, j’approuve un comportement par rapport à la structure de données réelle que mes utilisateurs vont rencontrer. La catégorie des bugs « validés en révision, mais qui plantent en production » devient plus petite. Pas nulle. Plus petite, et dans une catégorie sur laquelle tu peux raisonner.

C'est un petit changement dans le processus et un grand changement dans la confiance que tu as en ton propre pipeline.

Une question, et un aveu

Passe en revue tes trois derniers incidents de production. Combien d’entre eux étaient visibles dans l’environnement de test où la modification a été révisée ? Si la réponse est « aucun », et que tu en es sûr, ton environnement de test fait son travail. Si la réponse est « je ne sais pas », le chemin des données en est probablement la raison.

Le client qui m’a demandé ce qu’était le lorem ipsum est toujours un client. Il s’est montré aimable, comme le sont généralement les gens quand tu viens de te faire prendre en flagrant délit devant eux. Ce qu’il demandait en réalité, je pense, c’est « pourquoi est-ce que je regarde quelque chose qui n’est pas réel ? » C’est la bonne question à poser à n’importe quel environnement de test. Le tien devrait pouvoir y répondre sans que tu aies à plisser les yeux.

Lectures complémentaires

• Environnements Upsun et clonage
• Clone de production en 45 secondes avec toutes les données et tous les services