Cambios de esquema de base de datos sin interrumpir servicio

Despliega primero un esquema compatible

En una aplicación con varias instancias, no siempre se puede detener todo el servicio para cambiar el esquema y el código a la vez. El patrón expand-contract separa la transición en fases: primero se amplía el esquema de forma compatible; luego se migra el uso de la aplicación; por último se retiran los elementos antiguos cuando ya no tienen consumidores.

La documentación de EF Core sobre aplicación de migraciones recomienda inspeccionar y probar las migraciones antes de producción; los scripts SQL permiten revisión cuando el proceso lo requiere. El patrón de abajo es una estrategia de diseño, no una garantía de cero interrupción: bloqueos, volumen, motor de base de datos y consultas deben probarse con datos representativos.

Secuencia expand-contract

1. Expandir: añade una columna o tabla nueva sin eliminar todavía la anterior. Usa valores por defecto y nulabilidad de forma compatible con el código actualmente desplegado.
2. Desplegar lectores compatibles: publica una versión que pueda trabajar con el esquema anterior y el nuevo. Si hay doble escritura temporal, define qué lado es la fuente de verdad y cómo detectar divergencias.
3. Migrar datos: rellena los nuevos campos por lotes, con límites de carga, progreso observable, idempotencia y una consulta de reconciliación.
4. Cambiar el uso: activa la lectura del nuevo formato por etapas. Verifica errores, latencia y consistencia antes de dejar de escribir el formato antiguo.
5. Contraer: tras confirmar que no quedan versiones antiguas ni consumidores, elimina la columna o ruta anterior en un cambio separado y revisado.

Puerta de aprobación para cada fase

Antes de aplicar el cambio, revisa el SQL generado, duración estimada, índices, bloqueos, tamaño de lote y comportamiento con versiones N y N-1. Prueba restauración o reversión de aplicación; una operación destructiva de esquema puede no poder deshacerse sin pérdida de datos. Mantén copias y opciones de recuperación acordes al riesgo.

En producción, separa credenciales de despliegue y de ejecución de la aplicación, y registra quién aprobó y ejecutó cada migración. Complementa este procedimiento con el calendario de mantenimiento de aplicaciones y las prácticas CI/CD para GitLab y Kubernetes.