FlyWay迁移策略

Question

目前，我们在一个项目上使用FlyWay，并且我们有一个多个环境，例如:dev(本地开发人员)、QA应用程序的几个实例、暂存.我们有这样的任务工作流：in progress、->代码评审、-> QA -> merge。

我们面临一个问题:假设开发人员在开发分支A时提供了一个新的迁移版本，比如V331，同时QA人员在另一个分支上做qa，在QA环境上使用B。qa环境可能已经有了版本v331，因为几个开发人员可能在不同的时间在不同的分支上创建相同的版本号.更多的是qa在分支之间的切换，这就是qa数据库变得混乱的原因，尤其是表schema_version，，它导致我们手动删除损坏的模式版本，解决旧的迁移版本问题，然后在环境中再次启动迁移过程。如何处理多个环境和天桥？有最好的做法吗？

Answer 1

有一种方法，不确定它是否适合你的需要。

您可以使用outOfOrder config字段：https://flywaydb.org/documentation/commandline/migrate来配置天桥，以忽略版本控制的增量值。

如果开始用问题号命名版本，则不会有重叠的版本号，合并也不会关心缺少的序列号或版本号是否低于已经合并的项。How to use Flyway when working with feature branches

当不使用问题跟踪器时，您可以找到其他的东西，新的分支会得到更高的subversion或类似的东西。