4

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

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

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

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

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

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

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

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

如果有人能给我提示如何处理我的场景，那就太棒了:)

4

2 回答 2

1

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

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

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

于 2012-05-21T18:14:49.847 回答
1

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

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

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

当应用启动时，迁移工具会发现数据库结构已经过时，并将其升级到最新版本。完毕。

无需为此使用 DBUnit。

于 2012-05-21T22:15:33.337 回答