mongodb - 运行数据库架构迁移的最佳实践

Question

构建服务器通常与运行实例的 VPC 分离。无论是基于 GCP 的 Cloud Build，还是利用众多 CI 工具之一(CircleCI、Codeship 等)，因此运行 DB 模式更新特别具有挑战性。
所以，这让我想知道.... 运行数据库架构迁移的最佳位置是什么时候？
从我的角度来看，有四种机会可以在 CD 管道中自动运行模式迁移或种子:

在构建阶段

在实例启动时

通过预热脚本(同步或异步)

通过端点，自动或手动调用部署后

选项 1 的主要问题是安全性。使用 Google Cloud Sql/Google Cloud Build，我可以通过构建步骤和 SQL 代理运行(非常困难)、架构迁移/种子。老实说，设置起来很麻烦……但它确实有效。
我的最新项目正在使用 MongoDb，如果我需要移动一些数据/播种一些数据，我已经在 migrate-mongo 中连接了它。不幸的是，没有这样的 SQL 代理可以安全地将 MongoDb (atlas) 连接到 Cloud Build(或任何其他 CI 工具)，因为它不在实例的 VPC 中运行。因此，在我看来，这是一个死胡同。
因此，我对 热身脚本概念 感到温暖(没有双关语意)。
使用 App Engine，在提供流量之前调用预热脚本，并在已经可以通过 VPC 访问的主机上调用。预热脚本旨在用于打开数据库连接以加快连接速度，但假设没有未完成的迁移，它就会这样做 - 一个非常轻量级的选择语句。
任何人都可以想到这种方法有什么问题吗？
选项 4 也适用(本质上是一样的)。不过，这些端点可能需要更多保护 - 特别是如果存在“向下”迁移脚本(!)

Answer 1

很难回答你，因为这是一个基于意见的问题!
这是我对你的提议的看法

这对我来说是最好的解决方案。当然，您必须注意只添加字段而不是删除或删除现有的架构字段。像这样，您可以在构建阶段更新架构，然后进行部署。新部署将采用新架构，不再使用过时字段。在下一次架构更新时，您将能够删除这些过时的字段并清理您的架构。

此解决方案会降低您的冷启动性能。这不是一个合适的解决方案

与之前相同的评论，除了要坚持 App Engine 基础架构和工作方式。

与解决方案 1 相比没有真正的优势。

关于安全性，Cloud Build 将能够与 worker pool soon 一起使用。仍处于 alpha 阶段，但我希望在下个月发布它的 alpha 版本。