Airbnb社は、ビルド・パイプラインをBazel に移行している他の組織同様に、Buckの使用を停止し、ビルド時間だけでなくプロジェクトの生成とロード時間の両方を改善したプロセスの詳細なウォークスルーを提供した。
Airbnb社のエンジニアであるQing Yang氏とAndy Bartholomew氏が説明するように、Bazelへの移行を決定したのは、バックエンドとフロントエンドの両方を含むすべてのプラットフォームで、まとまりのある効率的なビルド体験を提供するという目標があったからだ。
iOSの開発パイプラインから始めて、Airbnb社のエンジニアはビルド構成とIDE統合という2つの主要な側面に焦点を当てた。
ビルド設定の移行は、BazelとBuckが同等のディレクトリ構造、同様のコマンドライン呼び出し、そしてもっとも重要な点として同じ設定言語であるStarlarkを使用するなど、いくつかの類似点を共有しているという事実によって、どうにかシンプルになった。
しかし、BuckとBazelは似ているにもかかわらず、両者は利用可能なルールのセットにおいて異なっている。
例えば、Buckはapple_libraryやapple_binaryといったルールを提供するのに対し、Bazelは外部のルールセットによって、swift_libraryやapple_frameworkといったルールを備えています。2つのシステムにgenruleのような同じ名前のルールがある場合でも、それらのルールを設定するための構文は似ていないことが多いです。
Airbnb社の場合、この問題を解決するために、ネイティブルールと外部ルールをラップするシムレイヤーを作成した。移行フェーズで両方のシムを同時に扱うため、Airbnb社のエンジニアは、rules_shim/buckと
rules_shim/bazelという
2つの異なるディレクトリを持つリポジトリを作成し、rules_shim
識別子を適切なディレクトリに関連付けるルールをビルドシステムごとに定義した。
rules_shim
レイヤーは、genrule
ハンドリングに対応するための鍵でもあった。GenrulesはAirbnb社でiOSコードベースの定型文を生成するために使用され、2つのビルドシステムで異なる構文を持っている。ラッパー・レイヤーのおかげで、Airbnb社のエンジニアは両方のシステムで同じgenruleスクリプトを使えられる。
ビルド・コンフィギュレーションで作業が必要だった最後の領域は、条件付きコンフィギュレーションのサポートだった。この場合、BazelとBuckのミスマッチは、Buckがコマンドライン引数を読み込むread_config
関数を提供しているのに対し、Bazelではサポートされていないという事実から生じる。解決策は、抽象化レイヤーを下に移動し、コマンドライン引数をselect
で再実装することである。
IDEとの統合に関しては、Airbnb社のエンジニアのゴールは、Xcodeプロジェクトを作成するための既存のBuck中心のソリューションを、Buckを中心に開発したすべてのツールを失うことなく、Bazel中心のものに置き換えることだった。この目的のために、彼らはXcodeGenを使って独自のXcodeワークスペース・ジェネレーターを開発することにした。
もっとも重要なことは、開発者のワークフローを中断させないために、3つのステップで移行プロセスを実施したことだ。最初のステップでは、新しいジェネレーターを既存のBuckベースのソリューションと統合し、すべてが期待通りに機能することを確認した。第二段階では、Buckで使用されているものと同等の新しいBazelコマンドを追加し、一方から他方への切り替えを可能にした。最終的には、新システムが十分に安定していることが確認された時点で、Buckのサポートを終了した。
この移行の最終結果は印象的だ。Buckで生成されたプロジェクト(buck project)と比べて、XcodeGenでの生成時間は60%短縮され、Xcodeのオープン時間は70%以上短縮された。
それに加えて、新しいBazelベースのビルド・システムは、特にインクリメンタル・ビルドのビルド時間を短縮し、共有とコラボレーションを改善するためのさらなる最適化を可能にした。全詳細に興味のある方は、元記事をお見逃しなく。