ご不明な点やサポートのご要望がございましたら、サポートのご案内をご覧ください。
Bazel とは
Bazel は、ソフトウェアのビルドとテストを自動化するツールです。サポートされているビルドタスクには、コンパイラとリンカーを実行して実行可能なプログラムとライブラリを生成することや、デプロイ可能なパッケージを Android、iOS、その他のターゲット環境用にアセンブルすることなどがあります。Bazel は、Make、Ant、Gradle、Buck、Pants、Maven などの他のツールに似ています。
Bazel の特長
Bazel は、Google でのソフトウェアの開発方法に適合するように設計されています。これには、次のような機能があります。
- 多言語サポート: Bazel は多くの言語をサポートしており、任意のプログラミング言語をサポートするように拡張できます。
- 高レベル ビルド言語: プロジェクトは
BUILD言語で記述します。これは、相互接続された小さなライブラリ、バイナリ、テストのセットとしてプロジェクトを記述する簡潔なテキスト形式です。一方、Make などのツールでは、個々のファイルとコンパイラ呼び出しについて記述する必要があります。 - マルチプラットフォームのサポート: 同じツールと同じ
BUILDファイルを使用して、さまざまなアーキテクチャのソフトウェアをビルドできます。さらに、プラットフォームが異なる場合もあります。Google では、データセンターのシステム上で実行されるサーバー アプリケーションからスマートフォン上で実行されるクライアント アプリまで、Bazel を使用してあらゆるものを構築しています。 - 再現性:
BUILDファイルでは、各ライブラリ、テスト、バイナリの直接的な依存関係を完全に指定する必要があります。Bazel はこの依存関係情報を使用して、ソースファイルに変更を加えるときに再構築する必要があるものと、並列実行できるタスクを把握します。つまり、すべてのビルドが増分であり、常に同じ結果が生成されます。 - スケーラブル: Bazel は大規模なビルドを処理できます。Google では、サーバー バイナリに 10 万個のソースファイルがあることが一般的で、ファイルが変更されていないビルドには約 200 ミリ秒かかります。
Google が... を使用しない理由
- Make、Ninja: これらのツールを使用すると、ビルドファイルで呼び出されるコマンドを厳密に制御できますが、正しいルールを作成するかどうかはユーザー次第です。
- ユーザーは上位レベルで Bazel とやり取りします。たとえば、Bazel には、「Java テスト」、「C++ バイナリ」、および「ターゲット プラットフォーム」や「ホスト プラットフォーム」などの概念に関するルールが組み込まれています。これらのルールは、確実な検証が実証されています。
- Ant と Maven: Ant と Maven は主に Java を対象としていますが、Bazel は複数の言語に対応しています。Bazel では、コードベースを再利用可能な小さなユニットに分割することを推奨しており、再ビルドが必要なユニットのみを再構築できます。これにより、大規模なコードベースで作業する際の開発時間を短縮できます。
- Gradle: Bazel 構成ファイルは Gradle よりもはるかに構造化されているため、Bazel は各アクションの機能を正確に理解できます。これにより、並列処理の数が増え、再現性が向上します。
- Pants、Buck: どちらのツールも、それぞれ Twitter、Foursquare、Facebook の元 Google 社員が開発、開発しました。これらのデバイスは Bazel にちなんだモデルになっていますが、機能セットが異なるため、Google にとって現実的な代替手段ではありません。
Bazel の由来
Bazel は、Google 社内でサーバー ソフトウェアを構築するために使用しているツールの一種です。当社のサーバーに接続するモバイルアプリ（iOS、Android）など、他のソフトウェアの構築にも拡大しています。
内部ツールをオープンソースとして書き換えましたか？フォーク？
Bazel はコードの大部分を内部ツールと共有しており、そのルールは毎日何百万ものビルドに使用されています。
Google が Bazel を開発した理由
Google のソフトウェアは、大昔に生成された大きな Makefile を使用して構築されていました。その結果、ビルドが遅く、信頼性が低くなり、開発者の生産性と会社のアジリティが妨げられ始めました。Bazel は、この問題を解決する手段でした。
Bazel にはビルドクラスタが必要ですか？
Bazel は、デフォルトでビルド オペレーションをローカルで実行します。ただし、Bazel をビルドクラスタに接続して、ビルドとテストをさらに高速化することもできます。詳しくは、リモート実行とキャッシュ保存とリモート キャッシュのドキュメントをご覧ください。
Google の開発プロセスの仕組み
サーバー コードベースでは、次の開発ワークフローを使用します。
- 当社のサーバーコードはすべて、1 つの巨大なバージョン管理システムに含まれています。
- 誰もが Bazel を使ってソフトウェアをビルドしています。
- ソースツリーのさまざまな部分はチームごとに異なり、それぞれのコンポーネントを
BUILDターゲットとして使用できるようにします。 - ブランチは主にリリースの管理に利用されるため、全員がヘッドリビジョンでソフトウェアを開発します。
Bazel はこの理念の基礎です。Bazel ではすべての依存関係を完全に指定する必要があるため、どのプログラムやテストが変更の影響を受けるかを予測し、提出前に調査できます。
Google での開発プロセスについて詳しくは、エンジニアリング ツールに関するブログをご覧ください。
Bazel を公開したのはなぜですか？
ソフトウェアの構築は楽しく簡単に行う必要があります。ビルドが遅く、予測不能な場合は、プログラミングの楽しみが減ります。
Bazel を使用する理由
- Bazel では、再コンパイルが必要なファイルのみを再コンパイルできるため、ビルド時間を短縮できます。同様に、変更されていないことがわかっているテストの再実行もスキップできます。
- Bazel は決定論的な結果を生成します。これにより、増分ビルドとクリーンビルド、ノートパソコンと CI システムの間のスキューが解消されます。
- Bazel では、同じワークスペースから同じツールを使用して、さまざまなクライアント アプリとサーバーアプリをビルドできます。たとえば、クライアント/サーバーのプロトコルを 1 回の commit で変更し、更新されたモバイルアプリが更新されたサーバーで動作することをテストすることで、両方を同じツールでビルドし、前述の Bazel のメリットをすべて享受できます。
例を表示できますか？
はい。簡単な例をご覧ください。より複雑な例については、Bazel ソースコードをご覧ください。
Bazel の強み
Bazel は、次のプロパティを使用してプロジェクトのビルドとテストを行います。
- 大規模なコードベースを使用するプロジェクト
- （複数の）コンパイル言語で作成されたプロジェクト
- 複数のプラットフォームにデプロイするプロジェクト
- 広範なテストが必要なプロジェクト
Bazel はどこで実行できますか？
Bazel は Linux、macOS（OS X）、Windows で動作します。
他の UNIX プラットフォームへの移植は、そのプラットフォームで JDK が使用可能である限り、比較的容易になるはずです。
Bazel の使用が適していないケース
- Bazel はキャッシュ処理のスマート化に努めています。つまり、出力をキャッシュに保存すべきでないビルド オペレーションの実行には適していません。たとえば、次の手順は Bazel から実行しないでください。
- インターネットからデータを取得するコンパイル ステップ。
- サイトの QA インスタンスに接続するテストステップ。
- サイトのクラウド構成を変更するデプロイ手順。
- 長い連続したステップがいくつか実行されている場合、Bazel ではあまり役に立たないことがあります。長いステップを Bazel で並行して実行できる小さな個別のターゲットに分割することで、スピードが上がります。
Bazel の機能セットはどの程度安定していますか？
コア機能（C++、Java、シェルルール）は Google 社内で幅広く活用されているため、徹底的にテストされており、チャーンはほとんどありません。同様に、Bazel の新しいバージョンを毎日何十万ものターゲットでテストし、リグレッションを検出しています。新しいバージョンは毎月複数回リリースしています。
要するに、試験運用版とマークされている機能を除き、Bazel は正しく動作する必要があります。試験運用版以外のルールへの変更には下位互換性があります。機能のサポート状況の詳細については、サポート ドキュメントをご覧ください。
バイナリとして Bazel はどの程度安定していますか？
Google 社内では、Bazel によるクラッシュは非常にまれであることを確認しています。これは、Google のオープンソースのコードベースにも当てはまります。
Bazel の使用を開始するにはどうすればよいですか？
スタートガイドをご覧ください。
Docker は再現性の問題を解決しないのでしょうか。
Docker を使用すると、Ubuntu 12.04、Fedora 21 などの固定 OS リリースを使用したサンドボックスを簡単に作成できます。これにより、システム環境の再現性、つまり「どのバージョンの /usr/bin/c++ が必要か」が解決されます。
Docker では、ソースコードの変更に関する再現性には対応していません。Docker コンテナ内で不完全な Makefile を使用して Make を実行すると、予期しない結果が生じる可能性があります。
Google 内部では、再現性を確保するためにツールをソース管理にチェックインしています。このようにして、ベース ライブラリに対する変更と同じメカニズム（「OpenSSL の境界チェックを修正」）を使用して、ツールへの変更（「GCC を 4.6.1 にアップグレード」）を詳しく調べることができます。
Docker にデプロイするバイナリをビルドすることはできますか？
Bazel を使用すると、C/C++ で静的にリンクされたスタンドアロンのバイナリや、Java 用の自己完結型の jar ファイルをビルドできます。これらは通常の UNIX システムに依存することなく動作するため、Docker コンテナに簡単にインストールできるはずです。
Bazel には、一連のデータファイルを使用するか、別のプログラムをサブプロセスとして実行する Java プログラムなど、より複雑なプログラムを構築するための規則があります。このような環境はスタンドアロンのアーカイブとしてパッケージ化できるため、Docker イメージなどのさまざまなシステムにデプロイできます。
Bazel で Docker イメージをビルドできますか？
はい。Google の Docker ルールを使用して、再現可能な Docker イメージをビルドできます。
Bazel ではビルドが自動的に再現されますか？
Java バイナリと C++ バイナリの場合は、ツールチェーンを変更しない場合に限り可能です。カスタムレシピを含むビルドステップがある場合（ルール内のシェル スクリプトを使用してバイナリを実行する場合など）、特に注意が必要です。
- 宣言されていない依存関係は使用しないでください。サンドボックス化された実行（–spawn_strategy=sandboxed、Linux のみ）を使用すると、宣言されていない依存関係を検出できます。
- 生成されたファイルにタイムスタンプと User-ID を保存しないようにします。ZIP ファイルなどのアーカイブでは、この問題が特に発生しやすくなります。
- ネットワークに接続しないようにします。ここでも、サンドボックス化された実行が役立ちます。
- 乱数を使用するプロセスは避けてください。特に、多くのプログラミング言語では辞書走査がランダム化されています。
バイナリ リリースはありますか。
はい。最新のリリース バイナリとリリース ポリシーを確認できます。
Eclipse/IntelliJ/XCode を使用している。Bazel は IDE とどのように相互運用していますか？
IntelliJ については、IntelliJ with Bazel プラグインをご覧ください。
Xcode については、Tulsi をご覧ください。
Eclipse の場合は、E4B プラグインをご覧ください。
その他の IDE については、これらのプラグインの仕組みに関するブログ投稿をご確認ください。
Jenkins/CircleCI/TravisCI を使用しています。Bazel は CI システムとどのように相互運用していますか？
ビルドまたはテストの呼び出しが失敗した場合、Bazel はゼロ以外の終了コードを返します。基本的な CI 統合にはこれで十分です。Bazel では正確性を確保するためにクリーンビルドは必要ありません。そのため、ビルド/テストの実行を開始する前にクリーンビルドを行うように CI システムを構成しないでください。
終了コードについて詳しくは、ユーザー マニュアルをご覧ください。
Bazel では今後どのような機能が追加される予定ですか？
ロードマップをご覧ください。
INSERT LANGUAGE HERE プロジェクトで Bazel を使用できますか？
Bazel は拡張可能です。誰でも新しい言語のサポートを追加できます。多くの言語がサポートされています。推奨事項のリストについては、ビルドの百科事典をご覧ください。包括的なリストについては、awesomebazel.com をご覧ください。
拡張機能の開発やその仕組みについては、Bazel の拡張に関するドキュメントをご覧ください。
Bazel コードベースに貢献できますか？
投稿に関するガイドラインをご覧ください。
すべての開発がオープンな環境で行われないのはなぜですか？
今後も、Bazel で公開されているコードと内部拡張機能との間のインターフェースを頻繁にリファクタリングする必要があります。そのため、オープンで多くの開発を行うことが難しくなります。
Bazel のオープンソース化は完了しましたか？
Bazel のオープンソース化は現在作業中です。特に、Google は引き続きオープンソース化に取り組んでいます。
- 単体テストと統合テストの多くに、パッチの提供が容易になるはずです。
- IDE の完全な統合。
コードだけでなく、最終的にはすべてのコードレビュー、バグ トラッキング、設計上の決定事項を、Bazel コミュニティと協力して公開したいと考えています。まだ存在しないため、一部の変更は明確な説明なしに Bazel リポジトリに表示されるだけです。このように透明性が欠けているとはいえ、Google は外部のデベロッパーやコラボレーションを支援したいと考えています。そのため、一部の開発はまだ Google 社内で行われていますが、Google はコードを公開しています。オープンモデルに移行するにあたり、不明瞭な点や不当と思われる点がございましたら、お知らせください。
オープンソース化されない Bazel の部分はありますか？
はい。コードベースの一部は、Google 固有のテクノロジーと統合されているか、排除する言い訳を模索していました（またはその 2 つを組み合わせたものです）。コードベースのこれらの部分は GitHub には公開されておらず、おそらく今後も提供されることはないでしょう。
チームへの連絡方法を教えてください。
bazel-discuss@googlegroups.com までお問い合わせください。
バグはどこに報告すればよいですか？
GitHub で問題を報告する。
コードベースにある「Blaze」という言葉はどうでしょうか？
これはツールの内部名です。Blaze を Bazel と表記してください。
他の Google プロジェクト（Android、Chrome）が他のビルドツールを使用するのはなぜですか？
最初の（アルファ版）リリースまで、Bazel は外部で利用できなかったため、Chromium や Android などのオープンソース プロジェクトでは使用できませんでした。さらに、元々 Windows がサポートされていなかったことも、Chrome などの Windows アプリケーションを構築する際の問題でした。プロジェクトが成熟し、安定性が増したため、Android オープンソース プロジェクトの Bazel への移行が進んでいます。
「Bazel」はどう発音しますか？
英語の「BAY-zel」（バジル）と同じ意味です。「hazel」と韻を踏みます。IPA: /apigeebez 主要な