Versiones que protegen tus datos antes de arrancar

Publicamos a menudo, a veces varias veces al día. La mayoría de las versiones solo cambian código, pero algunas también cambian la base de datos: una tabla nueva para una función nueva, un campo nuevo en un vídeo.

La promesa detrás de cada una cabe en una frase. Nada de lo que has creado debe depender de que una versión salga bien. Si una versión nueva tiene un problema, la anterior debe seguir atendiéndote, y tus datos quedarse exactamente como estaban.

Cuando arranca una nueva versión de PageToVid, antes de servir una sola página, pone al día la base de datos con Prisma, la herramienta que describe nuestras tablas. Ese paso lo ejecutamos a propósito sin la opción que acepta perder datos.

Si un cambio fuera a borrar una columna, convertir un campo de forma que pueda perder valores o poner en riesgo filas existentes de cualquier otro modo, el paso se niega. La versión nueva se detiene antes de recibir tráfico, y Cloud Run, que ejecuta nuestros servidores, mantiene la versión anterior en marcha como si nada.

Así, cada cambio en la base sigue una sola regla, solo añadir:

• tablas nuevas
• campos nuevos opcionales
• campos nuevos con un valor por defecto

Todo lo demás espera en la puerta hasta que cambie de forma.

Esta versión traía enlaces cortos y legibles que cada persona puede elegir, y dos personas nunca deben tener el mismo. La forma natural de escribirlo: un campo nuevo en la tabla de cuentas existente, marcado como único.

El campo era nuevo y estaba vacío. Parecía inofensivo. Pero una regla de unicidad nueva en una tabla que ya tiene filas cuenta como una posible pérdida, porque la base no puede garantizar de antemano que no haya dos filas en conflicto. Así que el control de la puerta hizo justo su trabajo: la versión que la llevaba esperó, la anterior siguió en marcha y nadie que estuviera haciendo un vídeo notó nada.

Nuestras pruebas no podían verlo. Construyen cada vez una base nueva y vacía, y en una tabla vacía da igual que el campo único esté en una tabla nueva o en una existente. La diferencia solo existe donde viven los datos reales, justo donde está la guardia.

La respuesta rápida habría sido activar la opción que acepta la pérdida y publicar. Hicimos lo contrario. Cambiamos la forma de los datos para que pasaran el control con honestidad.

Una regla creada junto con una tabla nueva es segura, porque una tabla nueva no tiene filas en conflicto. Así que la unicidad de esos enlaces pasó a una pequeña tabla propia, con el enlace como clave y una fila por persona. La cuenta guarda una copia simple para mostrarla, sin ninguna regla.

El cambio pasó a ser puramente aditivo. Lo comprobamos contra la base en producción antes de publicar, y la función salió ese mismo día.

La lección es ya parte de cómo publicamos. Antes de que salga cualquier cambio en la base de datos, lo comparamos con el esquema que está funcionando de verdad, no con la copia de un desarrollador:

1. 1tomar el esquema de la versión que está en línea, y el nuevo
2. 2pedirle a Prisma las instrucciones exactas que ejecutaría entre ambos
3. 3leerlas: solo tablas nuevas, campos opcionales o con valor por defecto, y reglas de unicidad en tablas nuevas
4. 4hacer una copia de seguridad reciente antes de publicar

Lo que nunca debe aparecer en una tabla existente: una regla de unicidad nueva, un campo obligatorio sin valor por defecto, un cambio de nombre o una eliminación. Cada uno tiene una forma segura conocida, casi siempre una tabla nueva.

No ves nada de esto, y esa es la idea. Una versión que no está lista simplemente no arranca, la que usas sigue funcionando, y tus proyectos y vídeos quedan exactamente como los dejaste.

Una versión que espera en la puerta es un pequeño retraso para nosotros. Un campo desaparecido sería una pérdida para ti. Elegimos el trato que protege tu trabajo. Más historias sobre cómo se construye PageToVid en el blog.