移动应用回滚平台指南

一个坏的移动更新可能会在您的团队意识到问题之前影响用户。应用商店发布也无法像Web发布那样被撤回。正确的回滚设置为您提供了一个更安全的路径：发布小的更改、实时监控信号并使用一个命令恢复一个已知的良好包。这份指南展示了如何评估并运行该过程使用 Capgo.

1. Capgo

Capgo 是一个 OTA 更新和回滚平台，支持 Capacitor 应用。它让我们可以在不等待新商店审查的情况下发布 web 层变化，然后通过通道和阶段发布控制谁接收每个包。

Capgo 首页截图

关键点是适合。一个Capacitor应用程序具有本机外壳加上Web层。 OTA更新可以改变Web层，而本机更改仍然需要一个新的iOS或Android构建。Capgo是围绕这个分离而构建的，所以您的发布计划可以以正确的方式处理每种类型的更改。

Capgo将四个组件带入同一个工作流程：

自动回滚： 应用程序可以在发布失败其健康检查时返回一个稳定的捆绑包。
差异更新： 用户只下载捆绑包的更改部分，这样可以节省带宽使用。
CI/CD集成： 团队可以将GitHub Actions、GitLab CI或Jenkins连接到发布。
实时分析： 发布团队可以监控捆绑包传播的采用率和应用程序健康状况。

弱连接下，混合包的大小对下载速度有很大影响。一个完整的包可能比一个小的补丁包下载时间长得多。差异性传输可以让下载包更小，从而使紧急修复更快地到达用户。

Capgo 还支持一键部署。在实践中，这意味着一个构建任务可以发布一个经过测试的包，而不需要开发人员打开控制台并手动重复发布步骤。将命令保留在管道中，检查输出，然后让您的频道规则控制发布。

在发布之前，设置一个清晰的稳定版本。为它分配一个您的团队可以识别的发布ID。将相关的提交、构建笔记和测试结果存储在该ID旁边。如果您需要在凌晨2点恢复，您不想猜测哪个包是安全的。

安全性也需要同样的关注。查看Capgo的 Trust information for over-the-air updates before you set access rules. Then decide which team members can publish, pause, or roll back a production channel.

For teams that need a preview before production, a pull request can map to its own channel. That keeps a tester’s bundle away from the main release path. Capgo’s PR Preview Channels can support that kind of review flow.

Mobile app rollback platform with staged release channels

Capgo 是一个强大的起点，当您的应用使用 Capacitor 或 Ionic 时，且您希望在一个组织订阅中实现回滚、小型更新包、CI/CD 和分析。它不会取代更改权限、原生插件或应用壳时的原生商店发布。这个界限应该从第一天就存在于您的发布策略中。

第 2 步：根据功能比较回滚平台

为了评估移动应用回滚平台，比较恢复路径而不是功能列表。问问在用户那里遇到坏包时会发生什么，设备下载的数据量有多少，是否可以在不需要手动工作的情况下发布管道。

以下表格使用这些问题。

选项	回滚路径	差异更新	CI/CD 集成	适用程度
Capgo	上下文	HTML 文本片段来自 Capgo UI 的更长字符串（父级键 `submitting_a_pr_to_capgo`）。页面/区域：Capgo 市场网站。角色：网站副本句子。见于：页面 contributing.astro。保留 Capgo 产品/品牌和开发人员术语的原始形式。消息键 `submitting_a_pr_to_capgo`（提交 PR 到 Capgo）。	GitHub 动作, GitLab CI, Jenkins	Capacitor 和 Ionic 团队希望有一个发布流程
Appflow	可以立即恢复之前的版本	否	—	正在计划迁移的现有用户
Expo Updates	手动回滚到较早的渠道更新	否	仅原生集成	Expo 和 React Native 项目
Shorebird	恢复到上一个补丁或原始二进制文件	是	—	Flutter 团队
CodePush	在一个时间窗口内基于崩溃的自动回滚	否	仅原生集成	维护社区 CodePush 部署的团队
EAS Update	回滚到一个前置频道	否	仅原生集成	React Native团队已经使用EAS
手动更新	需要新商店评论	否	—	没有OTA层的应用

栈适应优先。Expo Updates和EAS Update属于React Native讨论。Shorebird属于Flutter讨论。Capacitor团队应该避免选择工具仅仅因为它的回滚语言听起来熟悉。运行时决定了工具可以安全地改变什么。

接下来，查看更新大小。研究比较了Shorebird补丁包大小约为50到200KB，与Flutter全量发布大小约为15到30MB相比。对于移动数据用户来说，这是一个很大的差异。Capgo将相同的基本思想应用于Capacitor应用的web层更新通过差异性传输。

分析也是一个分界线。回滚按钮告诉你如何行动。实时分析则告诉你何时行动。没有发布级别的数据，团队可能会等待支持票才能发现更新失败。这种延迟会将小问题转化为更大的事件。

Expo支持CI/CD工作流和性能指标通过其Observe服务。比较应该遵循你的运行时，而不是一个通用的评分。

成本也需要更广泛的视角。低的入门价格可能看起来很好，但一旦你添加了一个单独的分析工具、一个自定义回滚脚本、存储、警报和工程时间，它们的价格就会变得很高。Capgo使用每个组织的订阅，并包括14天的免费试用期，所以你可以在测试发布流程之前将其纳入你的过程中。

最后一步：检查供应商的变化。即使供应商不再销售新计划，仍然可以为当前用户工作，但这会创建一个未来的迁移任务。将供应商状态放在技术能力旁边你的评估表格中。

关键点: 选择匹配你的运行时并为团队提供测试恢复路径的平台，而不是具有最长功能列表的平台。

步骤 3：连接平台到你的构建和 CI/CD pipeline

回滚计划只有在你的发布管道可以发布已知的良好包装时才会起作用。将移动应用回滚平台连接到源代码控制、测试和部署命令之前的第一次事件。对于实用的 CI/CD 工作流中的回滚策略将管道故障映射到明确的停止、暂停或恢复动作。

首先将本机构建与 web 层次发布分开。一个本机构建会改变应用二进制。一个 OTA 包会改变 code 已经可以运行的安装二进制。将这个规则写入管道，以便本机依赖项永远不会意外地进入 OTA 发布中。

然后设置一个发布作业，具有固定阶段的少数个数：

安装锁定的依赖项。
运行类型检查和单元测试。
构建 web 资产。
运行应用程序的烟雾测试。
将捆绑包发布到非生产渠道。
将测试的捆绑包推送到生产环境。

使用保护的机密来部署令牌。永远不要将令牌放入仓库或在作业日志中打印。为您的团队需要在暴露之前进行人工检查的生产作业分配单独的审批规则。

Capgo 与 GitHub Actions、GitLab CI 和 Jenkins 进行连接。具体的运行器并不重要，重要的是发布协议。作业应该知道它构建了哪个提交，目标渠道是什么，以及哪个版本可以替换它。

对于新项目，保持第一个管道简单。将其应用于每个发布候选人。将捆绑包发布到测试渠道。确认应用程序下载了捆绑包，启动正常，并报告就绪。只有在确认应用程序正常工作后，才应该将作业推送到生产环境。

Capacitor 团队经常使用通用 CI 运行器进行 lint 和测试，然后将原生构建移动到专门的移动服务。这种分离可以很好地工作。它将快速检查放在每个 pull 请求附近，而将签名和商店构建留给专门用于移动工作的系统。

研究表明 Capacitor CI/CD 的关键区别在于通用运行器和移动专家之间：通用运行器给你更多的控制权，但你必须自己编写管道。专门的服务可以减少设置工作量，当你需要管理签名、原生构建或实时更新时。您可以在您的团队正在处理这些选择时查看发布指南查看发布指南

现在测试失败路径。打断一个烟雾测试并确认发布步骤停止。将一个包发送到非生产项目的错误频道并确认生产环境保持不变。这些检查看起来很小，但实际事件会让管道承受压力。

到目前为止，你应该有一个可重复的工作流程，可以发布一个经过测试的包，识别出前一个稳定的包，并在检查失败时安全停止。这是阶段发布的基础。

步骤 4：使用频道、发布和分析进行阶段发布

频道为每个受众提供一个受控的发布路径。它们是移动应用回滚平台可以在包到达每个用户之前限制损害的主要原因。

至少设置三个频道:

预览: 开发人员和产品测试人员使用。
金丝雀: 用于小型真实用户或设备的群组。
生产: 在浸泡期后，用于全体受众。

保持频道规则清晰。预览包不应自我推广。金丝雀发布应有明确的负责人。生产环境应有暂停规则，任何一名事故团队成员都应能理解。

选择一个反映用户基数的 Canary 组。包括最新的手机以外的更多设备。设备年龄、OS 版本、网络质量和使用模式都可能影响包的行为。

小规模发布可以减少爆炸半径。如果十个用户接收到一个坏的包，团队有足够的时间来调查。如果所有用户都同时接收到它，支持队列就变成了监控系统。这不是一个好的学习发布的方式。

监控与用户损害相关的信号。单独的崩溃计数可能会因为 Canary 组的活跃而上升。将其与崩溃免费用户、失败的启动、身份验证错误和关键操作完成相结合。发布之前设置一个基线，以便团队知道发生了什么变化。

当一个信号超过您同意的限制时，暂停。不要等待完美的诊断。第一步是隔离。回滚通道或停止推广。然后检查日志并将失败的发布与最后一个稳定提交进行比较。

分阶段的移动应用程序发布，使用通道和实时分析

OTA 有限制。它不能添加原生插件、改变权限或替换原生依赖项。它也 shouldn't 用于推送需要商店审查的主要功能。使用商店发布进行这些更改，然后使用 OTA 进行适合安装的二进制的 web层修复。

对于企业应用程序，添加设备组。一个仓库设备可能需要一个不同的发布速度，而一个办公电话可能需要一个不同的发布速度。一个现场团队可能会与网络连接不佳。这些组不应该被视为一个测试池。

Capgo的频道模型支持这种分离。跟踪、采用、回滚。这种短循环在发布者可以看到哪个频道持有每个捆绑包时更容易运行。

每次推广都要保留发布说明。记录变更的原因、预期用户效果以及允许下一个阶段的信号。这个说明会为支持和产品团队提供一个共享答案，当用户询问变更内容时。

专业提示： 使暂停权限比推广权限更广泛。支持负责人应该能够在等待原始开发人员之前停止一个风险滚动。

步骤5：配置和测试自动回滚

自动回滚会将健康信号转换为恢复动作。为了安全使用它，定义信号、时间窗口和稳定版本在发布日之前。详细的 Capacitor更新的回滚配置也会帮助团队将这些规则连接到阶段性测试。

从已知的良好捆绑包开始。只有在它通过了烟雾测试和短期生产浸泡后才标记为稳定。将其发布ID保存在部署记录中。一个回滚系统如果自身的fallback未经测试也是无用的。

接下来，选择应该触发动作的错误。好候选者是：

安装后应用程序崩溃的急剧上升。
应用程序启动时反复失败。
A登录或数据加载路径出现问题。
A关键用户操作量大幅下降。
完整性或包验证失败。

在安装后设置一个时间窗口。一些bug在首次启动时出现，另一些bug只有在用户达到某个屏幕时才会出现。您的时间窗口应该覆盖应用中最重要的路径。

然后决定系统的行为。它可能会先暂停推广。它可能会将受影响的渠道回滚到最后一个稳定包。对于严重的故障，可能需要同时执行这两种操作。将顺序写下来，并在一个安全渠道中测试它，使用一个故意发布的坏版本。

移动回滚与web回滚不同。一个已经安装在手机上的商店二进制文件不能简单地消失。一个新的本机修复可能需要商店的审查。OTA回滚在安装的本机shell可以运行的code内工作。

这是为什么回滚应该与功能标志和良好的发布测试一起使用的原因。如果一个功能可以在不替换包的情况下关闭，那么这可能比回滚整个发布更安全。

至少进行三个演练:

发布一个不通过就绪检查的包。
在安装后触发一个受控错误。
确认应用返回到稳定包并报告就绪。

每个演练都要计时。测量从检测问题、暂停暴露、恢复稳定版本并确认恢复所需的时间。这个数字给您的团队提供了一个有用的事件目标。

保持手动控制。自动化可能会误判短暂的网络中断为应用程序故障。发布者应该能够暂停自动操作、检查信号并在安全时选择向前的修复。

详细的Capacitor回滚步骤，请参阅 Capgo回滚管理指南涵盖了捆绑包选择、更新应用程序、准备检查和阶段性测试。

使用自动回滚进行快速隔离，而不是作为放松审查的许可。最安全的系统能够早期捕获坏的发布并为工程师提供清晰的修复根源的方式。

第 6 步：在发布后操作回滚平台

移动应用程序回滚平台需要在发布后进行的运营程序。有人必须监视发布、决定何时暂停它，并保持恢复路径。

在首次生产发布之前，分配明确的角色：

发布者： 推广捆绑包并记录更改。
事件负责人： 决定是否暂停、回滚或向前滚动。
支持负责人： 监控用户反馈并分享常见症状。
工程负责人： 追踪问题并准备修复。

在发布后定期查看仪表盘。首先检查早期采用情况。然后检查崩溃、启动时间、失败的请求和主要用户操作。即使在十分钟后发布看起来正常，也可能在用户达到较少使用的流程时失败。

对于较大的舰队使用环形发布。第一个环应该包含各种设备模型和网络条件。不要只填充开发人员的新手机。测试组不会显示用户面临的问题，包括旧硬件或有限存储的用户。

对于企业部署，映射通道到业务风险。用于派送或支付的设备需要更紧密的门控，而用于内部新闻的设备则需要更松散的门控。将恢复设备放在发布组外，以便操作员在事故期间仍然可以访问管理工具。

发布控制的一部分是沟通。告诉支持人员发生了什么变化。给他们发布ID和症状以记录。如果您暂停发布，说明下一次检查时间。清晰的笔记可以减少重复报告并防止在压力下进行随机更改的团队。

每次回滚后都要审查。问一下是什么捕捉到了问题，什么错过了问题，以及触发器是否及时触发。然后更新测试用例或阈值。回滚在事故期间有用，作为下一次发布的证据时也有用。

保持旧的捆绑包只需与您的政策需要的时间。太多版本会使选择变得困难。太少的版本会移除您的fallback。设置一个保留规则，并在稳定版本中标记稳定版本，以便新团队成员可以理解。

访问控制也很重要。限制生产发布。要求对高风险变更进行第二次审查。记录审计记录，谁推动或撤销了捆绑包。Capgo团队还可以审查 Capgo数据政策当他们记录如何处理发布数据时。

最后，安排一次恢复演练。使用测试频道和无害故障。让没有构建发布的人遵循runbook。如果那个人可以暂停发布并恢复稳定捆绑包，过程就足够清晰了，以便处理真正的事件。

目标是平凡的发布。快速时安全的变更。谨慎时信号不明。自动化时规则已知。

常见问题

What is the best mobile app rollback platform for Capacitor?

Capgo is a strong fit for Capacitor and Ionic teams that need OTA updates with rollback control. It combines automatic rollback, differential update support, CI/CD integration, and real-time analytics under a subscription per organization. It also includes a 14-day free trial, so your team can test the release path before using it in production.

__CAPGO_KEEP_0是适合CAPGO_KEEP_1__和Ionic团队的强大选择，需要OTA更新和回滚控制。它结合了自动回滚、差异更新支持、CI/CD集成和实时分析，且以组织订阅的形式提供。它还包括14天的免费试用期，因此您的团队可以在生产环境中测试发布路径之前测试发布路径。

移动应用程序可以回滚OTA web层捆绑包，但它们无法擦除通过应用商店安装的本机二进制文件。回滚成功时，已安装的本机shell可以运行较早的捆绑包。native插件、权限或依赖项的更改仍然需要新的商店发布。

自动回滚如何工作?

自动回滚会监视安装捆绑包后健康信号。如果发布跨越了设置的失败规则，系统可以停止推广并将受影响的渠道恢复到稳定捆绑包。测试触发器时，请先使用安全渠道。短暂网络问题可能会导致不必要的恢复工作。

OTA更新后我应该监控什么?

监控无崩溃用户、失败的启动、登录错误、数据加载失败和主应用程序的主要动作。将每个信号与其预发布基线进行比较。突然下降即使原始数字看起来很小也很重要。请在扩大发布之前监控 Canary 渠道。

OTA是否可以替代App Store评审?

OTA does not replace App Store review for native changes or major app features. It can update compatible web-layer code inside the installed native shell. Use a store release when you change permissions, native modules, or native configuration. Keep that boundary in your CI/CD rules.

结论

选择Capgo时，Capacitor或Ionic团队需要一个发布路径时差异更新、渠道、分析、CI/CD 和回滚。开始 14 天免费试用，连接一个测试项目，并在移动生产流量之前运行一个阶段发布。这个小练习将显示您的团队是否可以通过不猜测来跟踪、采用、暂停和回滚。