跳过主要内容
教程

Capgo 环境最佳实践:使用Capgo频道进行一款移动应用的分级

使用Capgo频道来避免重复的应用ID和脆弱的运行时标志,实现Capacitor应用的分级、QA和生产环境

马丁·多纳迪厄

马丁·多纳迪厄

内容营销

Capgo 环境最佳实践:使用Capgo频道进行一款移动应用的分级

团队通常会选择三种移动环境的方法之一:

  1. 两种应用ID(生产环境+预发布环境)
  2. 一款应用ID+动态运行时环境切换
  3. 一款应用ID+Capgo频道

首先两个可以工作,但它们会产生长期的摩擦。在实际团队中,Capgo 通道模型通常是最干净的。

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

使用 com.myappcom.myapp.beta 看起来很简单,但你很快就会出现重复:

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

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

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

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

直到出现问题:

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

随着每个发布的增加,这种复杂性会增长,团队的速度也会减慢

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 forever. You do JS/CSS/asset updates there repeatedly through Capgo without publishing a new native app.

: 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

测试环境中使用Capgo通道

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
});

这不是必须的。许多团队使用仪表板中的通道分配,并且只在内部用户中切换通道,而不是所有客户。

运营检查表

  • 仅使用一个应用ID(无重复的生产/测试ID)
  • 一个原生构建管道基线
  • 频道映射文档(staging, beta, production, hotfix)
  • CI/CD 中推动路径
  • 仅在真实原生变化时重建原生
  • 定期测试回滚

实用益处

这种方法可以移除环境漂移,减少构建混乱,提高修复速度:

  • QA 可以获得真实的二进制文件(不再使用假的“测试应用”身份),
  • 您的 TestFlight 路径保持稳定
  • 您的团队避免了“两个应用 ID 债务”,
  • you can push many JS-only fixes through Capgo quickly.

最终结果是更简单的治理: fewer artifacts,cleaner telemetry,和 fewer surprises 在发布操作中。

继续阅读Capgo环境最佳实践:使用一个移动应用ID进行分阶段部署

如果您正在使用 Capgo环境最佳实践:使用一个移动应用ID进行分阶段部署 与__CAPGO_KEEP_0__环境最佳实践:使用一个移动应用ID进行分阶段部署 __CAPGO_KEEP_1__ __CAPGO_KEEP_1__ __CAPGO_KEEP_1__ __CAPGO_KEEP_1__ __CAPGO_KEEP_1__ __CAPGO_KEEP_1__ __CAPGO_KEEP_1__ __CAPGO_KEEP_1__ 版本目标解决方案 用于版本目标解决方案的产品工作流。

实时更新 Capacitor 应用

When a web-layer bug is live, ship the fix through Capgo instead of waiting days for app store approval. Users get the update in the background while native changes stay in the normal review path.

当 web 层 bug 活跃时,通过 __CAPGO_KEEP_0__ 发送修复,而不是等待几天的 app store 审核。用户在后台接收更新,而原生更改仍在正常的审查路径中。

上下文:Capgo 市场网站。角色:支持描述段落或元描述。见于:组件 GetStarted.astro。保留 Capgo 产品/品牌和开发者术语的原始形式。信息键 `instant_updates_for_capacitor_apps_description` (Capacitor 应用实时更新描述)。

人工支持从 Martin

Capgo gives you the best insights you need to create a truly professional mobile app.