Qu'est-ce qu'un environnement de staging ? La copie qui n'en est jamais tout à fait une

Un environnement de staging est une copie en fonctionnement de votre application, aussi proche de la production que vous pouvez vous le permettre, où une version est vérifiée avant que de vraies personnes la rencontrent. Le même code, la même forme de configuration, la même structure de base de données, d’autres données et un autre public.

L’idée est ancienne et simple : essayez d’abord là où cela n’a pas d’importance. Ce qui la rend intéressante, c’est que le staging n’est jamais vraiment une copie, et chaque problème qu’il laisse passer vient de cet écart.

Entre quoi il se situe

La plupart des équipes finissent avec trois ou quatre environnements, et les différences portent sur qui a le droit de les casser.

• Local est la machine d’un développeur. Elle casse en permanence, et cela ne dérange personne.
• Le staging exécute le code sur le point de partir, avec des données qui ne manqueront à personne. Il casse de temps en temps, et cela dérange un peu quelqu’un.
• La production est là où sont les clients.

Certaines équipes ajoutent un quatrième entre le staging et la production pour les tests de charge ou d’intégration, et d’autres placent un environnement de prévisualisation par branche avant le staging. Les noms varient plus que les idées.

À quoi il sert

Attraper ce qu’une suite de tests ne peut pas. Des migrations sur une base de données au volume réel. Des assets qui ne sont compilés que pendant un déploiement. Une valeur de configuration qui existe sur une machine et pas sur une autre. Aucun test unitaire ne touche à tout cela.

Répéter le déploiement lui-même. Une mise en production est une procédure, et la procédure a aussi ses bogues. Si déployer sur le staging est la même commande que déployer en production, vous avez répété ce qui serait sinon fait pour la première fois au pire moment.

Donner aux non-développeurs un endroit où regarder. La recette, une démonstration, une copie d’écran pour le support - tous ont besoin d’un endroit réel qui ne soit pas réel.

Comment le staging dérive

C’est la partie qui mérite d’être écrite, car un environnement de staging que personne n’entretient est pire que rien : il produit de la confiance plutôt que de l’information.

Le code dérive. Tout ce qui est fusionné part automatiquement sur le staging ; la production est déployée quand quelqu’un le décide. Un staging en avance de trente commits sur la production vous parle d’un logiciel que vos clients n’ont pas, et le bogue que vous n’arrivez pas à reproduire sur le staging y est peut-être simplement déjà corrigé.

Les données dérivent. La production accumule quinze ans de décisions - des comptes sans adresse e-mail, une commande antérieure à l’existence d’une colonne, un nom avec une apostrophe. Le staging a ce que les seeds y ont mis. La plupart des défauts qui atteignent les clients vivent dans des formes de données que personne n’a pensé à créer.

La configuration dérive. Une clé définie sur un hôte et pas sur l’autre, un feature flag activé à un seul endroit, un service tiers pointé vers un bac à sable qui se comporte autrement que le vrai. C’est la classe de problème pour laquelle le staging existe et celle qu’il provoque le plus souvent.

L’échelle dérive. Un processus web contre douze, une base de données de mille lignes contre dix millions. Une requête instantanée sur le staging peut être la raison pour laquelle la production tombe.

Garder l’écart honnête

Vous ne pouvez pas combler l’écart, l’objectif est donc de savoir où il se trouve.

• Déployez de la même façon sur les deux. Une commande, un script, aucune étape manuelle qui n’existe qu’à un seul endroit. Si la production a une étape que le staging n’a pas, cette étape n’a jamais été testée.
• Déployez-les ensemble quand un changement couvre les deux. Tout ce qui a un client - une extension de navigateur, une application mobile, une intégration partenaire - qui parle à un environnement et pas à l’autre n’est en ligne sur aucun des deux, du point de vue de la personne qui teste.
• Utilisez des données à la forme de la production, pas les données de production. Anonymisées ou générées, avec les formes gênantes délibérément incluses : le compte vide, la liste énorme, l’apostrophe. Copier de vraies données clients dans un environnement moins gardé est un incident de confidentialité qui attend sa date.
• Gardez-le éteint quand il ne sert pas, et attendez-vous à ce qu’il soit une cible : les environnements de staging sont réputés moins corrigés et plus ouverts que les systèmes qu’ils reflètent.
• Dites lequel est lequel. Une bannière, une couleur, n’importe quoi. Quelqu’un finira par faire une démonstration sur la production ou un test destructeur sur le mauvais hôte, et l’empêcher coûte une ligne de CSS.

Quand le staging dit une chose et la production une autre

Ce n’est pas un échec du staging, c’est l’information que le staging existe pour vous donner, et c’est le moment de découvrir laquelle des quatre dérives ci-dessus l’explique.

La première question est de savoir quel build chacun exécute. La seconde est de savoir si la même chose se produit avec les mêmes données. Ce sont deux choses qu’un rapport devrait dire, et deux détails qui manquent régulièrement à « ça marche sur le staging ».

Une capture depuis chaque environnement transforme une dispute en comparaison : les mêmes étapes, deux jeux de sortie console et de journaux réseau, et le plus souvent une différence évidente. Le guide du rapport de bogue contient le reste de ce qu’il faut y mettre, et nommer l’environnement est la ligne que l’on oublie.

La version courte

Le staging est une répétition, pas une copie. Sa valeur est proportionnelle à l’honnêteté avec laquelle vous suivez ce par quoi il diffère de la production - le code, les données, la configuration et l’échelle - et une différence que vous connaissez est une limite, tandis qu’une différence oubliée est un faux négatif déguisé en coche verte.