FlyWay 迁移策略

Question

目前在我们使用 FlyWay 的项目中，我们有多个环境，例如：dev（开发人员本地），QA 人员的多个应用程序实例，登台......我们有这样的工作流程与任务：进行中 -> 代码审查 -> QA -> 合并。

我们遇到了一个问题：假设开发人员在处理分支 A 期间提供了一个新的迁移版本，比如说 V331，同时一个 QA 人员正在另一个分支上进行 QA，比如说B，关于 QA 环境。可能qa环境已经有v331版本，因为几个开发者可能会在不同的时间在不同的分支上创建相同的版本号……而且qa经常在分支之间切换，这就是qa数据库变得乱七八糟的原因，尤其是表schema_version，它告诉我们我们已经手动删除损坏的架构版本，解决旧的迁移版本问题，然后再次在环境中启动迁移过程。您如何处理多种环境和飞行路线？有最佳做法吗？

Answer 1

有一种方法，不确定是否适合您的需求。

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

如果您开始使用问题编号命名您的版本，您将不会有重叠的版本名称，并且合并不会关心缺少序列号或版本名称低于已合并项目。 How to use Flyway when working with feature branches

当不使用问题跟踪器时，您可以找出其他问题，即新分支获得更高的颠覆或类似的东西。