天气
Windy.com - 天气预报
该天气应用程序需要在地图、警报和导航修复方面进行谨慎的生产扩展。
- Google Play 安装
- 32.9万
- 商店评分
- 4.7
问题
发布商店更新是一个缓慢的方式来发布一个小的修复
商店仅修复路径
1
找到错误
监控或支持报告屏幕破裂。修复是一个几行的 JavaScript 或 CSS
2
构建一个新二进制
您将版本号提升，针对 iOS 和 Android 构建，并准备两个商店提交
3
等待审批
审批商店通常需要 24-48 小时，有时更长。拒绝会重新开始等待
4
等待用户更新
批准后，每个用户仍然需要安装新版本。直到那时，他们仍然运行旧的 code
每一步都增加了修复就绪和修复在用户设备上运行之间的时间。
为什么修复到用户慢慢到达
24–48小时
典型的商店评论时间
苹果和谷歌会审查每个新二进制文件。审查通常需要24–48小时，有时更长，拒绝意味着重新提交。
每个用户
商店更新取决于每个设备
只有当用户或他们的自动更新设置安装它时，商店更新才会到达设备。一些设备会在很长时间内保持旧版本。
2个商店
每个修复都需要两次提交
同样的web修复需要通过App Store和Google Play分别审查和发布。
如何工作
如何生产团队使用Capgo发布修复
一个典型的发布版本Capacitor应用已经在商店中。以下每个命令都是从CapgoCLI文档中获取的。
-
设置更新器一次
运行设置向导，然后确保您的应用在启动时调用notifyAppReady()。从未调用该方法的捆绑包会自动回滚。
notifyAppReady()文档npx @capgo/cli@latest init # in your app start-up code await CapacitorUpdater.notifyAppReady() -
上传修复到生产切片
使用--delta使设备只下载更改的文件，--rollout从小比例开始。其他人仍在稳定捆绑包中。
渐进式发布文档npx @capgo/cli@latest bundle upload --channel production --delta --rollout 5 -
让Capgo停止一个坏的发布
设置失败率阈值（500基点是5%）后，Capgo会自动暂停。如果失败率超过阈值，Capgo会回滚发布。您可以在观察中查看新版本。
观察文档npx @capgo/cli@latest channel set production \ --auto-pause-enabled \ --auto-pause-failure-rate-bps 500 \ --auto-pause-action rollback -
推广到所有人
当数字看起来正确时，推广包到每个设备上。如果不正确，回滚发布分组到稳定版本。
回滚文档npx @capgo/cli@latest channel set production --rollout-promote # or, if something looks wrong npx @capgo/cli@latest channel set production --rollout-rollback
为生产发布而设计
生产团队使用的控制生产发布的工具，通常不会惊讶用户
delta更新
上传使用--delta并且设备只下载自从他们当前捆绑的文件改变过的文件。 大型资产很少改变只下载一次
- 用户在慢速或计量网络上下载的文件更小
- 在默认模式下，更新在会话之间应用，而不是在会话中间
--delta
只下载改变过的文件
渐进式发布
将新版本发送到一个随机的、粘性共享的频道中，而其他人则继续使用稳定版本。您可以增加百分比、推广它或从CLI或控制台中回滚。
- 自动暂停可以在失败率超过阈值时暂停或回滚发布
- 观察将新版本与之前的版本进行比较，直到您提高暴露度
1–5%
典型的首次发布步骤
自动回滚
每次更新都必须证明它起作用。如果新版本在规定时间内没有调用notifyAppReady()，设备将切回最后一个工作版本，并标记新版本为失败
- 回滚触发器如果notifyAppReady()在appReadyTimeout（默认10秒）内没有被调用
- 将整个频道回滚到其历史中的任何较早版本
10秒
默认应用就绪超时之前的自动回滚
商店评论感知的交付
CapgoCapgo提供了Capacitor的Web层：JavaScript、CSS和资产。它不会改变原生二进制、插件、权限、特权或应用商店元数据。商店评论是应用特有的，因此您仍然负责遵守政策和获得批准。
- 在原生能力、插件、权限或应用商店元数据发生变化时，使用原生商店发布
- 保持评审者对应用的预期功能和Web层更新路径的注释清晰
- 在每次提交之前，查看当前的Apple和Google政策
生产团队如何使用它
日常发布工作一旦实时更新就位。每个卡片都链接到文档。
现有的基础设施
Capgo已于2021年开始为生产应用程序提供实时更新。
- 每月更新
- 10亿+
- 已覆盖的设备
- 9亿+
- 使用Capgo的应用程序
- 4.7万+
- Typical API 时延
- translations
translations
translations
使用Capacitor构建的应用
高流量应用需要在生产环境中可靠地更新UI
天气、公共卫生和电信应用依赖准确的界面、警报和导航。生产更新有助于在监测采用率之前扩大审批的界面修复。
天气
医疗
连接服务
该公共卫生应用程序需要快速、可信的更新来提供指导和服务信息。
- Google Play 安装
- 2.77亿
- 商店评分
- 4.6
工具
小米橙子
电信账户应用，警报和账户面板频繁更改。
- 谷歌Play安装
- 9300万
- 商店评分
- 4.2
肖像 Sergiu S
驱动线 GmbH 的 Sergiu S
“Capgo Capacitor 更新器插件彻底改变了我们发布更新的方式。过去的几天现在只需要几分钟。”
Kapil
NuTriQ 创始人
“能立即推送生产 OTA 更新，无需等待完整 App Store 审核周期，这对我们来说是一个巨大的运营优势.”
Portrait of Michael Haberler
nethead emeritors
“更新插件工作非常顺畅，对于我来说，live 更新是一个快速测试回归的超级加速器.”
常见问题
生产团队常问的问题
更新如何到达设备，何时发生错误?
用户何时会获得一个live update?
默认情况下，应用程序在前台时检查更新，并在每 10 分钟的时间段内检查更新。它在后台下载新包，安装它时用户离开应用，下一次打开时运行它。autoUpdate 设置会改变此行为。
更新行为文档
设备是否能更快接收紧急修复?
是的。您更改一个频道的包后，通过控制台发送更新通知，或者在上传包时添加 --send-update-notification，设备会立即接收到静默推送并检查。这需要 Capgo 通知，包括 iOS 和 Android 推送凭据。交付是最佳努力：离线或强制退出的应用在下一次启动时会检查。
发送更新通知
如果更新破坏了应用程序，会发生什么?
如果新包在 10 秒内（默认值 appReadyTimeout）没有调用 notifyAppReady()，设备会返回到最后一个工作包并标记新包为失败。对于不阻止应用程序启动的 bug，可以回滚进展式发布或从频道历史中选择一个较早的包。
回滚文档
设备是否能更快接收紧急修复?
上传时使用 --rollout 可以将包发送到一个随机、粘性的频道分数，而其他人仍在稳定状态。提高百分比、推广或从 CLI 或控制台回滚。自动暂停可以在失败率超过阈值时停止暴露。
进展式发布文档
什么不能改变live update
Live updates replace the web layer: JavaScript, HTML, CSS, and assets. Native plugins, Capacitor upgrades, capacitor.config changes, and iOS or Android project files need a store release. Capgo checks bundles for native compatibility on upload, and channels can block updates to older binaries.
原生兼容性文档