運行數據庫架構遷移的最佳實踐

Question

構建服務器通常與運行實例的 VPC 分離。 無論是基於 GCP 的 Cloud Build，還是利用眾多 CI 工具之一（CircleCI、Codeship 等），因此運行 DB 模式更新特別具有挑戰性。

所以，這讓我想知道......什么時候運行數據庫模式遷移的最佳位置？

從我的角度來看，有四種機會可以在 CD 管道中自動運行模式遷移或種子：

1. 在構建階段
2. 實例啟動時
3. 通過預熱腳本（同步或異步）
4. 通過端點，自動或手動調用部署后

選項 1 的主要問題是安全性。 使用 Google Cloud Sql/Google Cloud Build，我可以通過構建步驟和 SQL 代理運行（非常困難）、架構遷移/種子。 老實說，設置起來很麻煩……但它確實有效。

我的最新項目正在使用 MongoDb，如果我需要移動一些數據/播種一些數據，我已經在 migrate-mongo 中連接了它。 不幸的是，沒有這樣的 SQL 代理可以安全地將 MongoDb (atlas) 連接到 Cloud Build（或任何其他 CI 工具），因為它不在實例的 VPC 中運行。 因此，在我看來，這是一個死胡同。

因此，我對預熱腳本概念很感興趣（沒有雙關語意）。

使用 App Engine，在提供流量之前調用預熱腳本，並在已經可以通過 VPC 訪問的主機上調用。 預熱腳本旨在用於打開數據庫連接以加快連接速度，但假設沒有未完成的遷移，它就會這樣做 - 一個非常輕量級的選擇語句。

任何人都可以想到這種方法有什么問題嗎？

選項 4 也適用（本質上是一樣的）。 不過，這些端點可能需要更多保護 - 特別是如果存在“向下”遷移腳本（！）

Answer 1

很難回答你，因為這是一個基於意見的問題！

這是我對你的提議的看法

1. 這對我來說是最好的解決方案。 當然，您必須注意只添加字段而不是刪除或刪除現有的架構字段。 像這樣，您可以在構建階段更新架構，然后進行部署。 新部署將采用新架構，不再使用過時字段。 在下一次架構更新時，您將能夠刪除這些過時的字段並清理您的架構。
2. 此解決方案會降低您的冷啟動性能。 這不是一個合適的解決方案
3. 與之前相同的評論，除了堅持 App Engine 基礎架構和工作方式之外。
4. 與解決方案 1 相比沒有真正的優勢。

關於安全性，Cloud Build 將很快能夠與工作人員池一起使用。 仍處於 alpha 階段，但我希望在下個月發布它的 alpha 版本。