El objetivo no es solo crear tablas
Flyway convierte el esquema en parte del entregable: cada entorno puede reconstruir la misma secuencia de cambios. En un equipo, esto elimina instrucciones manuales y reduce diferencias invisibles entre bases locales, staging y producción.
Migraciones inmutables
Una migración aplicada no se edita. Si aparece un error, creo una nueva versión que lo corrige:
V1__create_users.sql
V2__add_email_verification.sql
V3__fix_verification_index.sqlModificar V1 después de ejecutarla rompe el historial y hace que dos entornos puedan representar versiones distintas con el mismo nombre.
Cambios compatibles en despliegues
Cuando la aplicación anterior y la nueva pueden convivir durante un despliegue, uso una secuencia expandir-migrar-contraer:
Esto evita que una migración destructiva deje fuera de servicio instancias todavía activas.
Datos de referencia
Roles, catálogos y estados iniciales pueden vivir en migraciones versionadas cuando son parte del modelo. No mezclo esos datos con usuarios de prueba o contenido temporal.
Para datos que deben actualizarse repetidamente, evalúo migraciones repetibles o procesos idempotentes con responsabilidad clara.
Schemas compartidos
En ECOS utilicé un schema dedicado dentro de una instancia compartida. Esto reduce colisiones, pero no reemplaza permisos, naming consistente y ownership explícito.
La aplicación debe declarar cuál schema administra y Flyway debe apuntar al mismo historial en todos los entornos.
Qué pruebo
Una migración no está terminada solo porque funciona sobre una base vacía. Verifico:
Conclusión
Flyway aporta valor cuando el equipo trata las migraciones como código de producción: revisión por PR, inmutabilidad, compatibilidad y pruebas. Versionar SQL sin una estrategia de despliegue solo automatiza el riesgo.