移动应用回滚平台指南

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

目录

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

1. Capgo

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

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

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

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

弱连接下，bundle大小与修复速度有关。一个完整的bundle可能比一个小的补丁需要更长的时间。差异性传输可以减小下载大小，使紧急修复更快地到达用户。

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

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

安全性也需要同样的关注。审查Capgo的 __CAPGO_KEEP_0__的 __CAPGO_KEEP_0__的

Capgo的 __CAPGO_KEEP_0__的 __CAPGO_KEEP_0__的

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天的免费试用期，所以你可以在测试发布流程之前将其纳入你的过程中。

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

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

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

回滚计划只有在你的发布管道可以发布已知的良好包时才会生效。连接移动应用回滚平台到源代码控制、测试和部署命令之前发生的第一次事件。对于 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.

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

1. 安装锁定的依赖项。
2. 运行类型检查和单元测试。
3. 构建 web 资产。
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：配置和测试自动回滚

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

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

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

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

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

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

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

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

至少进行三次演练：

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

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

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

详细的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插件、权限或依赖项更改仍然需要新的商店发布。

How does automatic rollback work?

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

What should I monitor after an OTA update?

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

Does OTA replace App Store review?

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团队需要一个发布路径时进行差异更新 differential updateschannels、分析、CI/CD和回滚。开始14天的免费试用，连接一个测试项目，运行一个阶段的发布，然后将生产流量转移到那里。这个小练习会显示你的团队是否可以通过不猜测的方式跟踪、采用、暂停和回滚。