Staged Rollout — 什么是逐步发布，它如何运作

什么是 Staged Rollout？

Staged Rollout — 是 Google Play Console 的一个功能，用于逐步分发应用程序更新。开发者设定接收新版本的用户百分比，并逐步增加覆盖范围，同时监控稳定性和质量指标。只有在确认没有关键问题后，才会向所有用户进行完整发布。

该机制在应用商店层面运作：Google Play 自动将更新分发给选定百分比的设备。用户不会看到区别 — 对他们来说，这只是来自商店的普通更新。在选定的细分市场内，用户是随机选择的，这确保了样本的代表性。

该功能的历史

Google 在 2015 年将 Staged Rollout 作为 Google Play Developer Console 的一部分引入。在此功能出现之前，开发者会立即向所有用户发布更新，这会在出现错误时导致大规模故障。根据 Google I/O 2023 的数据，逐步发布的引入将 Android 应用中的关键事件数量减少了 60%。

何时使用 Staged Rollout

逐步发布用于发布重大变更时：新设计、架构变更、SDK 更新、数据库变更或迁移到新版本的 API。Staged Rollout 也推荐用于在完全部署之前对生产指标进行 A/B 测试。

Staged Rollout 如何运作

将 APK 或 App Bundle 上传到 Google Play Console 后，开发者选择 Staged Rollout 而不是完整发布。系统提示指定用户百分比，范围从 5% 到 100%，步长为 5%。Google Play 自动将更新分发给指定百分比的随机选择用户。

分发算法

Google Play 使用基于设备标识符和代码版本号的确定性算法。这保证了在 10% 时收到更新的用户在百分比增加到 20% 时不会丢失更新。分发是稳定的：用户要么已经收到了版本，要么将在下次增加覆盖范围时收到。

// build.gradle — Staged Rollout 的版本管理
android {
    defaultConfig {
        versionCode 42
        versionName "2.4.0-staged"
    }
}

// 确认稳定性后 — 完整发布
// versionCode 保持不变，versionName → "2.4.0"

过程中的指标监控

启动 Staged Rollout 后，需要监控关键指标：ANR 数量、崩溃频率、评分和用户评价。Google Play Console 提供实时指标面板。当超过阈值时，建议立即停止发布并执行回滚。

在 Google Play Console 中设置

Staged Rollout 的设置分为三个步骤，不需要更改应用程序代码。只需将构建上传到 Google Play Console 并选择逐步发布选项即可。以下是带有具体界面部分的逐步指南。

• 转到 Google Play Console → Release → Production
• 点击 Create new release 并上传 App Bundle
• 选择 Staged rollout 并指定用户百分比
• 确认发布并启动逐步分发
• 在 Dashboard 面板中跟踪指标

选择覆盖百分比

对于第一阶段，建议选择 5–10% 的用户。这是检测关键错误的最小代表性样本量。如果没有问题，则每隔 24–48 小时将百分比增加到 25%、50% 和 100%。快速增加覆盖范围仅适用于微小的更改。

Staged Rollout 的限制

该功能仅适用于 Google Play 中的生产版本。对于公开测试和封闭式测试轨，使用单独的机制。Staged Rollout 不能应用于单个国家或地区 — 百分比是根据应用的总受众计算的。对于地理定位，使用国家特定版本。此外，无法为不同的分发渠道设置不同的百分比 — 所有用户都是随机选择的，与安装来源无关。

逐步发布的优势

Staged Rollout 通过在小型用户样本上检测问题来降低发布风险。与内部轨道的测试不同，生产流量揭示了在 QA 环境中无法复现的真实使用场景。根据 Google Play Console 的分析（2024 年），70% 的关键错误正是在逐步发布阶段被发现的。

对用户体验的影响

出现问题，只有一小部分用户会遇到错误。其余用户继续在稳定版本上运行。这保持了应用的评分并防止了大量负面评价。Google Play 在搜索结果排名中也会考虑发布的稳定性。

与 CI/CD 的集成

Staged Rollout 受 Google Play Developer API 支持，允许通过 CI/CD 管道自动化逐步发布。像 Gradle Play Publisher 和 Fastlane 这样的工具提供了现成的命令，用于通过构建脚本设置覆盖百分比和监控发布状态。

阶段间过渡标准

在增加覆盖百分比之前，检查三个关键标准：崩溃频率低于 0.5%，ANR 数量不超过生产版本的基线，应用评分下降不超过 0.2 星。如果至少有一个标准被违反 — 停止 Staged Rollout，分析原因并从最低百分比发布修复后的构建。

回滚和撤销更改

回滚 — 是指在 Google Play 中恢复到应用程序的先前稳定版本。如果在 Staged Rollout 过程中发现关键错误，开发者可以停止分发并将所有用户恢复到之前的版本。操作在 Google Play Console 中进行，无需发布新构建。

如何执行回滚

要回滚，需要转到 Release → Production 部分并选择 Rollback to previous release 选项。Google Play 自动停止当前版本的分发，并将用户恢复到之前的稳定版本。所有进入该细分市场的新用户也将在下一次从商店更新时切换到旧版本。

何时无法回滚

如果之前的版本已从 Google Play 中删除或已过期，则无法回滚。建议始终在 Production 部分保留至少一个稳定版本。过期的版本可以通过 Google Play Console 支持服务临时恢复。

基于指标的自动回滚

Google Play Console 允许在崩溃频率或 ANR 超过阈值时设置自动回滚。在 Release → Production 部分设置触发器：如果崩溃频率超过 1%，Google Play 将自动停止 Staged Rollout 并恢复到之前的版本。这将在无需开发人员参与的情况下将事件响应时间减少到几分钟。设置触发器需要具有编辑者或管理员角色的帐户。

Staged Rollout vs 完整发布

在 Staged Rollout 和完整发布之间的选择取决于更改的类型和风险水平。完整发布适用于不更改逻辑的小型修复和依赖项更新。逐步发布对于主要更新、架构变更以及影响安全性或用户数据的更改是强制性的。

选择建议

对于影响超过 20% 代码的更新，Staged Rollout 是强制性的。UI 和 UX 更改也需要逐步部署以评估用户反应。完整发布适用于文本修复、不更改 API 的 SDK 更新以及低回归风险的安全补丁。如有疑问，始终选择逐步发布 — 回滚的成本远低于生产版本大规模故障造成的潜在损害。