我已经分别查看了 Liquibase 和 Flyway，仅通过单独比较，Liquibase 似乎是满足我们需求的更好工具。一些消息来源提到同时使用 Liquibase 和 Flyway。 Liquibase 似乎拥有 Flyway 所拥有的一切，并且在回滚方面具有更大的灵活性。 Flyway 的主要优点似乎是不必使用 XML，但 Liquibase 允许您在其 XML 中指定 SQL 文件。
基本上，我仍然不清楚将 Flyway 和 Liquibase 一起使用会比仅使用 Liquibase 带来什么好处（如果有的话）。也许有一种方法可以做到这一点，即使 Liquibase 指的是有效的 Flyway SQL 文件，这两种工具也必须独立运行并且仍然存在相同的缺陷，即使您在技术上可以使用任何一种工具。
【问题讨论】：
标签： compare database-migration liquibase flyway
在我回答问题之前，做一个小更正。假设
Liquibase 似乎拥有 Flyway 所拥有的一切
不正确。 Flyway 在解析 SQL 方面大放异彩。您可以使用由本地工具生成的未经修改的 SQL 文件，其中包含各种复杂性，例如 PL/SQL 包和过程、MySQL 分隔符更改、T-SQL、PostgreSQL 过程……使用 Liquibase，您必须将它们拆分为单独的语句，向 SQL 文件添加额外的 cmets，...
能够按原样使用 SQL 文件的好处在于可以避免锁定。您可以使用现有的 SQL 文件，以最少的投资开始使用 Flyway，如果它不再适合您的需求，则稍后将其移走。 Liquibase 并非如此。
此外，向下迁移的问题（将它们视为补偿事务，而不是回滚）在理论上听起来确实很棒，但在实践中几乎不需要。请参阅 this 旧文档页面¹。
然而，当谈到使用一种或两种时，我当然同意 SteveDonie（Liquibase 团队成员）的观点，即只使用一种而不是同时使用两种几乎总是更好的选择。
免责声明：我是 Flyway 的创造者
¹ 尽管 Flyway 现在确实支持撤消迁移，但通过阅读旧文档，您将了解 Axel Fontaine 试图提出的观点。
【讨论】：
我绝不建议同时使用这两种工具。根据我的经验，在大型分布式环境（超过 5 个团队可以访问同一个数据库）中，即使其中只有一个也会不时引起冲突/冲突。
在大型分布式团队的项目中运行这些工具时，我还将告诉您一些优缺点：
FlyWay：
缺点： 在迁移文件更改方面非常严格。如果有人签入了他们的迁移文件，则不建议对其进行更改。这就像在共享项目中在 git 中使用强制推送。更改迁移（其内容或文件名）将导致具有该文件先前版本的每台计算机上的迁移失败。整个迁移包需要从头开始运行。在某些情况下，这可能需要很长时间。
优点： 好吧，Cons 中描述的内容将同时建立一定程度的纪律。在谈论将多个团队同时更改引入生产运行的应用程序时，这可能是一个合理的限制。
Liquibase：
缺点： 使用几个tweaks 应该允许您更改现有（应用的）迁移。虽然它可以被认为是一种好处，但由于很多人在同一个代码库上工作，所以应该格外小心。灵活性是有代价的。当分布式项目允许这种“git force push”风格的更改时，更容易引入一些“回归”或不一致。
优点：更可配置且更灵活。将来可能包括 NoSql 的解决方案。几个有用的插件（例如休眠集成）。
【讨论】：