经过三年的试用，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 分钟。
根据 Balestra 的说法，这种改进主要得益于 Bazel 高效的远程缓存以及它对多台机器并行构建的支持。
不过，这个过程并不是说直接将构建文件输入到 Bazel 就可以了。相反，它会涉及到一个严谨的过程，即使用BuildBuddy提供的遥测洞察来识别性能问题和瓶颈（BuildBuddy 是一个旨在通过图形用户界面和命令行界面解锁 Bazel 功能的工具）。另外，借助bazel-diff，团队还可以更好地确定每个更改会影响到构建图的哪些部分，这样就可以尽可能地减少针对每个新构建所运行的测试集。
为了改善 Xcode 构建（开发人员在本地运行）和 Bazel 构建（在 CI 基础设施中使用）之间的共存，Spotify 采用了rules-xcodeproj。这使得他们可以直接从 Bazel 构建文件生成 Xcode 项目，而不是使用遗留的 Ruby/YAML 构建系统，这样就可以减少在本地构建成功但在 CI 中失败的情况，从而降低维护和故障排除的成本。
向 Bazel 迁移的最后一步是定义一个发布策略，在将 Bazel 构建直接部署到员工设备上两周之后，再将其推送给外部 Alpha 和 Beta 测试人员，最后向普通用户发布。
Balestra 说，所有这些做完之后，切换就成功了，故障和性能指标也没有显示什么异常。
原文链接：
