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號航班）將很快推出。