数据库结构用Flyway/Liquibase，数据库插入用DBUnit？

Question

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

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

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

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

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

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

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

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

如果有人能为我提供如何处理我的场景的提示，那就太棒了：）

Answer 1

简而言之，你所有的改变都将通过Liquibase或Flyway来完成。

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

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

Answer 2

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

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

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

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

无需为此使用数据库单位。