使用不同的应用程序 ID 进行调试/QA（通过 gradle Build Flavor）和 Google App Engine答案

【问题标题】：Using a different Application Id for debug/QA (via gradle Build Flavor) and Google App Engine使用不同的应用程序 ID 进行调试/QA（通过 gradle Build Flavor）和 Google App Engine
【发布时间】：2015-02-07 22:59:50
【问题描述】：

我正在考虑通过附加“-DEBUG”来更改我的应用程序 ID 的名称，这允许我在同一设备上安装它的发布版本和调试版本（并且还有助于解决 Crashlytics 过滤等问题）是其他方法来处理），但它会给谷歌应用引擎后端带来问题，因为所有安全功能都应该与应用程序名称相关联。

我正在考虑两种可能的解决方案，但想看看是否有其他人遇到过这个问题并且可能有更优雅的方法。

1) 相反，我可以通过 gradle versionNameSuffix 更改应用程序版本，尽管这不允许应用程序的两个版本共存

2) 向应用引擎后端注册两个应用 ID

我是不是想错了？一般来说，人们如何处理他们的应用程序的发布和 QA 实例并设置其后端的相应版本？此外，发布与 QA 后端实例是否共享相同的数据存储？谢谢。

【问题讨论】：

标签： android google-app-engine google-cloud-endpoints android-testing android-debug

【解决方案1】：

就我个人而言，我一直使用您正在考虑的后缀方法，除了一组更系统的后缀（-dev 如果有一个“开发中”版本，-dev-<developersusername> 如果团队中的每个开发人员都获得了单独的一个，-staging、-qa、-canary、-prod 等，具体取决于给定应用程序的确切部署工作流）。

而且，我需要从各种版本中使用的任何外部系统，例如您的应用引擎后端，我都会在其上注册所有相关版本。通常，一个小而简单的脚本可以轻松解决这个问题！-)

我认为在生产版本（其数据可能很宝贵并且绝对要保存）和很可能有问题的开发版本之间共享数据存储或其他持久性数据组是非常冒险的 - 不能新版本中有些意料之中的错误之一会抹去宝贵的待保存生产数据？

【讨论】：

感谢您的回复。那么在这种情况下，您是否为每种构建类型（staging、qa、canary、prod 等）创建完全不同的后端项目？或者 GAE 是否也允许对数据存储进行“实例化”或“版本化”？
@Creos，GAE 数据存储有 namespaces 可以对数据存储进行分区/分段——但在某个时候准确定义要使用的命名空间取决于应用程序，因此可以也会受到一个错误的影响......太冒险了。因此，我更喜欢单独的 GAE 应用程序，这样我可以确保新的有缺陷的应用程序不会破坏宝贵的数据——bulkload.py 有助于“复制”部分或全部现有的已填充数据存储，以便在以下情况下播种新的数据存储这对测试和开发很有帮助，或者控制台也可以提供帮助（但我更喜欢脚本来确保过程的完全可重复性......更合理！-）。
有道理，谢谢。但我有点困惑——在你的回答中，你指的是“应用程序版本”（当我在这里说应用程序时，我指的是客户端应用程序），这让我认为你的意思是你将说“-QA”附加到应用程序版本.但这不起作用，因为他们的应用程序 ID 将保持不变，并且您无法使用不同的 GAE 后端注册相同的应用程序 ID。那么您的意思是您使用后缀方法创建完全不同的应用程序 ID，而不是不同的应用程序版本 ID？感谢您的澄清。
@Creos，不，我没有在任何正式意义上使用“版本”——只是普通的、普通的、口语的——使用不同的应用程序 ID 通常是最简单的。
我明白了，谢谢，我会探索的。我想知道这种方法有多普遍，但我同意你的观点，依赖命名空间可能非常冒险……希望 GAE 提供一些本地解决方案，而不是为 PROD、QA、DEV 创建完全独立的应用程序。您将需要并行移动它们的版本。如果使用 GCM 也必须小心，因为它与项目 ID 相关...