SpotifyはBazelを3年間試用した後、2020年にSpotify iOSアプリの公式ビルドシステムとして採用を決定した。これにより、ビルド時間を4分の1に短縮できた、とSpotifyのエンジニアであるPatrick Balestra氏は説明している。
SpotifyのiOSチームにとって開発を止めることや、リリースの頻度に影響を与えることなく移行できることが非常に重要だった。Bazelを採用する前は、SpotifyはYAMLをベースにしたカスタムメイドの Ruby DSLを使用して、開発者がビルドターゲットの仕様、ビルドに必要なソース ファイル、リソースや依存関係などの新しいモジュールを宣言的に追加できるようにしていた。Balestra氏によると、同じDSLスクリプトを再利用して、Xcodeの.pxbprojファイルの代わりにBUILD.bazelファイルを生成できるため、Bazelへのシームレスな移行を確実にするのに役立った。
Bazelに切り替えたことで、前述の通り、ビルド+テストにかかる時間は80分(7日間の75パーセント)から20分にまで短縮された。
CIコンフィギュレーションをひとつずつBazelに移し、もっとも時間のかかるコンフィギュレーションから始めた。特に、300万行近くのコードを含む800以上のテストターゲットがあり、Xcodeでビルドするときに45分以上かかった。Bazelに移行後、この時間は10分以下に短縮された。
Balestra氏によると、このパフォーマンスの向上は、Bazelの効率的なリモートキャッシュと、複数のマシンにまたがるビルドの並列化のサポートによるところが大きいという。
とはいえ、Bazelにビルドをパイピングするだけの単純なプロセスではなかった。むしろ、BuildBuddy(グラフィカルユーザーインターフェースとコマンドラインインターフェースを通じてBazelのパワーを引き出すことを目的としたツール)によって提供される遠隔測定インサイトを使って、パフォーマンスの問題とボトルネックを特定する慎重なプロセスが必要だった。チームは、bazel-diffを使用することで、ビルドグラフのどの部分が各変更によって影響を受けるか正確に特定し、新しいビルドごとに最小限のテストセットだけを実行するようにした。
開発者がローカルで実行するXcodeビルドと、CIインフラで使用するBazelビルドの共存を改善するために、Spotifyはrules-xcodeprojを採用した。これにより、レガシーなRuby/YAMLビルドシステムを使用する代わりに、Bazelビルドファイルから直接Xcodeプロジェクトを生成できるようになった。ローカルではビルドが成功してもCIでは失敗するという、メンテナンスやトラブルシューティングのコストを発生させるようなケースが減った。
Bazelへの移行を完了するための最後のステップは、Bazelビルドを2週間従業員のデバイスに直接デプロイした後、外部のアルファ・ベータテスターにプッシュし、最終的に一般ユーザーに配布するというロールアウト戦略を定義することだった。
これらすべてが整っていたため、移行は成功裏に完了したとBalestra氏は言う。これは、クラッシュとパフォーマンスの測定基準からも明らかなように、目立った違いは見られなかった。