Flyway是一个非常好的自动化数据库更新工具（也称为迁移）。但是，从版本1.7开始，它依赖于完全线性的迁移序列。如果你有一个生产系统，你必须在你开发新东西时提供修复，这个假设立即无效。 FAQ argues correctly这对于生产系统本身来说不是问题，但如果您已经在开发分支上的开发和/或QA系统，则需要从生产版本的修订中运行迁移带外。
允许此问题的解决方案正在等待Issue 138，但尚未完成。因为这几乎是一个致命的问题：如果我现在想要使用它，是否有任何聪明的解决方法？
答案 0 :(得分：1)
我建议的方法（在持续交付/部署中几乎必不可少）环境使用功能切换和HEAD发布，而不是使用功能或发布分支。然后将其与向后兼容的迁移相结合，以完成缓解此问题。
如果出于某种原因不适合您，您不必再等待太久。 Flyway 1.8（将包括138的修复版）将很快推出。
答案 1 :(得分：0)
自Flyway版本2.0以来问题已经过时：如果您设置outOfOrder标志，那么flyway还将执行尚未应用的早期版本号的迁移。但是，您需要确保此类带外迁移可以按任何顺序应用于以后的迁移，否则您将遇到严重问题。
使用Flyway-1.7，您可以进行以下解决方法。如果您有开发和生产分支，则可以使用单独的flyway实例，包括生产和开发分支的单独元数据表（例如，SCHEMA_HISTORY和SCHEMA_HISTORY_DEV）。在生产服务器上只有SCHEMA_HISTORY，你照常工作;对于您拥有两者的开发服务器，每次运行flyway时，首先在生产分支sqls上使用SCHEMA_HISTORY运行它，然后在开发分支sqls上使用SCHEMA_HISTORY_DEV运行它。
切换分支时，必须将SCHEMA_HISTORY_DEV合并到SCHEMA_HISTORY中。 （您需要排除初始修订并重置SCHEMA_HISTORY上的CURRENT_VERSION。）当flyway-1.8出现时，您执行此合并并抛出SCHEMA_HISTORY_DEV。