Flyway和liquibase在一起？

Question

我单独看过Liquibase和Flyway,仅凭个别比较,Liquibase似乎是满足我们需求的更好工具.有些消息来源提到同时使用Liquibase和Flyway.Liquibase似乎拥有Flyway所拥有的一切,并且在回滚方面具有更大的灵活性.Flyway的主要优点似乎是不必使用XML,但Liquibase允许您在XML中指定SQL文件.

基本上,我还不清楚将Flyway和Liquibase一起使用的好处是仅仅Liquibase,如果有的话.也许有办法做到这一点我没有看到,即使Liquibase指的是有效的Flyway SQL文件,这两个工具都必须独立运行并且仍然有相同的陷阱,即使你可以在技术上使用任何一种工具.

Answer 1

在我回答问题之前,一个小小的修正.假设

Liquibase似乎拥有Flyway所拥有的一切

不正确.在解析SQL时,Flyway闪耀.您可以使用由本机工具生成的未修改的SQL文件,其中包含各种复杂性,如PL/SQL包和过程,MySQL分隔符更改,T-SQL,PostgreSQL过程,...使用Liquibase,您必须将它们拆分为单独的语句,为SQL文件添加额外的注释,...

能够按原样使用SQL文件的好处是可以避免锁定.您可以使用现有的SQL文件,以最少的投资开始使用Flyway,如果它不再适合您的需求,可以在以后搬走.Liquibase不是这样.

另外,向下迁移的问题(将它们视为补偿事务,而不是回滚)实际上在理论上听起来很棒,但在实践中几乎不需要.请参阅https://flywaydb.org/documentation/faq#downgrade

然而,当归结为使用其中一个或两个时,我当然同意SteveDonie(Liquibase团队成员),只使用一个而不是两者一起几乎总是更好的选择.

免责声明:我是Flyway的创作者

Answer 2

我永远不会建议同时使用这两种工具.根据我的经验,即使只有其中一个在大型分布式环境中不时会发生冲突/冲突(超过5个团队可以访问同一个数据库).

在大型分布式团队的项目中运行这些工具时,我还会给你一些优点和缺点:

飞路:

缺点: 在迁移文件更改方面非常严格.如果有人签入了他们的迁移文件,则不建议更改它.这就像在共享项目中使用强制推送git一样.更改迁移(其内容或文件名称)将导致具有该文件的先前版本的每台计算机上的迁移失败.整个迁移包需要从头开始运行.在某些情况下,它可能需要很长时间.

优点: 嗯,Cons中描述的内容同时会建立一定程度的纪律.在讨论将多个团队同时更改引入生产运行应用程序时,这可能是一个合理的限制.

Liquibase:

缺点: 通过一些调整应该允许您更改现有(应用)迁移.虽然它可以被认为是一种好处,但是很多人在相同的代码库上工作,应该格外小心.灵活性是有代价的.当分布式项目允许这种"git force push"风格的变更时,引入一些"回归"或不一致会更容易.

优点:更具可配置性和灵活性.可能包括未来NoSql的解决方案.一些有用的插件(例如,hibernate集成).