代码之家  ›  专栏  ›  技术社区  ›  Tymur Berezhnoi

FlyWay迁移策略

  •  5
  • Tymur Berezhnoi  · 技术社区  · 7 年前

    目前在一个项目中,我们使用FlyWay,我们有多个环境,例如:开发人员(开发者本地)、QA人员应用程序的多个实例、登台。。。我们有这样的任务工作流: 正在进行中->代码审查->QA->合并 .

    我们面临一个问题:假设一个开发人员在处理分支时 A. ,提供了一个新的迁移版本,比如说V331,同时一个QA人员正在另一个分支上进行QA B ,在QA环境中。qa环境可能已经有v331版本,因为几个开发人员可能在不同的时间在不同的分支上创建相同的版本号。。。更多的qa经常在分支之间切换,这就是qa数据库变得混乱的原因,尤其是表 schema\u版本 它引导我们手动删除损坏的模式版本,解决旧的迁移版本问题,然后再次在环境中启动迁移过程。你如何应对多种环境和飞行路线?有最佳实践吗?

    1 回复  |  直到 7 年前
        1
  •  5
  •   Stefan    7 年前

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

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

    如果您开始用发行号命名版本,您将不会有重叠的版本名,合并也不会关心丢失的序号或版本名低于已合并项目。 How to use Flyway when working with feature branches

    当不使用问题跟踪器时,您可以找到其他方法,即一个新分支获得更高的subversion或类似的东西。