作者 | Sergio De Simone
译者 | 平川
策划 | 丁晓昀
经过三年的试用，2020 年，Spotify 决定采用 Bazel 作为 Spotify iOS 应用程序的官方构建系统。按照 Spotify 工程师 Patrick Balestra 的说法，这一切换将他们的构建时间减少了四分之三。
对于 Spotify 的 iOS 团队来说，重要的是切换过程不能中断开发或影响发行频率。在采用 Bazel 之前，Spotify 使用基于 YAML 的自定义 Ruby DSL，开发人员可以声明式地添加新模块，包括构建目标的规范、构建它所需的源文件、资源和依赖项。Balestra 说，因为可以重用相同的 DSL 脚本来生成 BUILD.bazel 文件而不是 Xcode.pxbproj 文件，这有助于确保我们无缝地切换到 Bazel。
他提到，切换到 Bazel 将构建加测试时间从 80 分钟降低到了 20 分钟。
从耗时最长的配置开始，我们将 CI 配置一个接一个地迁移到 Bazel。其中有一个配置包含超过 800 个测试目标、近 300 万行代码，使用 Xcode 构建花费的时间在 45 分钟以上。迁移到 Bazel 之后不到 10 分钟就可以构建完成。
根据 Balestra 的说法，这种改进主要得益于 Bazel 高效的远程缓存以及它对多台机器并行构建的支持。
不过，这个过程并不是说直接将构建文件输入到 Bazel 就可以了。相反，它会涉及到一个严谨的过程，即使用 BuildBuddy 提供的遥测洞察来识别性能问题和瓶颈（BuildBuddy 是一个旨在通过图形用户界面和命令行界面解锁 Bazel 功能的工具）。另外，借助 bazel-diff，团队还可以更好地确定每个更改会影响到构建图的哪些部分，这样就可以尽可能地减少针对每个新构建所运行的测试集。
为了改善 Xcode 构建（开发人员在本地运行）和 Bazel 构建（在 CI 基础设施中使用）之间的共存，Spotify 采用了 rules-xcodeproj。这使得他们可以直接从 Bazel 构建文件生成 Xcode 项目，而不是使用遗留的 Ruby/YAML 构建系统，这样就可以减少在本地构建成功但在 CI 中失败的情况，从而降低维护和故障排除的成本。
向 Bazel 迁移的最后一步是定义一个发布策略，在将 Bazel 构建直接部署到员工设备上两周之后，再将其推送给外部 Alpha 和 Beta 测试人员，最后向普通用户发布。
Balestra 说，所有这些做完之后，切换就成功了，故障和性能指标也没有显示什么异常。
原文链接：
https://www.infoq.com/news/2023/10/spotify-bazel-ios-transition/
