跳转至正文
生产环境更新

让所有用户都用上最新修复

通过 CLI 或 CI 上传新的 web bundle。设备会在后台下载，并在下次应用回到前台时运行。按百分比发布，在 Observe 中监控，出问题就回滚。

无需信用卡
内置自动回滚机制
仅限 Web 层更新

问题

通过应用商店发布来修复小问题，效率实在太低

仅依赖应用商店的修复路径

1

定位 Bug

监控或客服反馈页面显示异常。而修复方案仅需几行 JavaScript 或 CSS。

2

构建新的二进制文件

你需要升级版本号，分别为 iOS 和 Android 构建，并准备两次商店提交。

3

等待审核

商店审核通常需要 24–48 小时，有时甚至更久。一旦被拒，等待又要重新开始。

4

等待用户更新

即使审核通过，用户仍需手动安装新版本。在此之前，他们运行的仍是旧版 code。

每一步都会拉长从修复完成到修复在用户设备上生效的时间。

为什么商店修复方案无法快速触达用户

24–48h+

典型的应用商店审核时间

Apple 和 Google 会审核每一个新的二进制文件。审核通常需要 24–48 小时，有时甚至更久，一旦被拒就必须重新提交。

每位用户

商店更新取决于各台设备

只有当用户或其自动更新设置安装时，商店更新才会到达设备。部分设备可能会长期停留在旧版本上。

2 个商店

每次修复都需要两次提交

同一个 Web 修复需要分别通过 App Store 和 Google Play，且各自都有独立的审核和发布流程。

解决方案

live update 如何触达用户

这是 Capgo 的默认更新行为。无需更新提示，无需强制重启，针对 Web 层变更也无需提交商店审核。

默认更新流程

  1. App 会检查更新

    当 App 进入前台时，以及在保持打开状态下的每 10 分钟，updater 都会向 Capgo 请求该 channel 的最新 bundle。

    进入前台时

  2. 在后台进行下载

    用户继续使用当前版本时，新 bundle 会在后台下载。通过 delta updates，仅下载发生变化的文件。

    无感中断

  3. 下次恢复时切换

    当用户退出 App 时，updater 会安装该 bundle。下次打开时，用户即可运行新版本。

    下次进入前台时

需要用户在打开 App 时立即看到新版本？Direct update 模式会在显示 splash screen 时于启动阶段应用更新。

了解 direct updates

更新行为文档

工作原理

生产团队如何使用 Capgo 发布修复

针对已上架商店的 Capacitor 应用进行典型发布。以下所有命令均来自 Capgo CLI 文档。

  1. 一次性配置更新器

    运行设置向导，并确保您的应用在启动后调用 notifyAppReady()。如果 bundle 未能调用该方法，则会自动回滚。

    npx @capgo/cli@latest init
# in your app start-up code
await CapacitorUpdater.notifyAppReady()
    notifyAppReady() 文档

  2. 将修复程序上传至生产环境切片

    使用 --delta 让设备仅获取变更文件，并使用 --rollout 从少量设备开始。其余用户将继续使用稳定的 bundle。

    npx @capgo/cli@latest bundle upload --channel production --delta --rollout 5
    渐进式发布文档

  3. 让 Capgo 拦截错误的 rollout

    通过设置失败率阈值来开启自动暂停（500 个基点即 5%）。如果失败率超过阈值，Capgo 会回滚 rollout。在运行期间可以通过 Observe 查看新版本情况。

    npx @capgo/cli@latest channel set production \
  --auto-pause-enabled \
  --auto-pause-failure-rate-bps 500 \
  --auto-pause-action rollback
    Observe 文档

  4. 向全量用户发布

    当各项指标符合预期时，将 bundle 推送到该 channel 下的所有设备。若指标异常，则将灰度版本回滚至 stable。

    npx @capgo/cli@latest channel set production --rollout-promote
# or, if something looks wrong
npx @capgo/cli@latest channel set production --rollout-rollback
    回滚文档

专为生产环境发布打造

生产团队用来频繁发布、又不会让用户感到意外的控制手段。

增量更新

使用 --delta 上传，设备只下载自当前 bundle 以来发生变化的文件。很少变动的大型资源只需下载一次。

  • 为慢速或按流量计费网络上的用户减少下载量
  • 在默认模式下，更新会在会话之间应用，而不是在会话进行中应用。
Delta 更新文档

--delta

仅下载变更的文件

支持自动暂停的渐进式发布

将新 bundle 发送给 channel 中随机且固定的一部分用户，其他人继续使用稳定版 bundle。你可以通过 CLI 或控制台提高比例、正式发布或回滚。

  • 当失败率超过设定的阈值时，Auto-pause 可以自动暂停或回滚发布进度
  • 在扩大曝光范围之前，Observe 会将新版本与旧版本进行对比
渐进式发布文档

1–5%

典型的首次发布步骤

自动回滚

每次更新都必须证明其已成功启动。如果新的 bundle 未能及时调用 notifyAppReady()，设备将回退到上一个可用的 bundle，并将新 bundle 标记为失败。

  • 如果未在 appReadyTimeout（默认 10 秒）内调用 notifyAppReady()，则触发回滚
  • 将整个 channel 回滚至历史记录中的任何早期 bundle
notifyAppReady() 文档

10s

自动回滚前的默认 appReadyTimeout

适配应用商店审核机制的发布

Capgo 交付的是 Capacitor Web 层：包括 JavaScript、CSS 和资源文件。它不会更改 Native Build、插件、权限、Entitlements 或 App Store 元数据。应用审核是针对 App 本身的，因此您仍需负责遵守政策并确保通过审核。

  • 当原生能力、插件、权限或 App Store 元数据发生变化时，请使用原生商店版本发布
  • 在审核备注中清晰说明 App 的预期功能及 Web 层更新路径
  • 在每次提交前请检查最新的 Apple 和 Google 政策

生产团队的使用场景

部署 Live Update 后的日常发布工作。每个卡片均链接至文档。

关键 Bug 修复

支付或登录界面出现故障时，可通过 Web 层进行修复。只需上传修复包，设备在下次检查更新时即可自动获取。

更新行为文档

文案与内容变更

无需构建新的二进制文件，即可修正文案、更新帮助文本，或替换图片及其他 bundle 资源。

Native 兼容性文档

Observe 中的发布健康度

对比新旧 bundle：无故障率、启动与 WebView 耗时，以及各版本的部署标记。

Observe 文档

更新通知，加快更新采用

更改 channel 的 bundle 后，发送静默更新通知，让设备立即检查更新，而非等到下次进入前台。

发送更新通知

保护旧版原生构建

在 channel 上阻止主版本更新，确保需要新原生 code 的 bundle 永远不会推送到旧版二进制文件。

版本定向文档

通过 Channel 历史记录进行回滚

在 Channel 的 History 标签页中选择任何早期的 bundle，即可让该版本重新在当前 Channel 的所有设备上生效。

回滚文档

为生产级 App 提供服务的成熟基础设施

Capgo 自 2021 年以来一直为生产级 App 提供 Live Update 服务。

每月更新次数
10亿+
覆盖设备数
9000万+
使用 Capgo 的 App 数量
4700+
典型的 API 延迟
~50ms

按团队类型的解决方案

找到符合团队需求的解决方案

企业版

支持多应用、多团队部署

初创公司

快速交付，告别繁琐流程

独立开发者

14 天免费试用，CLI 即可上传

代理机构

管理多个客户应用

使用 Capacitor 构建的应用

高流量应用在生产环境中需要可靠的 UI 更新

天气、公共卫生和电信类应用依赖准确的界面、警报和导航。生产环境更新可帮助发布已审核的界面修复，同时监控采用情况，再决定是否扩大范围。

Windy.com - 天气预报应用图标 天气

Windy.com - 天气预报

天气应用需要谨慎地进行生产环境扩展，以修复地图、警报和导航问题。

Google Play 安装量
32.9M
应用商店评分
4.7
Conecte SUS 应用图标 医疗

连接 SUS

公共卫生应用需要快速、可靠的更新来发布指南和服务信息。

Google Play 安装量
27.7M
应用商店评分
4.6
Mi Orange 应用图标 工具

Mi Orange

电信账户应用，其警报和账户展示界面变更频繁。

Google Play 安装量
930 万
应用商店评分
4.2

客户证言

使用 Capgo 交付的团队怎么说

5.0/5 开发者团队评分 9,400+ 团队 查看评价
Sergiu S 的肖像

Sergiu S

drivolino GmbH 首席开发者

“Capgo Capacitor Updater 插件彻底改变了我们的更新发布方式。过去需要几天的工作，现在只需几分钟。”

Kapil

NuTriQ 创始人

“无需等待完整的 App Store 审核周期，就能即时推送生产环境的 OTA 更新，这为我们带来了巨大的运营优势。”

Michael Haberler 的肖像

Michael Haberler

nethead emeritors

“这个 updater 插件做得太棒了。它在我这儿运行完美，live updates 对快速测试迭代是极大的加速。”

常见问题

生产团队常见问题

了解更新如何到达设备，以及出现问题时该如何处理。

用户何时会收到 live update？

默认情况下，App 在进入前台时以及保持打开状态的每 10 分钟会检查一次更新。它会在后台下载新的 bundle，并在用户退出 App 时进行安装，下次打开时即可运行。autoUpdate 设置可以更改此行为。

更新行为文档

设备能否更快地获取紧急修复补丁？

可以。在更改 channel 的 bundle 后，通过控制台发送更新通知，或在 bundle upload 时添加 --send-update-notification。设备会收到一条静默推送并立即检查。这需要配合 iOS 和 Android 推送凭据使用 Capgo Notifications。交付遵循尽力而为原则：离线或被强制退出的 App 会在下次启动时进行检查。

发送更新通知

如果更新导致 App 崩溃怎么办？

如果新的 bundle 在 10 秒内（默认的 appReadyTimeout）未调用 notifyAppReady()，设备将回滚到上一个可用的 bundle，并将新的 bundle 标记为失败。对于不影响 App 启动的 Bug，请回滚渐进式发布（progressive rollout），或从 channel 历史记录中选择之前的 bundle。

回滚文档

如何先向少数用户发布？

使用 --rollout 上传，可将 bundle 推送给 channel 中随机且固定的一批用户，其他人仍留在 stable 版本。可在 CLI 或控制台提高百分比、全量发布或回滚。失败率超过阈值时，Auto-pause 会自动暂停发布，避免影响更多用户。

渐进式发布文档

live update 无法更改什么？

Live updates 替换的是 Web 层：JavaScript、HTML、CSS 和 assets。Native plugins、Capacitor 升级、capacitor.config 的更改以及 iOS 或 Android 项目文件都需要通过应用商店发布。Capgo 会在上传时检查 bundle 的原生兼容性，channel 也可以阻止旧版二进制文件获取更新。

Native 兼容性文档

将下一个修复作为 live update 发布

在试用期间，在自己的 App 上走一遍完整流程：上传一个 bundle，rollout 到几台设备，再回滚。