ご不明な点やサポートが必要な場合は、ヘルプの利用をご覧ください。
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 が内部でサーバー ソフトウェアのビルドに使用するツールの一種です。また、Google のサーバーに接続するモバイルアプリ（iOS、Android）など、他のソフトウェアの構築にも拡大されています。
社内ツールをオープンソースとして書き直しましたか？フォークですか？
Bazel はコードのほとんどを内部ツールと共有し、そのルールは毎日数百万件のビルドに使用されています。
Google が Bazel を構築した理由
昔、Google は生成された大規模な Makefile を使用してソフトウェアを構築していました。その結果、ビルドが遅く信頼性に欠け、デベロッパーの生産性と会社のアジリティに支障をきたすようになりました。Bazel は、これらの問題を解決する方法でした。
Bazel にはビルドクラスタが必要ですか？
Bazel はデフォルトでビルド オペレーションをローカルで実行します。ただし、Bazel はビルドクラスタに接続して、ビルドとテストをさらに高速化することもできます。詳細については、リモート実行とキャッシュ保存とリモート キャッシュ保存に関するドキュメントをご覧ください。
Google の開発プロセスの仕組み
サーバー コードベースには、次の開発ワークフローを使用します。
- すべてのサーバーコードは、単一の巨大なバージョン管理システムに格納されています。
- 誰もが Bazel でソフトウェアをビルドしています。
- 各チームがソースツリーの異なる部分を所有し、コンポーネントを
BUILDターゲットとして利用できるようにします。 - ブランチは主にリリースの管理に使用されるため、すべての人がヘッド リビジョンでソフトウェアを開発します。
Bazel はこの哲学の基盤です。Bazel ではすべての依存関係を完全に指定する必要があるため、変更の影響を受けるプログラムとテストを予測し、送信前に検証できます。
Google の開発プロセスの詳細については、eng tools ブログをご覧ください。
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 内で広範に使用されているため、徹底的にテストされており、変更はほとんどありません。同様に、Google では Bazel の新しいバージョンを毎日何十万ものターゲットでテストして回帰を検出し、毎月複数回新しいバージョンをリリースしています。
つまり、試験運用版としてマークされている機能以外は、Bazel は「Just Work」です。試験運用版以外のルールへの変更は下位互換性があります。機能のサポート ステータスの詳細なリストについては、サポート ドキュメントをご覧ください。
Bazel のバイナリの安定性はどの程度ですか？
Google では、Bazel のクラッシュが非常にまれになるようにしています。これは、オープンソースのコードベースにも当てはまります。
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 イメージをビルドできますか？
はい。Docker ルールを使用して、再現可能な Docker イメージをビルドできます。
Bazel はビルドを自動的に再現可能にしますか？
Java バイナリと C++ バイナリの場合、ツールチェーンを変更しない限り、はい。カスタム レシピを含むビルドステップ（ルール内のシェル スクリプトによるバイナリの実行など）がある場合は、特に注意が必要です。
- 宣言されていない依存関係は使用しないでください。サンドボックス化された実行（–spawn_strategy=sandboxed、Linux のみ）を使用すると、宣言されていない依存関係を見つけることができます。
- 生成されたファイルにタイムスタンプとユーザー 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 には今後どのような機能が追加される予定ですか？
ロードマップをご覧ください。
Bazel を INSERT LANGUAGE HERE プロジェクトで使用できますか？
Bazel は拡張可能です。新しい言語のサポートは誰でも追加できます。多くの言語がサポートされています。推奨される言語の一覧については、Build Encyclopedia を、より包括的な一覧については awesomebazel.com をご覧ください。
拡張機能を開発する場合や、拡張機能の仕組みについて詳しくは、Bazel の拡張に関するドキュメントをご覧ください。
Bazel コードベースに貢献できますか？
投稿に関するガイドラインをご覧ください。
すべての開発が公開されていないのはなぜですか？
それでも、Bazel の公開コードと内部拡張機能の間のインターフェースを頻繁にリファクタリングする必要があります。そのため、オープンで多くの開発を行うことは困難です。
Bazel のオープンソース化は完了しましたか？
Bazel のオープンソース化は現在も開発中です。特に、以下のオープンソース化に取り組んでいます。
- 多くの単体テストと統合テスト（パッチの提供が容易になります）。
- IDE との完全な統合。
最終的には、コードだけでなく、すべてのコードレビュー、バグトラッキング、設計上の決定を公開し、Bazel コミュニティを巻き込んで行いたいと考えています。まだその段階に達していないため、一部の変更は明確な説明なしで Bazel リポジトリに表示されます。透明性が欠如しているにもかかわらず、Google は外部デベロッパーをサポートし、協力したいと考えています。そのため、一部の開発は Google 内部で行われていますが、コードは公開しています。オープンモデルへの移行に際して、不明瞭な点や不当と思われる点がございましたら、お知らせください。
Bazel の一部はオープンソース化されないのですか？
はい。一部のコードベースは Google 固有のテクノロジーと統合されているか、削除する口実を探していました（またはその両方）。コードベースのこれらの部分は GitHub では利用できません。今後も利用できるようになる可能性は低いでしょう。
チームに連絡するにはどうすればよいですか？
bazel-discuss@googlegroups.com までお問い合わせください。
バグを報告するにはどうすればよいですか？
GitHub で問題を報告してください。
コードベースに「Blaze」という単語が含まれているのはなぜですか？
これはツールの内部名です。Blaze は Bazel として参照してください。
他の Google プロジェクト（Android、Chrome）では他のビルドツールが使用されているのはなぜですか？
最初の（アルファ版）リリースまでは、Bazel は外部で利用できないため、Chromium や Android などのオープンソース プロジェクトでは使用できませんでした。また、元々 Windows がサポートされていなかったため、Chrome などの Windows アプリケーションのビルドに問題がありました。プロジェクトが成熟し、安定性が向上したため、Android オープンソース プロジェクトは Bazel に移行中です。
「Bazel」の発音は？
米国英語の「バジル」（ハーブ）と同じように「ベイゼル」と発音します。「ヘーゼル」と韻を踏みます。IPA: /ˈbeɪzˌəl/