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

Question

构建服务器通常与运行实例的 VPC 分离。无论是基于 GCP 的 Cloud Build，还是利用现有的众多 CI 工具之一（CircleCI、Codeship 等），因此运行数据库模式更新尤其具有挑战性。

所以，这让我想知道...... 什么时候运行数据库架构迁移的最佳位置？

在我看来，有四种机会可以在 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 访问的主机上调用。预热脚本旨在用于打开数据库连接以加快连接速度，但假设没有未完成的迁移，它会这样做 - 一个非常轻量级的 select 语句。

谁能想到这种方法有什么问题？

选项 4 也很合适（本质上是一样的）。不过，这些端点可能需要更多保护 - 特别是如果存在“向下”迁移脚本（！）

Answer 1

很难回答你，因为这是一个基于意见的问题！

这是我对你的提议的看法

1. 这对我来说是最好的解决方案。当然，您必须注意只添加字段，而不是删除或删除现有架构字段。像这样，您可以在构建阶段更新架构，然后进行部署。新部署将采用新架构，并且不再使用过时的字段。在下一次架构更新时，您将能够删除这些过时的字段并清理您的架构。
2. 此解决方案会降低您的冷启动性能。这不是一个合适的解决方案
3. 除了对 App Engine 基础架构和工作方式的坚持之外，与之前的评论相同。
4. 与解决方案 1 相比没有真正的优势。

关于安全性，Cloud Build 将能够使用worker pool soon。仍处于 alpha 阶段，但我预计下个月会发布 alpha 版本。