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