Les avantages des environnements de test avec des données de production

Avant de rejoindre Upsun, Andrew Kester a fait capoter la plus grosse vente de l'année d'un client.

Il faisait partie des deux ou trois développeurs web d’une agence créative spécialisée dans l’image de marque, les logos, l’impression et les sites web. Une boutique de design s’apprêtait à organiser son défilé annuel, et les réductions ainsi que les fonctionnalités mises en avant devaient rester secrètes jusqu’à la révélation prévue mardi à midi. Le client a demandé un aperçu. Cet aperçu a été publié en production. Ce genre d’incident justifie l’existence d’environnements de test contenant des données de production, et explique pourquoi les mécanismes de clonage d’environnement sont plus importants qu’il n’y paraît.

« La page d’accueil de leur site web devait dévoiler la grande surprise, et ça s’est produit avec environ deux jours d’avance », raconte Kester, aujourd’hui ingénieur senior en support cloud chez Upsun. « On avait déployé le mauvais environnement, ou je ne me souviens plus exactement de ce qui s’est passé, mais une base de données s’est retrouvée mélangée quelque part. C’était le bazar. »

Andrew raconte cette histoire dans le dernier épisode de « Product Highlights ». Depuis, il a passé des années de l’autre côté, au sein d’une équipe d’assistance disponible 24 heures sur 24, tous les jours de l’année, avec des ingénieurs en Amérique du Nord, en Amérique du Sud, en Europe, au Japon et en Australie. 

Les tickets vont des questions sur les produits aux sites en train de subir des attaques de la part d’acteurs malveillants. Il a vu ce qui peut mal tourner à grande échelle, ce qui fait de sa fonctionnalité préférée de la plateforme un choix révélateur : le bouton qui clone un environnement.

Ce que faisaient les agences avant le clonage d’environnement

Le schéma décrit par Andrew sera familier à tous ceux qui ont déjà créé des sites pour des clients. Un client veut une nouvelle page, une nouvelle fonctionnalité, un nouveau bon de réduction. Il veut voir le résultat avant la mise en ligne. Rien dans la stack technique n’était conçu pour lui permettre de le faire.

« L’un des plus gros défis auxquels on se heurtait toujours, c’était d’avoir un client qui voulait un nouveau site, une nouvelle fonctionnalité, une nouvelle page, un nouveau bon de réduction, peu importe, et de pouvoir lui montrer ça sans affecter son site de production », explique-t-il.

L’agence a donc improvisé. Copier l’environnement à la main en espérant que la copie soit assez fidèle. Ou déployer le nouveau code en production derrière une vérification par mot de passe en espérant que ça tienne le coup. Le verdict d’Andrew sur cette deuxième approche est sans appel : si tout s’alignait et que le client avait le bon mot de passe, la partie cachée du site s’affichait, « mais ce n’était jamais vraiment fiable ».

Ces deux approches échouent pour la même raison. Un environnement copié à la main n’est qu’une supposition par rapport à la production, et un « feature flag » en production, ça reste de la production. Aucune des deux ne t’offre un espace où tu peux te tromper sans conséquence.

Ce qui est réellement cloné

Sur Upsun Cloud™, un nouvel environnement correspond à une opération de branche plutôt qu’à une reconstruction. Pousse une branche, exécute `upsun branch` ou ouvre une pull request, et par défaut, le nouvel environnement hérite des données et des services de son parent, y compris les bases de données, le stockage réseau, les files d’attente et la configuration de routage.

Si tu veux le code sans les données, effectue un push avec environment.clone_parent_on_create=False.

Upsun attribue la rapidité de la copie aux instantanés « copy-on-write », ce qui fait du clonage une opération courante plutôt qu’une tâche à planifier.

Le résumé d’Andrew sur l’expérience développeur tient en trois phrases.

« Tu cliques sur un bouton. On clone tes services. On clone les données. »

C’est justement la partie « données » qui distingue cette fonctionnalité des liens d’aperçu que la plupart des équipes ont utilisés jusqu’à présent. Un aperçu statique du front-end ne t’apprend pas grand-chose sur un site géré par contenu. Comme le souligne Andrew, les applications comme WordPress, ou les sites ExpressionEngine gérés par son agence, comportent une base de données remplie d’états d’initialisation : configuration, types de contenu, relations, la structure accumulée d’une véritable installation. Une base de données vide n’est pas une version réduite de tout ça. C’est une application différente.

Les intégrations de source étendent ce même comportement à la révision de code. Lorsque l’intégration GitHub ou GitLab est activée, l’option « build-pull-requests » est activée par défaut : ainsi, l’ouverture d’une pull request crée un environnement de production lié à la branche cible. De même, l’option « pull-requests-clone-parent-data » est activée par défaut, ce qui fait que cet environnement est créé avec les données du parent déjà en place. 

Les pull requests en brouillon sont incluses, sauf si tu les désactives. Les relecteurs reçoivent une URL au lieu d’un checkout, ce qui fait toute la différence entre relire du code et relire une modification. C’est aussi ce qui élimine la file d’attente pour un serveur de staging partagé, un problème qui mérite un débat à part entière.

L’isolation, c’est ce qui te permet de casser des trucs

La parité avec la production ne représente que la moitié de l’intérêt. L’autre moitié, c’est que rien de ce que tu fais dans le clone ne peut revenir en arrière.

« Toutes les modifications du code, toutes les modifications de la base de données sont isolées, donc il n’y a aucun risque », explique Andrew. « Si je modifie quelque chose, je ne vais pas le repousser accidentellement vers la production. »

Upsun présente ça comme une propriété de la plateforme plutôt que comme une pratique que les équipes doivent maintenir : les environnements sont entièrement isolés par défaut, et rien ne passe d’un environnement à l’autre à moins que tu ne le demandes. La commande « sync » récupère le code ou les données depuis l’environnement parent. La commande « merge » envoie le code vers l’environnement de production. Ce sont deux commandes que tu exécutes délibérément, et c’est justement le but.

Cette garantie change ce qu’un développeur est prêt à tenter. Andrew reprend l’ancien adage tel quel, puis le corrige. «Move fast and break things» ne marche pas quand le seul endroit où agir, c’est la production, parce que la prudence augmente proportionnellement aux conséquences et que tu finis par avancer à pas de loup à chaque déploiement. Donne au même développeur une copie jetable, et le calcul s’inverse.

« Si tu casses toute la base de données et que tu la tronques, on s’en fiche ! En crée une nouvelle. Il suffit de la recopier. C’est une seule commande. »

Une migration destructive que tu veux observer une fois avant de lui faire confiance ne coûte pas cher quand son rayon d’action se limite à une branche.

Pourquoi les agents de codage IA ont besoin de la même garantie

La rentabilité d’une copie de production jetable a encore changé, car les développeurs ne sont plus les seuls à en demander une.

Greg Qualls, directeur du marketing produit chez Upsun, explique que les clients souhaitent de plus en plus qu’un agent « teste sur de vraies données de production sans interagir avec l’environnement de production ».

Ces deux exigences doivent être satisfaites simultanément. Un agent travaillant à partir d’un bac à sable vide bénéficie d’une isolation matérielle, mais n’a aucun contexte. Il ne peut pas valider de manière fiable un plan de requête, confirmer qu’une migration est terminée, ni remarquer qu’une modification provoque une rupture sur le seul type de contenu qui n’existe que dans le jeu de données réel. Upsun a plaidé en faveur des environnements de test avec état précisément sur ce point : les environnements de test éphémères isolent la puissance de calcul, mais manquent généralement des données calquées sur la production dont un agent a besoin pour vérifier son propre travail.

L’isolation est plus importante pour un agent que pour une personne, car les modes de défaillance sont moins prévisibles. Une commande destructrice erronée ou une boucle incontrôlable sont des événements très différents dans un environnement de test par rapport à la production. Donner à un agent une branche plutôt que des identifiants de production, c’est le processus « proposer et tester » que défend Upsun, et ça marche parce que la branche est suffisamment réelle pour prouver quelque chose et suffisamment jetable pour que ça n’ait pas d’importance.

Ce que couvre le « safe by default », et ce qu’il ne couvre pas

Il y a deux détails à connaître avant de partager une URL de prévisualisation avec un client.

Les moteurs de recherche sont gérés pour toi. Les environnements de test sans domaine personnalisé sont toujours masqués aux moteurs de recherche, et ce comportement ne peut pas être modifié. Les environnements de test avec un domaine personnalisé sont masqués par défaut, et tu peux choisir de les rendre visibles.

L’accès humain n’est pas géré pour toi. Un environnement de test est accessible à toute personne disposant de l’URL jusqu’à ce que tu configures le contrôle d’accès HTTP, qui te permet d’utiliser soit des paires nom d’utilisateur/mot de passe, soit une liste d’adresses IP autorisées/refusées en notation CIDR, définie dans la console Upsun ou via upsun environment:http-access.

Les environnements enfants héritent des paramètres du parent, mais un environnement existant doit être redéployé pour que la modification soit prise en compte — il faut donc configurer le parent avant de commencer à partager des liens. Pour les équipes qui clonent des ensembles de données sensibles, les hooks de déploiement sont l’endroit idéal pour nettoyer ou anonymiser les données dans le cadre du clonage.

L’incident du défilé d’Andrew était dû à une défaillance du processus, pas à un problème d’autorisations. La solution n’a jamais été de changer de mot de passe. Il s’agissait d’un espace où stocker des travaux non publiés qui n’étaient pas en production, mais qui ressemblaient suffisamment à la production pour mériter d’être montrés à un client.

Cet espace, c’est désormais un bouton. Découvre-en plus sur les environnements de développement instantanés sur Upsun Cloud, ou consulte la documentation sur les environnements pour comprendre comment la création de branches, la synchronisation et la fusion s’articulent entre elles.