Datos semilla y fixtures para bases de datos locales: pequeños, idempotentes y versionados junto con el esquema

Objetivo

Que cualquier persona que desarrolla, cualquier agente y cualquier tarea de integración continua pueda crear una base de datos local con datos suficientemente realistas y consistentes para ejecutar la aplicación y sus tests, con un solo comando, en segundos, sin una copia de producción.

Requisitos previos

Migraciones de esquema bajo control de versiones y una base de datos local que pueda eliminarse y recrearse libremente (un contenedor es suficiente; véase el artículo relacionado sobre bases de datos efímeras). Una clasificación de las tablas en datos de referencia (países, roles, planes), datos de ejemplo (algunos usuarios, pedidos, documentos) e historial extenso que el trabajo local no necesita.

Pasos

1. Separar los tres tipos. Los datos de referencia van junto con las migraciones o con un paso de siembra que se ejecuta en todos los entornos, incluida producción. Los datos de ejemplo son para desarrollo y demostraciones. Las filas específicas de los tests se crean dentro de los propios tests mediante builders o fixtures, nunca en la siembra global.
2. Escribir la siembra como código idempotente. La guía de Rails dice de db/seeds.rb que el código debería ser idempotente, de modo que pueda ejecutarse en cualquier momento y en todos los entornos; usar upserts basados en identificadores naturales (email, slug), no simples inserciones.
3. Mantener el conjunto de ejemplo pequeño y con nombres reconocibles: un puñado de usuarios con credenciales conocidas y un registro en cada estado interesante (un pedido pagado, uno reembolsado, una cuenta suspendida). Enumerar los nombres en el README, de modo que "iniciar sesión como alice@example.test" sea un punto de partida conocido.
4. Usar el formato que admite la pila tecnológica: loaddata de Django lee los archivos de fixture que produce dumpdata; otras pilas usan archivos SQL, CSV con COPY, o un script en el lenguaje de la aplicación. Preferir el lenguaje de la aplicación cuando las filas deben pasar validaciones y hooks.
5. Si se necesita un volumen realista, volcar producción con pg_dump --exclude-table-data para las tablas sensibles o enormes, anonimizar el resto en un paso separado, y almacenar el resultado fuera del repositorio con una fecha de caducidad. No sembrar nunca las máquinas de desarrollo con datos de producción sin anonimizar.
6. Integrar la siembra en el script de configuración y en el paso de base de datos de la integración continua, después de las migraciones en ambos casos; así, una siembra rota por una columna nueva se detecta el mismo día.
7. Incluir la siembra en la revisión cada vez que cambia el esquema: una migración que añade una columna obligatoria también actualiza la siembra.

Resultado esperado

Una sola tarea elimina, migra y siembra la base de datos; dos máquinas sembradas a partir del mismo commit contienen datos de ejemplo idénticos, y los tests no dependen de filas que no crearon ellos mismos.

Límites y base de verificación

La siembra sustituye a la base de datos vacía, no a los builders de datos de prueba. Los identificadores generados difieren entre ejecuciones a menos que la siembra los fije de forma explícita. La anonimización es una disciplina en sí misma y no se trata aquí. Los pasos son una síntesis de la documentación citada; no se afirma ninguna medición de tiempos.