Données d'amorçage et fixtures pour bases de données locales : petites, idempotentes et versionnées avec le schéma

Objectif

Permettre à chaque développeur, agent et job d'intégration continue de créer une base de données locale avec suffisamment de données réalistes et cohérentes pour exécuter l'application et ses tests, à partir d'une seule commande, en quelques secondes, sans copie de la production.

Prérequis

Des migrations de schéma sous contrôle de version et une base de données locale qui peut être détruite et recréée librement (un conteneur convient ; voir l'article associé sur les bases de données éphémères). Une classification des tables en données de référence (pays, rôles, formules), données d'exemple (quelques utilisateurs, commandes, documents) et historique volumineux dont le travail local n'a pas besoin.

Étapes

1. Séparer les trois catégories. Les données de référence vont avec les migrations ou une étape d'amorçage qui s'exécute dans chaque environnement, y compris en production. Les données d'exemple sont destinées au développement et aux démonstrations. Les lignes propres à un test sont créées à l'intérieur des tests par des builders ou des fixtures, jamais par l'amorçage global.
2. Écrire l'amorçage comme du code idempotent. Le guide Rails indique à propos de db/seeds.rb que le code doit être idempotent afin de pouvoir être exécuté à tout moment dans chaque environnement ; utiliser des upserts indexés sur des identifiants naturels (email, slug), pas de simples insertions.
3. Garder le jeu d'exemples petit et nommé : une poignée d'utilisateurs avec des identifiants connus et un enregistrement dans chaque état intéressant (une commande payée, une remboursée, un compte suspendu). Lister les noms dans le README afin que « se connecter en tant que alice@example.test » soit un point de départ connu.
4. Utiliser le format que la pile technique prend en charge : loaddata de Django lit des fichiers de fixtures que dumpdata produit ; d'autres piles utilisent des fichiers SQL, du CSV avec COPY, ou un script dans le langage de l'application. Préférer le langage de l'application lorsque les lignes doivent passer par des validations et des hooks.
5. Si un volume réaliste est nécessaire, extraire la production avec pg_dump --exclude-table-data pour les tables sensibles ou volumineuses, anonymiser le reste dans une étape distincte, et stocker le résultat hors du dépôt avec une date d'expiration. Ne jamais amorcer les machines de développement à partir de données de production brutes.
6. Intégrer l'amorçage dans le script d'installation et dans l'étape de base de données de l'intégration continue, après les migrations dans les deux cas ; un amorçage cassé par une nouvelle colonne est ainsi détecté le jour même.
7. Faire de l'amorçage un élément de la revue à chaque changement de schéma : une migration qui ajoute une colonne obligatoire met aussi à jour l'amorçage.

Résultat attendu

Une seule tâche détruit, migre et amorce ; deux machines amorcées à partir du même commit détiennent des données d'exemple identiques, et les tests ne dépendent pas de lignes qu'ils n'ont pas créées eux-mêmes.

Limites et base de vérification

Les amorçages remplacent la base de données vide, pas les builders de données de test. Les identifiants générés diffèrent d'une exécution à l'autre à moins que l'amorçage ne les fixe explicitement. L'anonymisation est une discipline à part entière et n'est pas couverte ici. Les étapes sont une synthèse de la documentation citée ; aucune revendication de temps n'est faite.