- Bazelは、Googleが大規模モノレポを効率的にビルドするために開発したオープンソースのビルドシステム
- 複雑なプロジェクトを正確かつ高速にビルドでき、特に大規模コードベースや多言語の依存関係を扱う際に効果的
- Bazelの中核となる概念
- 正確性に基づく速度: Bazelはビルドを純粋関数として扱い、同じ入力が同じ出力を生成することを保証
- 効率的なキャッシュ: Googleのような大規模環境ではキャッシュが不可欠であり、正確性がそれを可能にする
- クリーン不要のビルド: ソース変更後も "clean build" なしで安定したビルドが可能
- Bazelを使うべき場面
- 推奨されるケース
- 大規模モノレポ: コード行数が数百万に達し、複数言語を使っている場合
- 多様な言語の依存関係管理: たとえばPythonでモデル学習、Scalaでデータ処理を行う場合
- 高速かつ正確なCI/CDが必要: 開発速度を高め、衝突を防止
- 非推奨のケース
- 小規模プロジェクト: コード行数が10万以下で、単一言語を使っている場合
- オープンソースライブラリ: Bazelは配布可能なアーティファクトの生成には適しているが、再利用可能なライブラリ配布には不向き
- Bazel導入時の考慮事項
- 初期の学習コストが高く、ビルドファイルの作成と保守に追加のリソースが必要
- キャッシュサーバーやリモート実行設定などのインフラ構築が必須
- Bazel導入の成功事例
- Netflix
- 課題: 25万〜30万行のコードを含むリポジトリで、CIに45分〜1時間かかっていた
- 解決策: Bazel導入後、ビルド時間が20分から6分に短縮
- 効果: マージ競合の減少、PR処理速度の改善
- Open Systems
- 課題: ビルド時間が遅く、ワークフローが非効率だった
- 解決策: Bazelへ移行後、フィードバックループを20分から5分に短縮
- 教訓: 開発者教育とコミュニケーションが重要
- Bazel導入の長所と短所
- 長所
- 高速なビルド時間: キャッシュと増分ビルドで速度を改善
- 正確性と再現性: 複雑な依存関係グラフを正確に表現
- 多言語統合: Haskell、TypeScript、Pythonなどさまざまな言語をサポート
- 短所
- 高い導入コスト: 初期設定と学習コストが大きい
- ビルドファイル管理が必要: 入力/出力の明示が必須で、自動化ツールの活用が必要
- JavaScriptおよびフロントエンドツール群: ホットリロードなど既存ワークフローとの互換性が難しい
- Bazel移行のヒント
- 中核チームの編成: Bazelを理解し、設定できる専門家を確保
- 教育とコミュニケーション: 導入初期には、開発者教育と期待値の設定が必須
- 言語ごとの複雑さ: 各言語ごとに異なるビルド設定が必要
- ビルドファイルの自動化: Gazelle のようなツールを活用
- 結論
- Bazelは大規模モノレポと複雑な依存関係の処理に優れる一方、導入コストは高い
- 数百万行のコードと多言語を扱う組織に適している
- 小規模プロジェクトや段階的な移行を望む場合は、Bazelの代わりに Earthly のような代替案を検討
3件のコメント
Bazel の導入失敗事例にも触れられるとよさそうですね。
AOSP の場合、ここ数年の BazelCon で、既存のビルドシステム（Soong）から Bazel へ移行する取り組みについていくつか発表がありました。
https://developers.googleblog.com/en/…
しかし、今年の BazelCon では AOSP 関連の内容共有がなく、最近の AOSP のビルド関連ドキュメントでは、Bazel への移行が中止されたとの案内が出ています。
Bazel への移行に関しては、AOSP チームであれば多くの支援を受けられるはずですが、それでも導入を断念したという点には、多くの示唆があるように思います。
たぶん…あなたのソフトウェアにBazelは必要ありません。
ｗｗ EarthlyでEarthlyの広告をしているんですね。
Bazelは高速なビルドと高速な「テスト」に重点があります。テストの話があまりないですね。