Flyway和liquibase在一起？ [关闭]

Posted 2023-03-14

【中文标题】Flyway和liquibase在一起？ [关闭]

【英文标题】：Flyway and liquibase together? [closed]

【发布时间】：2016-12-26 22:59:08

【问题描述】：

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

基本上，我仍然不清楚将 Flyway 和 Liquibase 一起使用会比仅使用 Liquibase 带来什么好处（如果有的话）。也许有一种方法可以做到这一点，即使 Liquibase 指的是有效的 Flyway SQL 文件，这两种工具也必须独立运行并且仍然存在相同的缺陷，即使您在技术上可以使用任何一种工具。

【参考方案1】：

在我回答问题之前，做一个小更正。假设

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 试图提出的观点。

【讨论】：

哇，我没想到创作者会直接给出如此明确的答案！谢谢。您对回滚的看法是有道理的，即使使用 liquibase 回滚也或多或少是另一种迁移。我觉得练习是让事情变得更加相对的地方。这是为了取代或多或少的手动过程，因此实际上任何工具都可能是更好的做法。由于用例是在 Jenkins 的工作中，我觉得生产中有某些不受欢迎的变化，你需要反向操作。从我的角度来看，回滚只是一个命令的名称。

我的意思是，如果您愿意，您可以更改名称。回滚刚刚被采用，目前正在使用中。如果我开始为它使用不同的名称，没有人会称它为别的东西，因为我还没有建立这种趋势。只是我的想法。

嘿嗨，我对你的回答有很大的疑问，当我在主页上看到迁移工具和映射器之间的比较时，你无法将 mybatis 与 flyway 进行比较，就像将苹果与特斯拉引擎进行比较一样，他们就像..做同样的事情..他们存在！和供应商锁定..真的吗？从 postgres 中获取普通的旧（我猜是通用的）sql 并将其应用到 oracle 中，你会得到普通的老人，直到你得到“轻而易举”的结果 ans liquibase 不仅仅是关于 xml 只是打开文档。 . 哦，我的

看看这个mybatis.org/migrations :-)

Axel - 感谢您在 Flyway 上所做的工作，但我已经将 Rails 与 Java 一起使用了好几年了，并且多次使用了一个或多个回滚。虽然它“几乎从不需要”，但它是必需的，并且最好让开发人员为每个更改编写一个回滚。此外，在您的常见问题解答中，您似乎建议使用备份/恢复和快照——但这应该是数据库接受订单并跟踪业务工作的最后手段。我希望你能重新考虑回滚的好处。如果可能，我也会提倡非破坏性迁移——重命名与删除。

【参考方案2】：

我绝不建议同时使用这两种工具。根据我的经验，在大型分布式环境（超过 5 个团队可以访问同一个数据库）中，即使其中只有一个也会不时引起冲突/冲突。

在大型分布式团队的项目中运行这些工具时，我还将告诉您一些优缺点：

FlyWay：

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

优点： 好吧，Cons 中描述的内容将同时建立一定程度的纪律。在谈论将多个团队同时更改引入生产运行的应用程序时，这可能是一个合理的限制。

Liquibase：

缺点： 使用几个tweaks 应该允许您更改现有（应用的）迁移。虽然它可以被认为是一种好处，但由于很多人在同一个代码库上工作，所以应该格外小心。灵活性是有代价的。当分布式项目允许这种“git force push”风格的更改时，更容易引入一些“回归”或不一致。

优点：更可配置且更灵活。将来可能包括 NoSql 的解决方案。几个有用的插件（例如休眠集成）。