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

Teams通常选择其中一种移动环境的方法：

Two app IDs（生产环境+预发布环境）
One app ID + 动态运行时环境切换
One app ID + Capgo 通道

前两种方法可以工作，但它们会产生长期的摩擦。在实际团队中，Capgo 通道模型通常是最干净的。

为什么会出现重复的app ID

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

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

您最终需要管理两个产品，分别在商店控制台、团队和内部QA指南中

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

“一套应用ID + 运行时切换”模式通常意味着您的应用程序在启动时读取环境变量或标志并动态重新路由API、密钥和更新行为

这有效直到

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

这种复杂性随着每个发布而增长，并且是团队失去速度的地方

Capgo 的方式：一个应用ID，多个频道

Capgo 通过频道使环境控制显式

保持一个生产应用 ID 在 App Store / Play 中。
将一个原生二进制文件发布到“shell”（直到原生更改需要重新构建为止）。
通过通道而不是重复应用标识来路由行为。

在实践中，这意味着：

production: 所有用户
staging: 内部 QA 和发布候选人
beta: 邀请的测试者
hotfix: 紧急修补轨迹

您的 TestFlight/Play 内部测试应用可以保持在 staging forever。您可以在那里反复通过 Capgo 更新 JS/CSS/资产而不发布新的原生应用。

在实践中推荐的结构

1) 原生发布基线

Your last native binary stays the same for many JS iterations:

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

You only rebuild the native binary when you actually changed native surface area.

2) 使用专门的渠道

发布更新使用渠道：

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

测试QA，修复问题，然后推广：

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 构建可以与预生产更新相关联：

不频繁提交每个 JS 变更的本机提交。
QA 始终通过渠道验证近生产 code。
生产用户只接收推广的生产渠道包。

4) 只在受控工作流中使用渠道切换

For advanced teams, expose controlled channel switches for QA/admin users:

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

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

This is optional. Most teams use channel assignments from the dashboard and only switch channel for internal users, not all customers.

运维检查表

仅有一套应用 ID（无重复的生产/测试 ID）
仅有一套原生构建管道
渠道映射文档（staging, beta, production, hotfix)
CI/CD 中的推广路径被强制执行
仅在原生代码发生变化时重建原生
回滚测试频繁

实用益处

这种方法可以消除环境漂移，减少构建频率，提高修复速度：

QA 可以获得真实的二进制文件（无假的“测试应用”身份）
你的 TestFlight 路径保持稳定，
你的团队避免了 “两个 app ID 债务”，
你可以快速推送很多 JS-only 修复：Capgo

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

继续阅读 Capgo 环境最佳实践：使用一个移动应用 ID 进行分期

如果你正在使用 Capgo 环境最佳实践：使用一个移动应用 ID 进行分期 来规划通道路由和分阶段发布，连接它与 Channels Channels Channels Channels 频道关于频道的实现细节 Beta 测试解决方案关于 Beta 测试解决方案的产品工作流程版本目标解决方案关于版本目标解决方案的产品工作流程

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