Flyway-1.7：处理分支的解决方法？ （Flyway issue 138）

Question

Flyway是一个非常好的自动化数据库更新（也称为迁移）的工具。但是，从版本1.7开始，它依赖于完全线性的迁移序列。如果你有一个生产系统，在你开发新东西的时候你必须提供修复，这个假设立即失效。常见问题解答argues correctly这对于生产系统本身来说不是问题，但是如果您有开发分支上已有的开发和/或QA系统，则需要从带外生产版本的修补程序运行迁移。

一个解决方案将允许这个问题正在等待Issue 138，但尚未完成。由于这几乎是一个致命的问题：如果我现在想使用它，是否有任何聪明的解决方法？

Answer 1

自Flyway版本2.0以来，问题已经过时：如果您设置了outOfOrder标志，那么flyway也将执行具有尚未应用的早期版本号的迁移。但是，您需要确保这种带外迁移可以以任何顺序应用于以后的迁移，否则您将遇到严重的麻烦。

使用Flyway-1.7，您可以采取以下解决方法。如果您有开发和生产分支，则可以为生产和开发分支分开独立的元数据表（例如，SCHEMA_HISTORY和SCHEMA_HISTORY_DEV）。在生产服务器上只有SCHEMA_HISTORY，并且照常工作;对于两者都有的开发服务器，每次运行flyway时，首先在生产分支sqls上使用SCHEMA_HISTORY运行它，然后在SCHEMA_HISTORY_DEV的开发分支sqls上运行它。

当您切换分支时，您必须将SCHEMA_HISTORY_DEV合并到SCHEMA_HISTORY中。 （您需要排除最初的修订并重置SCHEMA_HISTORY上的CURRENT_VERSION。）当flyway-1.8出来时，您可以合并并将SCHEMA_HISTORY_DEV移开。

Answer 2

我推荐的方法（以及在持续交付/部署中变得几乎必不可少）的方法是使用特性切换并从HEAD发布，而不是使用特性或发布分支。然后再与向后兼容的迁移相结合来完成缓解这个问题。

如果由于某种原因，这不是您的选择，您不必等待更长的时间。 1.8号航线（其中将包括138号航班）将很快推出。