运行数据库架构迁移的最佳做法

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

所以，这让我感到奇怪。...什么时候是运行数据库架构迁移的最佳场所？

从我的角度来看，有四个机会可以在CD管道中自动运行模式迁移或种子：

选项1的主要问题是安全性。使用Google Cloud sql / Google Cloud Build，我可以通过一个构建步骤和一个 sql代理来运行（非常费力），模式迁移/种子。坦白地说，设置起来确实很麻烦……但是确实有效。

我的最新项目是利用MongoDb，如果我需要移动一些数据/播种一些数据，我已经在migration-mongo中进行了连接。不幸的是，由于没有在实例的VPC中运行的MongoDb（图集）与Cloud Build（或任何其他CI工具）没有安全的sql代理。因此，这是我眼中的死胡同。

因此，我正在为（预热脚本概念）加油（不是双关语）。

使用App Engine，在提供流量之前，在已经可以通过VPC访问的主机上，调用预热脚本。预热脚本旨在用于打开数据库连接以加快连接速度，但是假设没有未完成的迁移，它就会做到这一点-一个非常轻便的select语句。

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

选项4也适用（本质上是同一件事）。不过，在这些端点上可能还需要更多保护-尤其是如果存在“向下”迁移脚本（！）

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

这是我对您的主张的看法

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

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