用于数据库结构的Flyway / Liquibase和用于数据库插入的DBUnit？

Question

我的应用程序有以下场景：

• 1个生产服务器
• 1个测试服务器
• n开发计算机

对于数据库迁移，我们使用Schema和DBUnit的Hibernate Schema Update来填充生产数据（在所有服务器/计算机上）。架构更新完成后，我为新架构生成一个新的DTD文件，因此我可以重新导入DBUnit XML。应用程序在启动时使用XML文件更新数据库（仅在开发和测试服务器/计算机上！）

当然，这种方法不是最优和脆弱的。所以我看了Liquibase和Flyway。两者似乎都是很好的工具，但我没有得到的是：我如何迁移数据？在我的例子中，我每周一次转储生产系统的数据并将其作为DBUnit XML文件添加到应用程序源代码控制中，因此所有开发人员都有“新鲜”数据，测试服务器也有当前生产数据。

我在Liquibase和Flyway看到的问题是，没有解决方法如何从数据库数据中自动执行差异并自动生成迁移更改。

所以我的想法是以下步骤：

1. 将Hibernate设置为验证而不是更新。
2. 当需要更改STRUCTURAL数据库时，我将其添加到主要版本的迁移脚本
3. 迁移脚本中没有数据库插入。
4. 根据新的数据库结构为DBunit生成新的DTD
5. 从生产数据库生成DBUnit XML。

另一个想法是利用flyways JavaMigration并提供基于DBUnit的初始数据库转储。数据库数据的所有其他更改将在迁移脚本中处理。但仍然存在问题：如何从当前迁移脚本状态和生产数据库状态进行差异？

如果有人能提供我如何处理我的方案的提示，那将是非常棒的：）

Answer 1

简短的回答是，您所做的所有更改都将通过Liquibase或Flyway完成。

我们使用Flyway，使用相同的产品/测试/开发设置。 我们使用存储在源代码管理中的Flyway迁移脚本进行所有数据库更改（结构或元数据）。每次我们对环境进行新部署时，我们首先在那里运行迁移脚本（使用命令行工具或maven插件）。代码首先进入开发环境，在那里进行集成测试，并继续进行测试和生产。

需要注意的主要事项是，Flyway需要对文件进行线性版本控制，因此如果两个开发人员同时检入迁移，则其中一个必须重命名他们。

Answer 2

如果您的目标是在DEV和TEST环境中使用PROD数据库的转储，我会：

• 将数据库迁移工具配置为在应用程序启动时运行（Flyway和Liquibase都通过各自的API支持此功能）
• 将所有数据库结构迁移与应用程序一起打包
• 从PROD转储数据和结构

这样，当PROD数据库恢复到DEV或TEST时，也会恢复迁移工具的旧元数据表。

当应用程序启动时，迁移工具将发现db结构已过时并将其升级到最新版本。完成。

不需要使用DBUnit。