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