Capgo 环境最佳实践：使用一个移动应用 ID 进行测试

Teams usually choose one of three approaches for mobile environments:

Two app IDs (production + pre-production)
One app ID + dynamic runtime environment switching
One app ID + Capgo channels

The first two can work, but they create long-term friction. In real teams, the Capgo channel model is usually the cleanest.

为什么重复的应用 ID 会变得噪杂

使用 com.myapp 和 com.myapp.beta 看似简单，但很快就会出现重复：

两个发布管道
两个推送 ID、深度链接和权限映射
两个分析和崩溃身份
环境配置和行为不一致

最终你需要管理两个产品，涉及到商店控制台、团队和内部 QA 指南。

为什么在运行时切换配置通常会很混乱

通常情况下，'一个应用 ID + 运行时切换' 模式意味着应用在启动时读取环境变量或标志，并动态重定向 API、密钥和更新行为。

直到：

QA开始绕过预期流程，因为配置状态过时了，
有人在生产环境中使用了错误的端点，
环境漂移导致难以复现的错误，
你需要在用户设备上调试“这个二进制文件使用的配置版本是哪个？”

这种复杂性随着每次发布而增加，正是团队失去速度的地方。

The Capgo way: one app ID, many channels

Capgo makes environment control explicit through channels:

在App Store/Play中保留一个生产应用ID。
将一个原生二进制文件发送到“壳”（直到原生变化需要真正重建为止）。
通过渠道而不是重复的应用身份来路由行为。

在实践中，这意味着：

production: 所有用户
staging: 内部QA和发布候选
beta: 受邀测试者
hotfix: 紧急修复跟踪

: 你的TestFlight/Play内部测试应用可以永久留在 staging 这里。你可以在这里反复通过Capgo更新JS/CSS/资产而不发布新的原生应用。

: 实践中的推荐结构

: 1) 原生发布基线

: 你的最后一个原生二进制文件可以保持多个JS迭代不变:

bun run build
bunx cap sync
# generate Xcode/Android Studio archives as usual

: 只有当你实际改变了原生表面区域时才重建原生二进制文件。

: 2) 为环境使用专用通道

: 使用通道发布更新：

bun run build
bunx @capgo/cli deploy --channel staging

测试环境中进行测试，修复问题，然后推广：

bunx @capgo/cli promote vX.Y.Z --channel production

如果您更喜欢显式版本控制：

bunx @capgo/cli deploy vX.Y.Z --channel staging
bunx @capgo/cli promote vX.Y.Z --channel production

3) 保持 TestFlight “始终为预发布”

在 iOS 工作流中，这意味着您的 TestFlight 构建可以与预发布更新相关联：

不频繁提交本机更改。
QA 总是通过 staging 通道验证近生产环境的 code。
生产用户只接收从生产通道推广的包。

4) 仅在受控工作流中使用通道切换

对于高级团队，暴露受控的通道切换给 QA/管理员用户：

import { CapacitorUpdater } from '@capgo/capacitor-updater';

await CapacitorUpdater.setChannel({
  channel: 'staging',
  triggerAutoUpdate: true
});

这不是必须的。大多数团队从仪表板使用通道 assignments，并且仅在内部用户中切换通道，而不是所有客户。

运营检查表

仅使用一个应用 ID（无重复的生产/测试 ID）
一个基本的原生构建管道
渠道映射文档（staging, beta, production, hotfix)
CI/CD 中推广路径强制执行
仅在真实原生变化时重建原生
定期测试回滚

实用益处

这种方法移除了环境漂移，减少了构建混乱，提高了修复速度：

QA 得到现实的二进制文件（没有假的“阶段应用”身份），
您的 TestFlight 路径保持稳定
您的团队避免了“两个应用 ID 债务”，
您可以快速推送许多 JS-only 修复：Capgo。

最终结果是更简单的治理： fewer artifacts，cleaner telemetry，和发布操作中更少的惊喜。

继续遵循 Capgo 环境最佳实践：使用一个移动应用ID进行分阶段

如果您正在使用 Capgo 环境最佳实践：使用一个移动应用ID进行分阶段 来规划渠道路由和分阶段发布，连接它与渠道渠道渠道渠道 Beta 测试解决方案了解 Beta 测试解决方案中的产品工作流程 Beta Testing Solution for the product workflow in Beta Testing Solution, and 版本目标解决方案为版本目标解决方案中的产品工作流程

Capgo Environment Best Practices: Staging with One Mobile App ID