連續交付生產數據遷移模式

Question

連續交付生產中的關係數據庫（和模式）遷移模式是什麼？

在許多傳統開發中，DBA在當前發佈週期中創建的許多較小腳本中安排了一個大型遷移腳本。但是在CD中，開發人員可能想要將更改推向生產，而不是等待用其他腳本編譯它們。

我知道在rails-migration上，但對我來說，使用原始sql腳本看起來更合理。

我也見過像flyway這樣的工具來管理遷移，但我還沒有看到很多人在生產中使用它們。這就是爲什麼我想知道這裏常見的做法。

Answer 1

Flyway適用於連續交付/部署。許多客戶在所有環境中使用它，包括生產。

跨環境級聯DB遷移的一個最重要的事情是有一個3個步驟：

步驟1

舊的應用程序代碼與舊的數據庫一起工作。

步驟2

新的應用程序代碼中得到部署，並遷移DB上啓動。此遷移必須向後兼容，以便舊應用程序代碼仍可與新數據庫一起使用。這是必要的，因爲：

• 然後你可以做滾動升級，每次升級一個節點，直到當新的壞
所有節點都具有新的應用程序代碼立即
• 回滾到舊的應用程序代碼

此步驟可能涉及兼容性視圖和觸發器以執行此項工作。

步驟3

更改已證明的工作之後，應用程序代碼的下一個版本得到 必要DB遷移部署在一起以丟棄任何剩餘的過時的（來自步驟1）和兼容性（從步驟2）結構。

Answer 2

對單個（原始）sql文件實施對數據庫的更改，然後使用sqlpatch構建遷移腳本。

我通常只有一個單獨的數據庫git倉庫和一個CD環境附加到它。我通常有一個生產和開發數據庫，​​當我推送到相應的分支時會自動遷移。

此設置使得爲功能分支設置另一個數據庫並對其進行實驗變得非常簡單。 Sqlpatch負責處理單獨的sql文件中的所有依賴項，以便我可以輕鬆地將特性分支合併到另一個分支中。