精英软件团队部署code 1,460次/年低效的团队部署 1.5次/年，根据 DORA的2021年加速开发运维报告。这差异约为 973倍，这改变了我们思考软件交付的方式。发布频率不是一个虚荣指标。它表明团队是否能安全地、周期性地将批准的更改转化为用户价值。
移动团队需要更精确的定义。一个Capacitor应用程序可能包含需要App Store或Play Store审查的原生code，以及一个可以独立更改的Web层。如果您仅仅测量二进制提交，您将错过用户体验的更新。实际问题不是团队如何频繁构建应用程序。问题是客户何时接收到功能改进、修复、内容更改或配置更新。
目录表格
- Release Velocity 对软件团队来说到底意味着什么
- Release Velocity 的核心指标是什么
- 二进制节奏与交付体验频率
- 实践策略来加速您的发布管道
- 如何 Capgo 为跨平台应用启用更快的发布
- 发布速度的常见误解
- 提高发布速度的行动计划
软件团队中真正的发布速度意味着什么
软件团队发布速度的实际含义 按需, 每日多次发布 按需，多次部署 低表现者每六个月部署一次，详见2022 年 DevOps 状态报告
发布速度 是团队从提交的code到实时体验的速度。这个过程包括审查、测试、打包、部署、发布、采用和恢复。快速的构建管道有助于，但它并不能自动产生快速的客户反馈环节。
为什么移动改变了计算
Web团队可以直接将JavaScript更改部署到基础设施并立即使其可用。移动团队面临着不同的依赖链。原生更改可能需要新的二进制文件、商店提交、审查、批准、发布和用户采用。团队可以快速完成修复，但仍然需要等待用户安装的应用程序能够接收它。
这对于Capacitor、Ionic和Electron团队来说很重要。他们的应用程序通常结合原生功能、HTML、CSS、JavaScript、资产和配置。将每个更改视为二进制发布会迫使简单的界面或逻辑更新通过最慢的路径。
实践规则： 测量从code更改到用户接收预期体验的时间，而不是仅仅测量从提交到构建完成的时间。
有用的运营模型将 二进制发布节奏 与 发布体验频率 . 二进制节奏告诉你团队如何高效地处理原生包装和商店合规性。发货体验频率告诉你用户接收有意义变化的频率。这种区别属于更广泛的 运营效率实践 . 因为管道可以技术上繁忙，而客户却看不到任何进展。
. 目标不是绕过平台规则或推送任意可执行行为。它是将合格的网层变化通过适合这些变化的交付机制进行路由，同时将原生功能保留在正常商店流程中。
发布速度核心指标
. 包括重工率，追踪团队花费在纠正早期变化而不是交付新价值的努力。使用 . 的指南来保持团队之间的定义一致。 . 跟踪速度和稳定性一起 . 这些指标作为一个系统工作： .
.
.
- 发布频率 衡量变化到生产环境或用户手中所需的时间。
- 变化时间 衡量从code提交到发布所需的时间。
- 变化失败率 衡量发布是否导致失败、回滚或修复的频率。
- 恢复平均时间 衡量团队恢复服务后生产故障所需的时间。
- 重做率 衡量团队在交付新价值的能力中所花费的时间比例。
移动团队需要通过交付路径来解释变化时间。JavaScript或资产变化可能已经准备好发布，而原生变化仍然在二进制管道中。将两条路径合并到一个仪表板中可能会使一个高效的团队看起来慢，并掩盖了应用商店审查瓶颈。
历史DORA等级提供了有用的词汇。精英团队可以按需发布，并且每天发布多次。高效团队从每月一次到每周一次不等，中等团队从每六个月一次到每月一次不等，低效团队每六个月发布一次或更少，根据 2022 年 DORA 报告这些等级描述了交付能力。它们不是在考虑风险、团队大小或二进制发布和实时 web 层更新之间的差异时追求的目标。
使用一个暴露权衡的仪表板
没有失败和恢复数据的发布频率图表可能会奖励冒险的批处理。没有 lead 时间的失败率图表可能会隐藏一个避免发布的团队。跨平台团队应该将原生二进制发布与 web 层更新分开，并且还要跟踪更新采用、回滚事件和重工。
| 性能等级 | 发布频率 | 变更时间 | 变更失败率 | 恢复时间 |
|---|---|---|---|---|
| 精英 | 按需，多次发布每天 | 跟踪发布流程 | 作为稳定性保护栏 | 跟踪恢复速度 |
| 高 | 每月一次到每周一次 | 跟踪与部署流程 | 作为稳定性保护栏 | 跟踪恢复速度 |
| 中 | 每六个月一次到每月一次 | 跟踪与部署流程 | 作为稳定性保护栏 | 跟踪恢复速度 |
| 低 | 六个月内不超过一次 | 跟随部署流程 | 作为稳定性基准线 | 跟踪恢复速度 |
不要为未测量的指标创建基准。建立基准，分离原生和网页层次的变化，并检查是否更快的交付也带来更小的批次、可管理的故障和更快的恢复。对于构建更广泛的工程输出视图的团队，这个 开发者生产力指南 提供了一个补充参考。
二进制节奏与发布体验频率
二进制发布是指通过商店提交的应用程序包或通过批准的桌面渠道分发的应用程序包。 发布体验频率 是指用户接收影响他们看到和做什么的变化的频率。这些指标重叠，但它们不是可互换的。
A每月二进制节奏可以与频繁的Web层交付共存。一个Capacitor团队可能保留二进制发布用于原生插件、权限、OS集成和更新器更改，而将符合条件的JavaScript、CSS、复制、配置和资产更新通过受控的实时更新路径发送。二进制数字描述了打包工作。体验数字描述了产品迭代。
为什么一个移动电话号码不够
应用商店评论引入了延迟，后端团队在同样的方式上面不会遇到。 Digia的移动发布速度分析 描述了商店评论引入 24到48小时的延迟 并且认为移动团队应该单独跟踪二进制发布节奏和发布的体验频率。用户采用创建了另一个延迟。即使经过批准，用户也可能不会立即安装新的二进制。
这创建了一个常见的测量失败。一个团队可能频繁提交二进制文件，但大多数客户仍在运行较旧的版本。如果产品团队只测量提交，它可以声称用户没有体验到的进步。
将每个变化通过正确的路径
使用二进制管道处理需要原生打包的变更。使用特性标志、远程配置、内容分发和签名的 Web 层更新处理不需要原生打包的变更。目标不是强制每次更新通过无线机制。目标是停止将不需要新二进制的变更作为默认门户。
应用更新的使用频率分段 可以帮助团队区分谁接收更新、什么时候接收更新以及更新是否到达活跃用户。这些数据使交付的体验频率比简单的发布日历更有用。
实践策略加速您的发布管道
发布速度提高时，团队会移除等待、重复的手动工作和不必要的耦合。首先，测量每个发布花费的时间。手动签名、原生依赖安装、串行测试、批准手动和全包传输需要不同的修复，因此将它们视为单独的瓶颈。
自动化机械工作
可靠的 CI/CD pipeline 从已知的提交中构建、安装固定依赖项、运行测试、生成签名的 artifact 并发布它们，而不重复本地步骤。并行化独立测试套件并在支持它的构建系统中缓存原生依赖项。保持 staging 和 production 配置结构一致，因为环境不匹配可能会在发布过程的后期阻塞。
自动化改变了拥有者而不是时间。没有它，一个开发者负责签名、构建、审批和发布。有了它，管道执行可重复的工作，而开发者则审查结果并处理异常。
差异更新解决了另一个浪费的来源。如果仅有部分 Web 包的内容发生变化，发送更改的文件而不是整个包可以减少传输工作并使实时交付在受限连接上更为实际。然后，工件反映了实际的变化表面，而不是再次打包每个未变更的资产。
减少风险而不创建 QA 队列
基于频道的发布分离了内部测试、早期访问和一般可用性。预发布可以先接收更新，beta 版本可以将其暴露给选择的用户，生产环境可以在收到可接受行为的遥测数据后再接收更新。这使得验证与较小、可观察的受众相关联，而不是一次性批量积累后再进行晚期审批。
功能标志在应用内部添加了控制。开发者可以合并 code 而不激活完整体验，然后为定义的受众启用它并监控错误和行为。这样可以支持较短的分支并让团队禁用一个问题体验而不需要重建原生二进制文件。
有关测试覆盖率和性能验证的指导，请参阅 PageSpeed Plus 测试策略文章 ，在自动化部署门控之前。
实践管道可以遵循以下顺序:
- 提交和验证: 为每个相关变更运行 linting、单元测试、打包检查和安全检查。
- 发布到受控频道: 将 artifact 发送到 staging 或 beta，带有清晰的版本历史和受众规则。
- 观察和推广: 在推广同一 artifact 到生产之前，查看采用情况、失败和用户报告。
- 故意恢复: 保持先前的已知良好版本可用，以便回滚不需要另一个存储提交。
观看工作流程的运行:
在 部署自动化指南 为这些实践提供实施上下文，使其成为可重复的交付。对于Capacitor团队来说，实践上的区别仍然很重要：原生变化仍然需要二进制发布，而合格的Web层变化可以遵循受控的实时更新路径并在等待商店审查之前就可以将更新推送给用户。
如何Capgo为跨平台应用程序实现更快的发布
Capacitor团队可以使用Capgo作为实时更新路径来发布合格的Web层变化。开发人员修复了一个JavaScript错误，构建了Web包，并通过CapgoCLI发布了一个签名的更新。更新器可以将包推送到目标设备，应用于下一次启动，并在更新失败时保留回滚保护。
该工作流程改变了交付的单位。原生能力仍然遵循二进制路径，但Web层修复不需要等待新商店包的发布，因为它符合平台和商店政策的边界。Capgo支持签名的Web包、差异更新、通道、CI/CD集成、设备日志、采用和失败指标、版本历史和自动回滚保护，根据发布者的产品信息。
通道将发布控制转换为团队工作流
通道自然映射到跨平台团队的工作方式:
- 测试环境 为内部测试人员提供一个隔离的更新流
- 测试版 支持早期采用者和受控验证。
- 生产环境 为满足团队对证据的满意度后，服务普通用户。
每个频道都可以按照自己的节奏前进。这意味着开发者可以为内部验证发布一个修复，而不暴露它给广泛的用户，然后推广经过测试的包而不是重建它给每个用户。
回滚与发布一样重要。如果出现严重问题，恢复到之前的包给团队提供了恢复路径，同时底层修复正在调查中。这个安全网并没有消除测试或可观察性的需求。它减少了错误的成本，使小规模发布更为实际。
比较两个发布路径
传统的Capacitor周期通常如下：
- 修改Web和本机code。
- 构建二进制文件。
- 提交审核。
- 等待批准和发布。
- 等待用户采用它。
一个符合条件的 Web 层级变化的实时更新周期看起来是这样的：
- 更改 web层。
- 构建并签署捆绑包。
- 将其发布到受控频道。
- 观察采用和故障。
- 推广或回滚。
团队可以使用 Capgo GitHub 集成指南
将此工作流连接到自动化管道。重要的结果不是承诺的发布次数。它是能够将本机发布工作与 web层迭代分开，并测量两者的能力。
常见的误解关于更快的交付 更快的发布并不自动意味着更低的质量。
第二个误解是部署频率本身就能定义速度。DORA将交付视为一组指标，包括交付时间、变更失败率和恢复时间。频繁部署但花费大量时间修复事故的团队并没有建立健康的速度。它只是加速了未完成的风险的移动。
没有恢复的速度只是一条通往更长停机时间的更快路线。
移动团队经常说商店评论会使改进不可能。商店评论限制了二进制交付，但它并没有定义每个用户面向的变化。有用的区别是变化是否属于原生code还是在web层。功能标志、远程配置、内容更新和合格的签名包可以缩短后者路径而不假装原生变化不需要审查。
实时更新也会引发合理的政策和安全问题。团队必须了解苹果和谷歌的规则，限制交付到允许的内容和行为，签名和认证包，保护通道，并保持一个清晰的回滚路径。实时更新系统不应该成为隐瞒不允许的可执行行为的方式。
产品价值和运营健康状况的衡量标准并非仅凭更新次数。
提高发布速度的行动计划
从测量开始，接着去掉最大的等待来源。 在你的控制台中，将原生二进制发布与 web 层更新分开，记录每条路径的 lead time，跟踪失败和恢复率与频率。 这样可以防止团队优化一个单独的数字，而客户体验仍然缓慢。
首次迭代
- 自动触发 从仓库中而不是开发者笔记本上运行验证和构建任务。
- 标准化版本号 使用一致的版本控制方案，团队可以识别出哪些变化以及用户接收到的哪些 artifact。
- 创建测试渠道 为内部测试者提供一个受控的路径，不需要进行广泛的分发。
- 恢复步骤记录: 可以暂停、推进或回滚更新的用户。
- 查看批次大小： 将大规模变更拆分在发布管道之前。
下一步的投资是架构性的。确定哪些变更需要二进制文件，哪些可以通过 Web 层传递。适当的地方添加差异化打包，引入渐进式渠道，并将交付事件连接到可观察性系统。仪表板应该回答谁接收了更新，是否失败，以及团队恢复安全版本的速度。
长期来看，产品和工程领导者需要奖励 交付频率,而不是仅仅关注版本号活动。较小的发布创建了更紧密的反馈循环，但只有当团队保护稳定性，保持回滚程序，并将恢复视为交付的一部分，而不是异常事件时才会如此。
在当前冲刺中使用此清单：
- 分离二进制频率和交付频率。
- 自动化构建、测试、签名和发布路径。
- 在扩展生产交付之前，建立预发布和测试渠道。
- 添加采用、失败和回滚可见性。
- 一起审查 DORA 指标，而不是单独追求部署频率。
因为每个完成的反馈环节都会为下一个变化提供信息，发布速度会因为每个完成的反馈环节而倍增。移除一个瓶颈会改善下一个周期，尤其是团队可以快速发布更小的变化，观察它们并在不重建整个应用程序的情况下恢复。
Capgo 为 Capacitor 和 Electron 团队提供了一个受控的实时更新路径，用于签名的 Web 层包，差异性交付，通道，观察性和回滚保护。如果 App Store 审核正在拖慢符合条件的修复和体验变化，请访问 Capgo 来评估它如何融入您的发布管道。
