4

像 liquibase 和 flyway 这样的工具当然可以轻松升级您的数据库。我没有弄清楚的是如何最好地处理发布分支和主干上发生的更改。

一个例子：

我在产品中的代码是 2.5 版，并且位于发布分支上。与此同时，开发人员已经开始开发基于主干的 3.0 版本。

在生产中发现了一个错误。制作了一个数据库更改脚本（2.5.1）并提交到发布分支。必须将相同的更改脚本合并回主干（3.0.1？）。

版本 3.x 已发布到野外生产数据库中，与 2.5.1 相比已经有了变化。升级可能会失败。

相反，如果我从头开始创建一个数据库，如果我使用的是仅向前策略，我会发生两次相同的更改（2.5.1 和 3.0.1）。

其他人如何处理这种情况？

4

1 回答 1

1

您正确地认识到生产数据库更改将始终是线性的。

要解决这个问题，您应该将 DB 迁移 2.5.1 放在分支和主干上。并且不创建具有相同更改的 3.0.1！

这样，它将与分支一起部署，但也与主干一起部署。

然后将生产升级到主干

  • 找到迁移 2.5.1 并跳过它，因为它已经应用了
  • 找到迁移 3.0 并将其应用于 2.5.1 db

当然，还有更好的解决方案。那就是完全摆脱分支并始终从主干中释放使用功能切换来代替。

于 2012-07-24T18:56:01.713 回答