如何在谷歌应用引擎上建立一个登台环境

我在设置中选择了第二个选项,因为它是最快的解决方案,而且我还没有编写任何脚本来更改部署时的应用程序参数。

但我现在看到的是,方案A是一个更清洁的解决方案。您可以使用几行代码根据版本切换数据存储名称空间,您可以从环境变量current_version_id动态获取该版本,如本文所述: http://code.google.com/appengine/docs/python/runtime.html#The_Environment

如果需要单独的数据存储, 选项B看起来更干净 因为:

1. 您可以保留用于生产应用程序的真正版本控制的版本功能。
2. 您可以保留用于流量分割的版本功能。
3. 您可以为多租户保留名称空间功能。
4. 您可以轻松地将实体从一个应用程序复制到另一个应用程序。在名称空间之间并不容易。
5. 很少有API仍然不支持名称空间。
6. 对于具有多个开发人员的团队,可以为单个人员授予“上载到生产”权限。

我们选择了选项B,我认为总体上更好,因为它完全隔离了项目。因此,例如,在登台服务器上使用某些配置不会影响并不会损害安全性,也不会在生产环境中造成任何其他蝴蝶效应。

至于部署脚本,您可以在app.yaml中使用任何应用程序名称。一些虚拟/dev名称,在部署时,只需使用 -A 参数:

appcfg.py -A your-app-name update .

这将大大简化您的部署脚本,不需要字符串替换或在app.yaml中进行任何类似操作。

我们使用选项B。

除了zygmantas建议在应用程序级别上分离dev和prod的好处之外,我们还使用dev应用程序测试性能。

通常,dev实例在运行时没有太多可用的资源,这有助于了解应用程序“感觉”的速度有多慢。然后,我们还可以独立地调整性能设置,看看有什么不同(例如前端实例类)。

当然,有时我们需要咬紧牙关,调整现场观看。但是有另一个应用程序可以玩真是太好了。

仍然使用名称空间和版本,只是dev是脏的并且是实验性的。

我更喜欢选项A,我正试图设置一个 simple build script 自动化处理