Google Play安卓应用CI/RC构建包发布方案最佳实践咨询

该场景下的行业通用最佳实践是选择第二种方案：将CI构建产出的安装包上传至现有「MyApp」的Internal Testing轨道，非必要不新建独立的MyAppTest测试应用。

优先选择Internal Testing轨道的核心原因 #

• 完全匹配Google Play的官方测试分发设计逻辑：Internal Testing轨道本身就是为高频CI构建的内部分发场景打造的，支持最多100名授权内部测试人员，包上传后通常数分钟即可完成审核推送，没有正式发布轨道的流程卡点，完全适配日常开发中CI出包、快速给测试团队验证的需求。
• 从流程上规避环境差异问题：同个应用下所有轨道的安装包必须使用和正式版一致的签名，测试包的Play服务适配、权限规则、运行环境和最终发给用户的RC正式包完全同源，不会出现独立测试包常见的「测试环境验证全过，正式版上线出bug」的配置、签名、环境不一致问题。
• 测试侧使用成本极低：测试人员只需要接受一次测试邀请，不需要单独下载另一个独立应用，后续所有CI测试包、RC版本的更新都可以通过Play Store自动推送，也不需要手动卸载重装不同包名的应用，切换测试版本的操作成本几乎为0。
• 适配你当前的版本号规则：Google Play会基于versionCode判定版本优先级，你当前CI构建的1.1.0.1版本号高于现有RC包的1.0.0-RC1，测试人员在Internal轨道会优先收到最新的CI构建包，后续RC版本迭代升级到1.1.x系列时也不会出现版本冲突。

仅在特殊场景下才考虑新建独立MyAppTest应用 #

只有当你满足以下任意一类需求时，才需要选择新建独立包名的测试应用：

• 测试包需要开放给超过Play测试轨道人数上限的外部用户，且需要和正式应用做完全的环境隔离（比如测试包默认连接测试环境后端、内置调试工具、需要和用户设备上安装的正式版MyApp同时共存）
• CI构建包包含大量仅用于开发测试的调试逻辑、敏感测试工具，完全不能和正式包共用签名、应用商店配置，且明确要求测试包和正式包数据完全隔离
  注意：独立测试应用需要单独维护包名、签名、商店上架配置，长期维护成本很高，没有上述强需求的话完全没必要选。

• 建议统一规划versionCode规则，比如正式RC版本的versionCode以1开头按版本号递增，CI构建的versionCode统一以2开头按构建序号递增，从规则上彻底避免CI测试包和正式RC包的versionCode冲突。
• Internal Testing轨道的包不会被普通外部用户搜索到，只有你主动添加到测试列表的账号才能查看、下载，不需要担心测试包泄露给正式用户的问题。

内容的提问来源于stack exchange，提问作者Xiaosu