liquibase 和 flyway 等工具无疑可以轻松升级您的数据库。我还没有弄清楚如何最好地处理发布分支和主干上发生的更改。
一个例子:
我在产品中的代码是 2.5 版并且存在于发布分支上。与此同时，开发人员已经开始开发位于主干上的 3.0 版。
在生产中发现了一个错误。制作数据库更改脚本(2.5.1)并提交到发布分支。相同的更改脚本必须合并回主干(3.0.1？)。
版本 3.x 发布到野外生产数据库的将已经从 2.5.1 更改。升级可能会失败。
相反，如果我使用前向策略从头开始创建数据库，我会发生两次相同的更改(2.5.1 和 3.0.1)。
其他人如何处理这种情况？
最佳答案
你是正确的承认生产数据库更改将始终是线性的 .
要解决此问题，您应该将 DB 迁移 2.5.1 放在分支和主干上。而不是创建具有相同更改的 3.0.1!
这样，它将与分支一起部署，但也将与主干一起部署。
然后将生产升级到主干
当然，还有更好的解决方案。那就是完全摆脱分支，并始终使用功能切换从主干中释放。
关于liquibase - 数据库变更管理 - 如何处理分支和主干上的变更，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11632922/