Liquibase与Flyway的比较

在持续集成和数据库开发的自动化重构时代，我们需要采用渐进式数据库设计的技术。像Liquibase和Flyway这样的工具遵循这些技术，并提供迭代的开发方法。在本文中，我们将研究Liquibase和Flyway之间的差异和相似之处。

请注意，没有一种工具适合所有用例。每种工具在各自领域都有其优势。

Liquibase和Flyway的相似之处

由于Liquibase和Flyway实现了渐进式数据库的设计原则，它们提供了许多相似的功能。这两个工具：

• 在一定程度上都是开源的，帮助管理、跟踪和部署数据库模式变更。
• 使用版本化的迁移方法来改变数据库模式。
• 基于Java，并为Java框架如Spring Boot和Vert.x提供广泛支持。
• 支持与构建工具如Maven和Gradle集成。
• 可以通过提供的脚本独立于命令行运行。
• 支持多种数据库。

现在我们将讨论这些工具提供的不同之处。

Liquibase和Flyway的差异

3.1. 定义变更

Flyway使用SQL来定义变更。另一方面，Liquibase提供了灵活性，可以以不同格式指定变更，包括SQL，如XML、YAML和JSON。使用Liquibase，我们可以使用数据库无关的语言，轻松地将模式变更应用到不同类型的数据库。

Flyway围绕线性数据库版本控制系统构建，每次版本化变更都会递增。这有时可能会与并行开发产生冲突。Flyway脚本的文件名定义了迁移的类型。例如，迁移应该遵循前缀的约定，如_V_（表示版本化）、U（表示撤销）和R（表示可重复的）。后面跟着版本号和分隔符__（两个下划线），然后是描述和后缀.sql，如_V01__Add_New_Column.sql_。

Liquibase的迁移不需要遵循任何文件名约定。在Liquibase中，变更由一个称为主变更日志的账本管理，它将定义包括所有迁移。

3.2. 存储变更

两种工具都将部署的变更存储在表中。 Flyway迁移存储在数据库模式中的默认表名为_flyway_schema_history_。同样，Liquibase将其部署的迁移存储在名为_databasechangelog_的表中。两种工具都支持覆盖默认配置以更改表名。

3.3. 变更的执行顺序

在Flyway中管理变更的顺序相对困难。使用Flyway时，顺序取决于文件名中的版本号和迁移类型。相反，Liquibase使用一个名为_master_changelog_的单独文件，其中定义的变更将按照它们定义的顺序部署。

3.4. 回滚变更

现在，让我们讨论数据库迁移的一个主要方面。当一个不良变更导致应用程序出现灾难性问题时，需要回滚。 Liquibase提供了回滚所有内容或撤消特定迁移的方法（仅在付费版本中可用）。

Flyway也有撤销迁移的功能，可以通过文件名以_U_开头并跟随需要撤销的版本来部署。其付费版本还提供了更复杂的撤销功能。

两种工具都提供了不错的回滚功能，但考虑到仅免费版本，Flyway提供了一个好用的解决方案。

3.5. 选择性部署变更

有些情况下，我们需要只将变更部署到一个环境中。当我们需要选择性地部署变更时，Liquibase在这里胜出。Flyway也能够做到这一点，但你必须为每个环境或数据库设置不同的配置文件。使用Liquibase，我们可以轻松添加标签和上下文以确保在特定位置部署。

3.6. 基于Java的迁移

两种工具都强烈倾向于Java，并提供基于Java的迁移。Flyway和Liquibase允许在Java文件中定义迁移。这在某些场景中可能是有利的。

3.7. 快照与比较数据库

Liquibase允许用户拍摄当前数据库状态的快照。我们可以使用这个状态与另一个数据库进行比较。这在故障转移和数据库复制等场景中非常有用。另一方面，Flyway不支持任何快照功能。

3.8. 条件部署

Liquibase提供了一个名为先决条件的附加功能。先决条件允许用户根据数据库的当前状态应用变更。只有在通过这些先决条件后，变更集才会执行。

另一方面，Flyway不支持这一点。但通过过程，我们可以在大多数基于SQL的数据库中应用条件。

4. 结论

在本文中，我们比较了两种最常用的数据库迁移工具Liquibase和Flyway。在选择工具时，总是需要权衡。当比较这两种工具时，它们之间没有明显的弱点或优势。你可以根据你的应用需求选择Liquibase或Flyway，并检查大部分选项。