FlyWay迁移策略

Tim*_*rJD 5 java database-migration flyway

目前在我们使用FlyWay的项目中,我们有多个环境,例如:dev(本地开发人员),QA人员应用程序的几个实例,分段......我们有这样的工作流程,包括任务:进行中 - >代码评论 - >质量保证 - >合并.

我们遇到了一个问题:假设一个开发人员在分支机构A上工作,提供了一个新的迁移版本,比方说V331,同时一个QA人在另一个分支上做qa,比如B,在QA环境中.可能会发生qa环境已经有版本v331,因为几个开发人员可能会在不同的时间在不同的分支上创建相同的版本号...更多的qa在分支之间切换非常频繁,这就是为什么qa数据库变得混乱,特别是表schema_version,它引导我们手动删除损坏的模式版本,解决旧的迁移版本问题,然后再次在环境中启动迁移过程.你如何处理多个环境和飞路?有最好的做法吗?

Ste*_*fan 5

有一种方法,不确定它是否适合您的需求.

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

如果您开始使用问题编号命名版本,则不会有重叠的版本名称,并且合并将不关心缺少序列号或版本名称低于已合并的项目. 如何在使用功能分支时使用Flyway

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