ご質問がある場合やサポートが必要な場合は、サポートをご覧ください。
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 よりもはるかに構造化されているため、各アクションの動作を正確に理解できます。これにより、並列処理が促進され、再現性が向上します。
- どちらのツールもそれぞれ Twitter、Foursquare、Facebook の元 Google 社員によって開発、開発されました。Bazel に基づいてモデル化されていますが、機能セットが異なるため、代替手段としては有効ではありません。
Bazel はどこから来たのですか?
Bazel は、Google がサーバー ソフトウェアを社内で構築するために使用するツールのフレーバーです。Google のサーバーに接続するモバイルアプリ(iOS、Android)など、他のソフトウェアの構築にも拡大しています。
内部ツールをオープンソースとして書き直しましたか?フォークですか?
Bazel はコードのほとんどを内部ツールと共有しており、そのルールは毎日数百万のビルドで使用されています。
Google が Bazel をビルドしたのはなぜですか?
昔、Google は大規模な Makefile を使用してソフトウェアを構築していました。その結果、ビルドの速度が遅くなり、信頼性も損なわれ、デベロッパーの生産性と会社のアジリティを損なうようになりました。Bazel は、このような問題を解決するための手段でした。
Bazel にはビルドクラスタが必要ですか?
デフォルトでは、Bazel はビルド オペレーションをローカルで実行します。ただし、Bazel をビルドクラスタに接続して、ビルドとテストをさらに高速化することもできます。詳しくは、リモート実行とキャッシュとリモート キャッシュに関するドキュメントをご覧ください。
Google の開発プロセスの仕組み
サーバーコードベースでは、次の開発ワークフローを使用します。
- サーバーコードはすべて、単一の巨大なバージョン管理システムにあります。
- 誰もが 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 内で広く使用されているため、徹底的にテストされており、チャーンはほとんどありません。同様に、Google では Bazel の新しいバージョンを数十万のターゲットで毎日テストして回帰を検出しており、新しいバージョンを毎月複数回リリースしています。
要するに、試験運用版とマークされている機能を除き、Bazel は動作しません。試験運用版でないルールの変更には下位互換性があります。機能のサポート状況について詳しくは、サポート ドキュメントをご覧ください。
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 ファイルなどのアーカイブは、特にこの傾向が強くなります。
- ネットワークに接続しないでください。この場合もサンドボックス化された実行が役立ちます。
- 乱数を使用するプロセスは避けてください。特に、多くのプログラミング言語では辞書走査がランダム化されています。
バイナリ リリースはありますか?
はい。最新のリリース バイナリを入手して、Google のリリース ポリシーを確認してください。
Eclipse/IntelliJ/XCode を使用している。Bazel と IDE の相互運用の仕組みを教えてください
IntelliJ については、IntelliJ での IntelliJ プラグインの使用をご確認ください。
Xcode については、Tulsi をご確認ください。
Eclipse の場合は、E4B プラグインを確認します。
他の IDE については、これらのプラグインの仕組みに関するブログ投稿をご覧ください。
Jenkins、CircleCI、TravisCI を使用しています。Bazel と CI システムの相互運用について教えてください
ビルドまたはテストの呼び出しが失敗した場合、Bazel はゼロ以外の終了コードを返します。基本的な CI 統合にはこれで十分です。Bazel は正確性のためにクリーンビルドを必要としないため、ビルド/テストの実行を開始する前にクリーンアップするように CI システムを構成するべきではありません。
終了コードの詳細については、ユーザー マニュアルをご覧ください。
Bazel に今後どのような機能が追加される予定ですか?
ロードマップをご覧ください。
[ここに言語を挿入] プロジェクトで Bazel を使用できますか?
Bazel は拡張可能です。誰でも新しい言語のサポートを追加できます。多くの言語がサポートされています。推奨事項のリストについては、ビルド百科事典を、包括的なリストについては awesomebazel.com をご覧ください。
拡張機能の開発やその仕組みについては、Bazel の拡張のドキュメントをご覧ください。
Bazel コードベースに貢献できますか?
投稿に関するガイドラインをご覧ください。
すべての開発がオープンで行われるわけではないのはなぜでしょうか。
依然として、Bazel の公開コードと内部拡張機能の間のインターフェースを頻繁にリファクタリングする必要があります。そのため、オープンで多くの開発を行うことが困難になっています。
Bazel のオープンソース化は完了していますか?
Bazel のオープンソース化は現在進行中です。特に、オープンソース化に取り組み続けています。
- 単体テストと統合テストの多く(パッチの提供が容易になるはずです)。
- IDE との完全な統合。
コードだけでなく、最終的にはすべてのコードレビュー、バグ トラッキング、設計上の決定が、Bazel コミュニティとともに公開されていきたいと考えています。ここにはまだ確認されていないため、いくつかの変更点は単に Bazel リポジトリに表示されるだけで、明確な説明はありません。このような透明性はないものの、外部のデベロッパーを支援し、協力したいと考えています。したがって、開発の一部はまだ Google 社内で行われていても、コードを公開しています。オープンモデルに移行するにあたり、不明瞭、不当と思われる点がありましたらお知らせください。
決してオープンソース化されない Bazel の部分はありますか?
はい。コードベースの一部は、Google 固有のテクノロジーと統合されているか、排除するための言い訳を探している(またはその 2 つの組み合わせである)かのいずれかです。コードベースのこれらの部分は GitHub では提供されておらず、今後さらに増える可能性はあります。
チームへの連絡方法を教えてください。
bazel-discuss@googlegroups.com までご連絡ください。
バグを報告するにはどうすればよいですか?
GitHub で問題を報告します。
コードベースの「Blaze」という言葉はどうなってる?
これはツールの内部名です。Bazel は Bazel です。
他の Google プロジェクト(Android、Chrome)が他のビルドツールを使用するのはなぜですか?
Bazel は、最初の(アルファ版)リリースまで外部に提供されていなかったため、Chromium や Android などのオープンソース プロジェクトでは使用できませんでした。さらに、当初は Windows がサポートされていなかったことが、Chrome などの Windows アプリケーションを構築するうえで問題となっていました。プロジェクトが成熟して安定しているため、Android オープンソース プロジェクトが Bazel への移行作業中です。
「Bazel」はどのように発音しますか?
アメリカ英語の「バジル」(ハーブ)と同じ意味の「BAY-zel」。「hazel」と韻を踏む。IPA: /~be>"zèñèl/