Un entorno de pruebas con datos generados gana a una copia de producción

Hay un momento en la vida de todo equipo pequeño en el que alguien propone apuntar el desarrollo local a una copia de la base de datos de producción, porque los datos falsos se ven flojos y los fallos de verdad solo pasan con registros de verdad. Es una idea tentadora con una larga cola de arrepentimiento: credenciales repartidas por los portátiles, nombres de clientes en las capturas, un proceso de correo de prueba que un día se encuentra direcciones reales. Nosotros fuimos por el otro camino y no nos hemos arrepentido.

Un Postgres entero dentro del proceso

Las versiones embebidas de Postgres se han puesto realmente bien. Nuestra aplicación decide al arrancar: si hay credenciales reales de base de datos en el entorno, usa la base de datos alojada; si están en blanco, levanta un Postgres en el propio proceso que vive en una carpeta local. Las máquinas de desarrollo simplemente nunca tienen las credenciales, así que el peor caso de un portátil mal configurado es una base de datos vacía y recién hecha, no un incidente en producción.

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}

La forma de reconstruirla importa tanto como el motor. Recreamos la base de datos local aplicando los mismos ficheros de migración que ejecutó producción, en orden y desde el primero. Esa sola decisión nos ha cazado gratis toda una familia de fallos: una migración que daba por hecha una columna de un fichero posterior, un cambio de esquema que funcionaba contra una copia antigua pero no desde cero. Si el portátil no puede construir el esquema desde el historial, el siguiente despliegue tampoco habría podido.

Genera un negocio, no filas

La diferencia entre unos datos falsos inútiles y unos útiles es que cuenten algo. Nuestro script no inserta diez usuarios llamados test. Crea un salón con nombre, personal con especialidades, servicios con precios y duraciones creíbles, clientes con historial de visitas, citas próximas y productos de venta con existencias y un libro de movimientos detrás. Las páginas se ven habitadas, y eso hace que los fallos de maquetación, los estados vacíos y los recortes de texto raros aparezcan igual que le aparecerían a un cliente real.

Esa última propiedad es fácil de infravalorar. Todas las capturas de nuestra documentación, de nuestro blog y de nuestros informes de fallos salen del entorno con datos generados. Nadie tiene que forzar la vista sobre una imagen preguntándose si se ha colado el nombre de un cliente, porque no hay nombres de clientes que se puedan colar. El proceso de anonimizado más seguro es no tener nada que anonimizar.

Qué hay que hacer bien

• Que el camino seguro sea el camino por defecto. Un desarrollador debería tener que desviarse para llegar a los datos reales, no para evitarlos.
• Neutraliza también los efectos secundarios: las claves de correo, de pagos y de almacenamiento se quedan en blanco en local, así que un bucle sobre clientes generados nunca puede escribir a una persona real.
• Genera los estados que te dan miedo: la cuenta recién creada, el día completo, el producto agotado, el cliente con una sola visita hace años.
• Mantén el script en las revisiones de código. Cuando una funcionalidad añade una tabla, el script crece con ella o el entorno se pudre en silencio.

El beneficio se acumula. Los compañeros nuevos ejecutan dos comandos y tienen un negocio funcionando con el que trastear. La revisión visual puede fotografiar todas las páginas sin pasar por una revisión de privacidad. Y el entorno de demostración está siempre a cinco minutos de estar impecable, porque estar impecable es solo reconstruirlo.

Los datos de producción responden preguntas. Los datos generados te dejan hacerlas sin riesgo.