Spotify 采用 Bazel 作为 iOS 应用的官方构建系统

2020 年，经过三年的实验，Spotify 决定将 Bazel 作为其 iOS 应用的官方构建系统。这一决定使构建时间缩短至原来的四分之一。

无缝过渡的关键

Spotify iOS 团队在过渡期间保持了开发的连续性和发布频率。在采用 Bazel 之前，Spotify 使用基于 YAML 的自定义 Ruby DSL，允许开发者以声明方式添加新模块，包括构建目标、源文件、资源和依赖项。这种 DSL 脚本可以重用于生成 BUILD.bazel 文件，而非 Xcode 的 .pxbproj 文件，从而确保了向 Bazel 的无缝过渡。

构建和测试时间的显著减少

采用 Bazel 后，构建和测试时间从 80 分钟（七天内的 75% 分位数）减少到仅 20 分钟。一个包含 800 多个测试目标和近 300 万行代码的配置，使用 Xcode 构建需要超过 45 分钟，而使用 Bazel 后，时间减少到不到 10 分钟。

性能提升的原因

性能提升主要归功于 Bazel 的高效远程缓存和对多台机器并行构建的支持。

过渡过程中的挑战和解决方案

过渡过程并不简单，Spotify 使用 BuildBuddy 工具通过图形用户界面和命令行界面识别性能问题和瓶颈。他们还使用 bazel-diff 工具更好地识别每个变更影响的构建图部分，从而减少每次新构建所需的测试集。

本地构建与 CI 构建的共存

为了改善开发者在本地使用 Xcode 构建与 CI 基础设施中使用 Bazel 构建的共存，Spotify 采用了 rules-xcodeproj，直接从 Bazel 构建文件生成 Xcode 项目，减少了本地构建成功但在 CI 中失败的情况，降低了维护和故障排除成本。

迁移的最后步骤

迁移的最后一步是定义一个推出策略，Bazel 构建首先在员工设备上部署两周，然后推送给外部 alpha 和 beta 测试者，最后面向普通用户。

迁移的成功

迁移过程顺利完成，崩溃和性能指标均未显示显著差异。