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

Teams通常选择三种移动环境的方法:

两个应用ID（生产+预发布）
一个应用ID+动态运行时环境切换
一个应用ID+Capgo频道

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

为什么会出现重复的应用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:

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

在实践中，这意味着：

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

您的 TestFlight/Play 内部测试应用可以永久留在那里。您可以在那里反复通过 __CAPGO_KEEP_0__ 更新 JS/CSS/资产，而无需发布新的本机应用。 staging forever. You do JS/CSS/asset updates there repeatedly through Capgo without publishing a new native app.

1) 本机发布基线

2) 每个渠道的本机二进制文件

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) 只在受控工作流中使用通道切换

对于高级团队，暴露受控的频道切换选项给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 路径保持稳定，
你的团队避免了 “两个 App ID 债务”，
你可以快速通过 Capgo 推送许多 JS-only 修复。

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

继续阅读 Capgo 环境最佳实践：使用一个移动 App ID 进行分级发布

如果你正在使用 Capgo 环境最佳实践：使用一个移动 App ID 进行分级发布 来规划通道路由和分级发布，连接它到 Channels for the implementation detail in Channels, Channels Channels 频道为频道的实现细节测试版解决方案为测试版解决方案中的产品工作流程版本定位解决方案为版本定位解决方案中的产品工作流程

Capgo 环境最佳实践：使用__CAPGO_KEEP_1__应用程序ID进行一键式环境