Preparar una versión de software con cambio de base de datos

Una versión de software puede cambiar a la vez la aplicación y la base de datos. El retorno debe considerar más que la versión anterior del programa. Registre qué combinación de código, configuración y estructura de datos funciona junta.

El ejemplo hipotético de portal siguiente es una prueba planificada. No describe un cambio en una base real de cliente.

Pruebe el retorno con el mismo estado de datos

La aplicación actual V1 lee nombres de cliente de customer_name. La nueva aplicación V2 debe leer display_name. En el plan inicial se elimina la columna antigua. Después, la aplicación nueva no arranca porque falta configuración.

Volver a desplegar el código anterior no revierte la estructura. Un botón de reversión en la herramienta no resuelve por sí solo esta incompatibilidad.

Planifique una transición compatible

Una alternativa es avanzar por etapas: conservar primero la columna antigua y añadir la nueva. Los valores existentes se trasladan de forma trazable. El equipo define qué campo es la referencia y cómo mantener coherentes los cambios durante la transición.

En un entorno separado se prueban ambas versiones con ese estado intermedio. Incluya cambiar un nombre y leerlo correctamente desde las dos versiones. Una copia única no basta si los valores posteriores se escriben en un solo campo.

Solo después de confirmar la transición y dejar de necesitar la versión antigua para volver se planifica eliminar el campo anterior. Eso cambia otra vez qué versiones antiguas siguen siendo utilizables. El paso requiere su propia decisión.

Considere los datos posteriores al cambio

Una copia antigua puede contener la estructura anterior. Si se han aceptado nuevos pedidos, quizá no estén en esa copia. Restaurarla no debe descartar esas operaciones sin advertirlo. Qué datos llegan después y cómo conciliarlos forma parte del plan de recuperación.

Según el cambio, una ventana de mantenimiento o una corrección específica de la nueva versión puede resultar más adecuada. La transición gradual no promete de forma general una actualización sin interrupciones.

Registre el resultado del ensayo

Documente versión probada, configuración, estado de datos y quién decide si algo falla. En pruebas, siga un pedido hasta su confirmación en destino y ensaye después el retorno previsto. Anote qué datos se conservan y qué limitaciones hay.

Así podrá ver antes del cambio en producción si el retorno previsto encaja realmente con la aplicación y sus datos.

Fuentes

• Prisma — Expand-and-contract migrations

• GitLab — Environments