Spotify发布流程大揭秘

在 Spotify，发布团队肩负着双重使命：既要监督主要应用的发布，还要构建支持整个流程的必要工具。日常协调工作由全职发布经理负责，团队其他成员则在一旁默默支持。

Spotify发布团队标志

发布团队在应用发布时有两个核心职责：

1. 确保从代码合并到用户可用的时间尽可能短
2. 确保质量符合他们的标准

这两个目标之间有时会有些小摩擦，发布管理的艺术就在于如何巧妙化解这种摩擦。 他们既通过工具，也通过明智的协调和决策来平衡这种关系。

需要平衡的实例可能包括：

• 相应地确定优先级 并非所有 bug 都是平等的。注册或播放期间的崩溃需要立即关注，而登出后的崩溃可能不那么紧急。
• 识别回退方案 如果 bug 影响特定的 A/B 测试组，他们可以通过后端调整暂时将所有用户路由到工作体验，在下一个版本中解决客户端修复。这在不牺牲用户体验的情况下保持发布进度。
• 在必要时快速行动 即使是影响小但重要用户组的轻微 bug（例如，特定区域的崩溃）也可能需要快速解决。

1 发布周期

为了说明 Spotify 的发布周期，让我们跟随版本 8.9.2 从诞生到推出的旅程。

Spotify发布时间线

9 月 20 日星期五：新版本诞生

每个发布周期在星期五早上开始，此时前一个版本的发布已被切断。一旦完成，就是时候开始处理即将到来的版本了。

在 Spotify，他们实践基于主干的开发，这意味着开发者在代码经过测试和审查后立即将其合并到主分支。

但是，他们对重大更改有例外：大规模或基础设施更新在周期早期合并（通常是第 1 周的星期五）。 这给了他们充足的时间进行彻底测试，利用内部团队和外部 alpha 用户来早期识别和修复问题。

对于 Spotify 8.9.2，他们计划在一些市场推出有声书功能 — 它已经在后端的功能标志后面可用了一段时间，供内部测试发现可能阻碍计划推出的任何 bug。这是公司的一个重要新功能，他们想确保做对了，特别是因为营销活动和事件已经安排好了。

发布经理确保提前安排，这是这个版本推出的唯一大功能 — 最初计划在同一周推出的另一个新功能被重新安排到下一周。

其他团队仍然可以随时合并代码，但他们强烈鼓励使用功能标志。如果那不可能，他们要求避免在那特定的一周合并任何高风险更改。

9 月 20 日星期五 – 9 月 26 日星期四

除了第一天的额外行动外，发布周期第一周的每一天基本上看起来都一样。

• 每天清晨，主分支的夜间构建会发送给内部和他们的 alpha 用户。
• 团队开发并合并新代码。开发者及其团队确保代码事先经过测试和审查。
• 内部和外部 alpha 用户提交 bug 报告。当受影响功能的所有者对报告者未知时，发布经理确保 bug 报告分配给正确的团队。
• 每个构建的崩溃率和其他指标都会自动和手动跟踪。当崩溃或其他问题超过他们预定义的严重性阈值时，会自动创建 bug 票据；当发布经理或任何其他员工认为某事值得调查时，会手动创建票据。

为了帮助监控即将到来的发布状态，他们使用发布经理仪表板，它在同一地方收集所有相关的发布信息：

Spotify发布状态仪表板

仪表板中发现的数据的一些示例如下：

• 阻塞 bug
• 最新可用构建，通过测试，并通过应用商店的 alpha 程序分发
• 每单位消费的崩溃和 ANR（应用无响应）
• 每日使用量
• 在内部和外部分发应用的分发作业状态

到这个时候，有声书功能已经为大多数员工开启。因此，除了这个特定版本的常规流程外，发布经理和有声书团队都查看了客户端中发生的所有崩溃，看看是否有任何可能危及有声书推出的东西。即使是看似轻微的崩溃影响少数员工也可能意味着在推出时影响大量用户群的潜在问题。因此，尽快调查和缓解任何问题很重要。

9 月 27 日星期五：星期五是分支日！

一周过去后，是时候为 8.9.2 版本分支进行发布了，启动发布过程中最密集的部分。一旦发布被分支，它被视为*当前*发布，只允许关键 bug 修复。 他们的每周发布节奏允许在后续发布中处理不太关键的 bug 和新功能，团队通常避免最后一刻的更改以最小化风险。

一旦分支完成，发布经理协调尽快发布版本的工作与所有利益相关者。

为了帮助他们收集关于发布分支质量的额外数据，他们有一个从发布分支获取的公共 beta 程序 — 这些构建预计比他们的 alpha 构建更稳定。

在第 2 周的星期五，团队对他们拥有的功能执行手动回归测试并报告结果。对他们的自动化测试和预合并例程有高信心的团队可以选择退出手动测试。

在整个测试过程中，团队可能会在他们自己或其他团队的功能中发现 bug，并将为这些创建票据。此外，来自内部和外部用户的崩溃报告和 bug 报告也会触发新 bug 票据的创建。

对于 8.9.2，有声书团队在这个阶段特别警惕，仔细搜索任何潜在问题。在这一点上，讨论 bug 并决定它们是否值得成为发布阻塞器并不罕见。良好的发布管理意味着客观地看待风险、潜在影响和解决方法。

9 月 27 日星期五 – 9 月 30 日星期一：准备提交

在分支后的周末，他们的 beta 用户提供应用的额外运行时间，这要么增加他们发布它的信心，要么帮助他们找到之前没有发现的问题，到他们周一回到工作时。

理想情况下，他们旨在周一向应用商店提交应用。但是，复杂的 bug 或意外问题可能会将此过程延长几天。为了简化每次发布的沟通和协调，发布经理、功能团队和其他利益相关者在专门的 Slack 频道上分享更新、提问并标记潜在问题。

发布经理确保 bug 分配给正确的团队并适当确定优先级，手动测试被执行和报告，任何发布阻塞 bug（每次发布通常有三到五个这样的 bug）在发布分支上修复。

在他们将构建提交到应用商店之前，他们希望确保满足以下标准：

• 发布分支上的所有提交都包含在最新构建中，并通过了自动化测试。
• 没有阻塞 bug 票据保持开放。
• 所有团队都已签署并批准。
• 崩溃率和其他关键指标低于他们定义的阈值。
• 要发布的应用版本已被用于播放足够数量的内容。

发布经理仪表板提供了这些标准的清晰概览，使用颜色编码（红色/黄色/绿色）进行快速评估。

对于 8.9.2 发布，他们为各种应用商店提供了启用了有声书功能的额外测试账户，以及详细的测试说明，以确保应用商店了解新功能，在他们开始推出功能时不会措手不及。

10 月 1 日星期二 – 10 月 2 日星期三：推出

一旦应用被平台批准，他们分两个阶段推出：首先，向一小部分用户推出，然后，第二天，向 100%的用户推出。

当发布已向 1%的用户推出时，他们期望仪表板看起来像这样：

Spotify发布经理仪表板

在完全推出之前唯一剩余的黄色指示项目是 ITGC 票据，他们检查客户端到后端的报告是否按必要工作。发现轻微 bug 并不罕见，虽然在当前版本中可接受，但会被视为未来版本的阻塞器。在严重情况下，他们可能会暂时停止功能推出，并在下一个版本中恢复。

感谢他们庞大的用户群，即使是很小的初始推出百分比也允许他们快速识别在内部和公共 alpha 和 beta 测试期间可能溜过裂缝的关键问题。

如果他们在第一推出阶段发现严重问题，他们立即暂停推出，负责的团队开始创建修复。理想情况下，修复在下一个版本分支之前准备好，允许他们提交更新的构建。但是，如果修复不及时，他们可能面临取消当前或即将到来的发布的困难决定，以防止同时管理两个活跃发布分支的复杂性。一旦他们达到 100%，他们继续监控发布状态超过下一周。

对于版本 8.9.2，一旦足够的用户群使用新版本，有声书团队启动了他们的分阶段推出。这涉及使用后端功能标志逐渐为特定市场中的一小部分用户启用有声书功能。

幸运的是，对于版本 8.9.2，有声书功能符合他们的质量标准，推出在接下来的几天内成功提升到 100%。

使用上述发布程序，他们能够向所有用户推出超过 95% 的发布。 每周节奏也意味着取消的发布对功能团队来说不是世界末日，因为新的发布将在下周推出。同样，只要符合他们的质量标准，用户每周都能获得应用的新版本。

2 总结

Spotify 的每周移动应用发布过程试图在速度和质量之间取得平衡。

这个过程的核心是发布经理，他在发布周期的整个过程中与功能团队和其他利益相关者处理沟通和协调，并得到发布小队的帮助。

像发布仪表盘（ Dashboard） 这样的工具在使发布经理能够做出快速准确决策方面发挥着重要作用。

工具和过程的详细文档有助于指导所有相关团队。

这个健壮的系统允许 Spotify 持续更新其应用，快速解决问题，并引入像有声书这样的新功能，同时最小化对用户体验的干扰。