Spotify 的平台迁移经验：从小事做起，关注利益相关者，寻求自动化

在管理不断壮大的开发团队与愈发复杂的代码库的同时，还要提供更快也更可靠的交付，这似乎是飞速发展的科技公司都难逃的挑战，对平台团队而言也是一样。在代码库和组织不断增长的现状下，我们要如何快速推陈出新、更安全地引入新技术呢？

从 2019 年的 29%，2020 年的 49%，到 2021 年的 23%，Spotify 的移动端代码库规模一直在急速扩大。随着我们在业务上的扩展，Spotify Live 等新体验的加入，代码库也在不断演化。而于此同时，Spotify 也在不断招收新工程师，致使移动端代码库的修改次数逐渐增加。

我们的移动工程策略项目于一年半前发起了一项倡议，通过多次迁移让客户端功能得以在独立环境中进行开发，类似于后端微服务。

自此之后，我们将系统与约 2,200 个安卓及 iOS 组件相关联，将大部分安卓与 iOS 代码库迁移至谷歌的开源构建系统 Bazel 进行构建。这一大工程影响了公司上下上百的项目组。

我们认为，代码库和组织规模的增长与复杂性的加剧将会是迁移的主要难点所在。如果我们期望能在 Spotify 的移动端高效且规模化交付平台解决方案，就需要常态化迁移所带来的挑战。

以下是我们在迁移路上所遇到的挑战，其中囊括了场景和问题表征，以及面对问题时应当避免或鼓励的行为。

如何在创造变化并提出可支持大部分用例的标准化架构解决方案的同时，不影响其他用例？

这一范围看似很广，给人一种无数用例亟待处理的感觉。在面对大量的技术债务、需要的改动、需要支持的用例时，往往会让人无从着手。利益相关者们即使是在多次询问后，也还是对迁移时自己要做的事云里雾里。

• 在还未确定所有可能情况之前便试图推出解决方案。

• 在尚未预估路线图或成功的界定之前便开始大规模迁移。

• 在没有明确定义利益相关者需要做的事之前便接触他们。

• 清楚目标。在产品简介中写明你的原因、方法，以及目的。

• 注重价值。价值的转变是很耗时的，但需要的时候也要对其调整以适应你的目标。

• 应对受众。了解受众的心智模式才能给出相关的回应、对接他们的需求，并寻找到合适的代理以扩大自己的影响。

• 从小事做起。创建一份概念证明，和利益相关者们核对其内容，并让迁移经历 alpha、beta，以及 GA 产品循环。从最常见的用例开始，随进展不断添加新发现的用例。这一步会让你收到足够的反馈，并渐渐能够支撑不同用例情况。

• 合作！在早期阶段，合作是关键。寻找愿意积极试用早期解决方案的人，他们将成为自己群组内的传播者。这点最后也将助力于方案的可扩展性。

在飞速扩张的组织内，我们要如何才能更快地推动大型架构和基础设施的变化？

• 大量项目组将会受变动影响（超过百个项目组）

• 工作量巨大。其中包括迁移中途需要团队手动重构的任务

• 进展缓慢。涉及无数利益相关者与依赖关系

• 利益相关者被进行中的迁移工作重担压垮

• 认为大型组织中的大型基础设施和架构中的变动是不可能或不需要的

• 在进行架构或基础设施变动时要缓慢前行

• 关注利益相关者的管理。明确不同利益相关者的优先级，通过邮件或 Slack 等形式保持联络，并将自己工作的重点相告知。

• 沟通。通过邮件及工作区发帖将自己的进度共享，让受众保持参与感。

• 寻求自动化。预先投入的自动化会简化迁移进程。我们是否需要重构代码？是否能通过脚本将重复步骤自动化？

• 为敏捷的 spike 周腾出时间。团队与贡献者组队，用一周时间协同合作迁移。

• 通过不同资源提升影响力。培训项目可以帮助团队了解迁移和新的概念，从而能够立刻将其投入应用。

• 在公司的入职计划中介绍公司的工程实践，让新员工能从一开始就理解并遵循所推荐的最佳实践。

平台团队是需要努力减少技术债务并引入新技术，还是要让其对自己代码质量负责？这二者之间要如何平衡？

• 利益相关者参与了优先级更高的项目，而无暇采用你的解决方案。

• 利益相关者认为平台迁移拖慢了他们的脚步，缺乏采用新技术的动力。

• 项目被稀释，推动迁移进行的团队没有动力，甚至有成员选择离开团队。

• 必要的代码修改与迁移方向相左。

• 自信利益相关者明白迁移的重要性和影响程度，并将其优先处理。实际上他们也有很多其他任务要处理。

• 放弃。“我们忙于抢占更高优先级”，这是个平台迁移中很常见的放弃理由。

• 认为指标和目标是固定且很难变动的。

• 应激励，向利益相关者展示迁移的积极影响，鼓励他们完成迁移任务。

• 持续评估。季度内定期的检查点可以评估迁移进行的速度，判断是否能达成季度、半年度或年度的指标。

• 风险管理。如果迁移进展过慢，要如何调整方法以达成目标？是否能精简流程？是否需要更多工程师？能否雇佣承包商？能否影响其他团队，把自己的任务加入他们积压的工作之中？

• 替平台承担。可能的情况下，为组织做出必要变动，以便组织能专注于为用户创造价值。

• 密切关注与迁移 KPI 相违背的变动，建立与团队之间的渠道以提供支持。

如何才能在需要大量变动和重构基础设施的新技术采用过程中，让团队承担起责任？

在新技术的采用过程中缺乏责任感，导致迁移进展缓慢。

无法预估迁移何时结束。

• 在驱动大量改动时指望内外部能保持一致性。

• 认为基础设施上的变动和影响很难衡量。

• 明确“完成”的定义。借助数据和趋势图给出预测。我们需要清楚自己的出发点和进展速度，才能预估未来的趋势，并确定是否需要调整策略以加快迁移进展。

• 进度展示。掌控成功的定义且不断沟通，才能保持受众参与并接受我们所做的变动。

• 使用看板。通过指标和看板沟通进展和影响，并规模化确定一段时间内的工作优先顺序。

• 维护时间线并实时更新路线图。随着时间的推移，团队和利益相关者可能会有变动，他们需要了解我们的迁移进程和时间线。路线图也有助于透明化，让反馈和协作成为可能，也能帮助发现障碍。

这种性质和规模的迁移工作可能会成为未来的常态，若非如此，公司可能将无法执行特定的变动。新科技将会不断出现，迁移也将成为必然，但我们也应减少这些动作对团队的干扰。有的平台产品或许会让迁移无可避免，且可能会规模不小，我们应将其与测试、设计共同视作是开发周期的一部分。

我们从这项工作中学到了很多，希望这些经验能对其他团队的大型迁移有所帮助。如果你想了解更多关于我们所遇到的挑战和相应的解决方法，请随时联系我们。

特别感谢 Marvin、Foundation、BoB，以及 Rubik，为我们的工作提供助力。

比VS Code快得多！用Rust重写，支持OpenAI、Copilot 的Zed编辑器开源了

淘宝启动鸿蒙开发，微信会跟进吗？马云抄底阿里；“哄女友挑战”上线即爆火，24 小时用户达 60 万 | Q 资讯

贾扬清新作被某印度创始人内涵借鉴，懒得纠缠：巧了，正准备开源，GitHub 见

被严重宕机坑惨了！多家公司向这个已经存在10年却“鲜为人知”的架构迁移