移动应用回滚平台指南

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

目录

• Capgo
• 步骤2：通过功能比较回滚平台
• 步骤3：将平台连接到您的构建和CI/CD管道
• 步骤4：使用通道、回滚和分析阶段发布
• 步骤5：配置和测试自动回滚
• 步骤6：在发布后操作回滚平台
• 常见问题
• 结论

1. Capgo

Capgo 是一款 Ionic 和 Capacitor 应用程序的 OTA 更新和回滚平台。它让我们可以在不等待新商店审核的情况下将 web 层更改推送给用户，然后通过通道和阶段性发布控制谁接收每个捆绑包。

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

Capgo 将四个组件整合到同一个工作流中：

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

在弱信号的移动连接下，这个混合很重要。一个完整的包可能比一个小的补丁需要更长的时间。差异性传输可以使下载更小，从而使紧急修复更有可能快速到达用户。

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

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

安全性需要同样的关注。查看 Capgo 的 对线上更新的可信信息 然后决定哪些团队成员可以发布、暂停或回滚生产频道。

对于需要在生产之前预览的团队，一个拉取请求可以映射到自己的频道。这样可以将测试者的包与主发布路径分开。 Capgo 的 PR 预览频道 可以支持这种审查流程。

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

步骤 2：比较回滚平台的功能

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

以下表格使用这些问题。

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

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

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

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

成本也需要更广泛的视角。低入门价格看起来很好，直到您添加单独的分析工具、自定义回滚脚本、存储、警报和工程时间。Capgo使用组织订阅，并包括14天的免费试用期，因此您可以在将发布流程纳入您的过程之前测试发布流程。

最后一步：将平台连接到您的构建和CI/CD管道

关键 takeaway： 步骤3：连接平台到您的构建和CI/CD管道

连接平台到您的构建和CI/CD管道

只有当您的发布管道可以重新发布已知的良好包时，回滚计划才会有效。将移动应用回滚平台连接到源代码控制、测试和部署命令之前发生的第一次事件。为了实用 回滚策略将管道故障映射到明确的停止、暂停或恢复操作

Start by separating native builds from web-layer releases. A native build changes the app binary. An OTA bundle changes code that the installed binary can already run. Write this rule into your pipeline so a native dependency never slips into an OTA release by mistake.

已安装的二进制可以运行的__CAPGO_KEEP_0__。将此规则写入管道，以便原生依赖项永远不会意外地进入OTA发布

1. 然后设置一个固定阶段的发布作业：
2. 安装锁定的依赖项
3. 运行类型检查和单元测试
4. 运行应用程序的烟雾测试。
5. 发布到非生产渠道。
6. 将测试的包推送到生产环境。

使用保护的密钥来部署令牌。永远不要将令牌放入仓库或在作业日志中打印。为您的生产作业设置单独的审批规则，如果您的团队需要在发布前进行人工检查。

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

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

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

研究表明Capacitor CI/CD 的关键区别在于通用运行器和移动专家之间：通用运行器提供了更多的控制权，但您必须编写更多的管道。专门的服务可以减少设置工作量，当您需要在同一工作流中进行管理签名、原生构建或实时更新时。 查看发布指南 查看发布指南

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

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

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

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

至少设置三个频道：

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

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

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

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

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

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

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

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

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

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

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

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

context 回滚配置为Capacitor更新 自动回滚会将健康信号转换为恢复动作。为了安全使用它，定义信号、时间窗口和稳定版本在发布日之前。详细的

__CAPGO_KEEP_0__更新的回滚配置

也会帮助团队将这些规则连接到阶段测试。

• 应用安装后出现严重的崩溃率上升。
• 接下来，选择应该触发动作的错误。好候选者是：
• A登录或数据加载路径出现问题。
• A关键用户操作量大幅下降。
• 完整性或捆绑包验证失败。

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

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

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

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

至少进行三个演练:

1. 发布一个通过完整性检查失败的捆绑包。
2. 在安装后触发一个受控错误。
3. 确认应用程序返回到稳定捆绑包并报告就绪。

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

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

有关详细的Capacitor回滚步骤，请参阅关于Capacitor rollback management with Capgo 涵盖了捆绑包选择、更新应用程序、准备检查和阶段性测试。

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

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

上下文：关于Capgo页面。角色：UI标签。见于：关于.astro页面。消息键 `about_how_step_label` (关于如何步骤标签)。

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

• 在第一次生产发布之前，分配明确的角色： 发布者：
• 推广捆绑包并记录更改。 事件负责人：
• 支持负责人： 监控用户反馈并分享常见症状。
• 工程负责人： 追踪问题并准备修复。

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

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

对于企业部署，映射通道到业务风险。用于派送或支付的设备需要更紧密的门控，而用于内部新闻的设备则不需要。保留一个恢复设备，操作员可以在意外情况下访问管理员工具。

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

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

保持旧版本的包只需要符合您的政策需求。太多版本会使选择变得困难。太少版本会移除您的fallback。设置一个保留规则，并在稳定发布时使用标签，使新团队成员可以理解。

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

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

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

常见问题

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.

是否真实的可以让移动应用程序回滚？

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

自动回滚是如何工作的？

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

在 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.

Conclusion

选择 Capgo 时，当您的 Capacitor 或 Ionic 团队需要一个发布路径时 差分更新开始 14 天免费试用，连接测试项目，运行一个阶段性发布，然后将生产流量转移到该平台。这个小练习将显示您的团队是否能通过无需猜测地跟踪、采用、暂停和回滚。