Un bac à sable garni vaut mieux qu'une copie de la production

Il y a un moment dans la vie de chaque petite équipe où quelqu'un propose de faire pointer le développement local sur une copie de la base de production, parce que les fausses données paraissent maigres et que les vrais bugs ne se produisent qu'avec de vrais enregistrements. C'est une idée tentante avec une longue traîne de regrets : des identifiants qui se répandent sur les portables, des noms de clients dans les captures d'écran, une tâche d'e-mails de test qui trouve un jour de vraies adresses. Nous avons pris l'autre chemin et nous ne sommes jamais revenus en arrière.

Un Postgres entier dans le processus

Les versions embarquées de Postgres sont devenues vraiment bonnes. Notre application décide au démarrage : s'il existe de vrais identifiants de base dans l'environnement, elle utilise la base hébergée ; s'ils sont vides, elle lance un Postgres dans le processus, stocké dans un dossier local. Les machines de développement n'ont tout simplement jamais les identifiants, si bien que le pire scénario d'un portable mal configuré est une base vide toute neuve, et non un incident de production.

1// Choose the database at runtime. Blank env = embedded, local, harmless.2function makeDb() {3  const url = process.env.DATABASE_URL;4  if (url) return connectHosted(url);5  // In-process Postgres persisted to a local folder6  const client = new EmbeddedPostgres('./.pgdata');7  return drizzle(client, { schema });8}

Le chemin de reconstruction compte autant que le moteur. Nous recréons la base locale en appliquant les mêmes fichiers de migration que la production a joués, dans l'ordre, depuis le premier. Cette seule décision a attrapé gratuitement toute une famille de bugs : une migration qui supposait une colonne venant d'un fichier plus tardif, un changement de schéma qui marchait sur un instantané périmé mais pas depuis zéro. Si le portable n'arrive pas à construire le schéma depuis l'historique, le prochain déploiement n'y arriverait pas non plus.

Garnissez une activité, pas des lignes

Ce qui sépare de fausses données inutiles de fausses données utiles, c'est le récit. Notre script de remplissage n'insère pas dix utilisateurs appelés test. Il crée un salon avec un nom, une équipe avec ses spécialités, des prestations avec des prix et des durées honnêtes, des clients avec un historique de visites, des rendez-vous à venir, des produits en rayon avec leurs niveaux de stock et un journal derrière eux. Les pages ont l'air habitées, ce qui veut dire que les bugs de mise en page, les états vides et les troncatures maladroites apparaissent comme ils apparaîtraient pour un vrai client.

Cette dernière propriété est facile à sous-estimer. Chaque capture d'écran de notre documentation, de notre blog et de nos rapports de bug vient du bac à sable garni. Personne n'a à plisser les yeux devant une image en se demandant si un nom de client s'y est glissé, parce qu'il n'y a aucun nom de client à glisser. Le processus d'anonymisation le plus sûr, c'est de n'avoir rien à anonymiser.

Ce qu'il faut réussir

• Faites du chemin sûr le chemin par défaut. Les développeurs devraient avoir à faire un détour pour atteindre les vraies données, et non pour les éviter.
• Neutralisez aussi les effets de bord : les clés d'e-mail, de paiement et de stockage restent vides en local, si bien qu'une boucle sur les clients de test ne peut jamais écrire à une vraie personne.
• Garnissez les états que vous redoutez : le compte tout neuf, la journée complète, le produit en rupture, le client venu une seule fois il y a des années.
• Gardez le script de remplissage dans la relecture de code. Quand une fonctionnalité ajoute une table, le script grandit avec elle, sinon le bac à sable pourrit en silence.

Le bénéfice se cumule. Les nouveaux arrivants lancent deux commandes et disposent d'une activité qui tourne, avec de quoi fouiller. Le contrôle visuel peut photographier chaque page sans revue de confidentialité. Et l'environnement de démonstration est toujours à cinq minutes d'être impeccable, parce qu'impeccable n'est qu'une reconstruction plus loin.

Les données de production répondent aux questions. Les données de test permettent de les poser sans risque.