Presta atención ya que en esta crónica vas a encontrar la contestación que buscas.
Solución:
Una pequeña corrección, antes de responder a la pregunta. La suposición
Liquibase parece tener todo lo que tiene Flyway
no es correcto Flyway brilla cuando se trata de analizar SQL. Puede usar archivos SQL no modificados generados por sus herramientas nativas que contienen todo tipo de complejidad como paquetes y procedimientos PL/SQL, cambios de delimitador MySQL, T-SQL, procedimientos PostgreSQL, … Con Liquibase tendría que dividirlos en declaraciones individuales, agregue comentarios adicionales a los archivos SQL, …
La belleza de poder usar sus archivos SQL tal como están es que evita el bloqueo. Puede tomar sus archivos SQL existentes, comenzar a usar Flyway con una inversión mínima y mudarse más tarde si ya no se ajusta a sus necesidades. No es así con Liquibase.
Además, el problema de las migraciones descendentes (piense en ellas como transacciones compensatorias, no reversiones) es realmente algo que suena muy bien en teoría, pero que casi nunca es necesario en la práctica. Consulte esta página de documentación antigua¹.
Sin embargo, cuando se trata de usar uno o ambos, ciertamente estoy de acuerdo con SteveDonie (miembro del equipo de Liquibase) en que usar solo uno en lugar de los dos juntos casi siempre es la mejor opción.
Descargo de responsabilidad: soy el creador de Flyway
¹ Aunque Flyway admite deshacer migraciones hoy en día, al leer la documentación anterior comprenderá el punto que Axel Fontaine está tratando de demostrar.
Nunca recomendaría usar ambas herramientas al mismo tiempo. En mi experiencia, incluso uno solo de ellos causa conflictos/colisiones de vez en cuando en entornos distribuidos grandes (más de 5 equipos con acceso a la misma base de datos).
También le daré un par de ventajas y desventajas cuando se trata de ejecutar estas herramientas en proyectos con equipos grandes y distribuidos:
ruta de vuelo:
Contras:
Muy estricto cuando se trata de cambios en los archivos de migración. Si alguien registró su archivo de migración, no se recomienda cambiarlo. Es como usar force push en git en proyectos compartidos. Cambiar una migración (ya sea su contenido o el nombre del archivo) provocará un error de migración en todas las máquinas que tenían la versión anterior del archivo. Todo el paquete de migración deberá ejecutarse desde cero. En algunos casos puede llevar mucho tiempo.
Ventajas:
Bueno, lo que se describió en Contras, al mismo tiempo, desarrollará un nivel de disciplina. Podría ser una restricción razonable cuando se habla de introducir cambios simultáneos por parte de varios equipos en una aplicación que se ejecuta en producción.
Liquibase:
Contras:
Con un par de ajustes debería permitirle cambiar las migraciones existentes (aplicadas). Si bien puede considerarse un beneficio, con muchas personas trabajando en el mismo código base, se debe tener especial precaución. La flexibilidad tiene un precio. Es más fácil introducir alguna “regresión” o inconsistencia cuando se permite el estilo de cambios “git force push” para proyectos distribuidos.
Ventajas: Más configurable y más flexible. Podría incluir soluciones para NoSql en el futuro. Un par de complementos útiles (integración de hibernación, por ejemplo).
Si guardas alguna vacilación y disposición de aclarar nuestro noticia eres capaz de añadir una ilustración y con placer lo leeremos.