当前，在一个项目中，我们使用FlyWay，并且我们有多个环境，例如:dev(开发人员本地)，质保人员的应用程序的多个实例，暂存...以及这样的工作流程，其任务是:正在进行->代码审查->质量检查->合并。
我们面临一个问题:假定开发人员在分支上工作时，一个提供了新的迁移版本，比如说V331，而一个QA家伙正在另一个分支上进行质量检查，比如说 B ，则是在QA环境中。 qa环境可能已经具有版本v331，因为几个开发人员可能会在不同的时间在不同的分支上创建相同的版本号，这可能发生。。。此外，qa经常在分支之间切换，这就是为什么qa数据库变得困惑，尤其是表 schema_version ，它告诉我们，我们手动删除了损坏的架构版本，解决了旧的迁移版本问题，然后再次在环境上启动了迁移过程。您如何应对多种环境和飞行路线？有最佳做法吗？
最佳答案
有一种方法，不确定是否适合您的需求。
您可以使用outOfOrder配置字段将flyway配置为忽略版本控制的增量值:https://flywaydb.org/documentation/commandline/migrate
如果您开始使用发行号来命名版本，则不会有重叠的版本名称，并且合并将不会担心缺少序号或版本名称比已合并的项目要低。
How to use Flyway when working with feature branches
当不使用问题跟踪器时，您可以找出其他问题，其中新分支具有更高的子版本或类似的东西。