ご不明な点がある場合やサポートが必要な場合は、ヘルプの利用をご覧ください。
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 の開発プロセスはどのように機能しますか?
サーバー コードベースには、次の開発ワークフローを使用します。
- すべてのサーバーコードは、単一の巨大なバージョン管理システムにあります。
- すべての人が Bazel を使用してソフトウェアをビルドします。
- ソースツリーの異なる部分を異なるチームが所有し、コンポーネントを
BUILD
ターゲットとして利用できるようにします。 - ブランチは主にリリースの管理に使用されるため、すべてのユーザーがヘッド リビジョンでソフトウェアを開発します。
Bazel はこの哲学の要です。Bazel ではすべての依存関係を完全に指定する必要があるため、変更の影響を受けるプログラムとテストを予測し、送信前に検証できます。
Google の開発プロセスについて詳しくは、エンジニアリング ツールブログをご覧ください。
Bazel をオープンソース化したのはなぜですか?
ソフトウェアの構築は楽しく簡単であるべきです。ビルドが遅く、予測できないと、プログラミングの楽しさが失われます。
Bazel を使用する理由
- Bazel では、再コンパイルが必要なファイルのみを再コンパイルできるため、ビルド時間を短縮できます。同様に、変更されていないことがわかっているテストの再実行をスキップできます。
- Bazel は決定論的な結果を生成します。これにより、増分ビルドとクリーンビルド、ノートパソコンと CI システムなどの間のスキューが解消されます。
- Bazel は、同じワークスペースから同じツールを使用して、さまざまなクライアント アプリとサーバーアプリをビルドできます。たとえば、1 回の commit でクライアント/サーバー プロトコルを変更し、更新されたモバイルアプリが更新されたサーバーで動作することをテストできます。両方を同じツールでビルドし、Bazel の前述のメリットをすべて享受できます。
例を見せていただけますか?
はい。簡単な例をご覧ください。より複雑な例については、Bazel ソースコードをご覧ください。
Bazel の得意なことは何ですか?
Bazel は、次のプロパティを持つプロジェクトのビルドとテストに優れています。
- 大規模なコードベースを持つプロジェクト
- (複数の)コンパイル言語で記述されたプロジェクト
- 複数のプラットフォームにデプロイするプロジェクト
- 大規模なテストがあるプロジェクト
Bazel はどこで実行できますか?
Bazel は、Linux、macOS(OS X)、Windows で動作します。
プラットフォームで JDK が利用可能であれば、他の UNIX プラットフォームへの移植は比較的容易です。
Bazel を使用すべきでないのはどのような場合ですか?
- Bazel はキャッシュ保存を賢く行おうとします。つまり、出力がキャッシュに保存されないビルド オペレーションの実行には適していません。たとえば、次の手順は Bazel から実行しないでください。
- インターネットからデータを取得するコンパイル ステップ。
- サイトの QA インスタンスに接続するテストステップ。
- サイトのクラウド構成を変更するデプロイ ステップ。
- ビルドが長い連続したステップで構成されている場合、Bazel はあまり役に立たない可能性があります。長いステップを Bazel が並列実行できる小さな個別のターゲットに分割すると、速度が向上します。
Bazel の機能セットはどの程度安定していますか?
コア機能(C++、Java、シェルルール)は Google 内部で幅広く使用されているため、徹底的にテストされており、変更はほとんどありません。同様に、Bazel の新しいバージョンを毎日何十万ものターゲットでテストして回帰を見つけ、毎月複数回新しいバージョンをリリースしています。
つまり、試験運用とマークされている機能を除き、Bazel は正常に動作するはずです。試験運用以外のルールの変更には後方互換性があります。機能のサポート ステータスの詳細なリストについては、サポート ドキュメントをご覧ください。
バイナリとしての Bazel の安定性はどの程度ですか?
Google では、Bazel のクラッシュが非常にまれであることを確認しています。これはオープンソースのコードベースにも当てはまるはずです。
Bazel の使用を開始するにはどうすればよいですか?
スタートガイドをご覧ください。
Docker で再現性の問題は解決されないのですか?
Docker を使用すると、Ubuntu 12.04、Fedora 21 などの固定 OS リリースでサンドボックスを簡単に作成できます。これにより、システム環境の再現性(「どのバージョンの /usr/bin/c++ が必要か」)の問題が解決されます。
Docker は、ソースコードの変更に関する再現性に対応していません。Docker コンテナ内で不完全な Makefile を使用して Make を実行すると、予期しない結果が生じる可能性があります。
Google では、再現性を確保するために、ツールをソース管理にチェックインしています。このようにして、ツールへの変更(「GCC を 4.6.1 にアップグレード」)を、ベース ライブラリへの変更(「OpenSSL の境界チェックを修正」)と同じメカニズムで審査できます。
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 の今後の機能について教えてください。
ロードマップをご覧ください。
INSERT LANGUAGE HERE プロジェクトで Bazel を使用できますか?
Bazel は拡張可能です。新しい言語のサポートは誰でも追加できます。多くの言語がサポートされています。推奨事項の一覧についてはビルド百科事典、より包括的な一覧については awesomebazel.com をご覧ください。
拡張機能を開発する場合や、拡張機能の仕組みについて学習する場合は、Bazel の拡張に関するドキュメントをご覧ください。
Bazel コードベースに貢献できますか?
投稿に関するガイドラインをご覧ください。
すべての開発がオープンに行われないのはなぜですか?
Bazel の公開コードと内部拡張機能の間のインターフェースは、頻繁にリファクタリングする必要があります。そのため、オープンな開発は難しくなります。
Bazel のオープンソース化は完了しましたか?
Bazel のオープンソース化は現在も進行中です。特に、以下のオープンソース化に取り組んでいます。
- 多くの単体テストと統合テスト(パッチの投稿が容易になります)。
- IDE との完全な統合。
コードだけでなく、最終的にはすべてのコードレビュー、バグの追跡、設計の決定を Bazel コミュニティの参加を得て公開で行いたいと考えています。まだそこまで進んでいないため、一部の変更は明確な説明なしに Bazel リポジトリに表示されます。透明性が低いにもかかわらず、Google は外部デベロッパーをサポートし、連携したいと考えています。そのため、開発の一部は Google の内部で行われていますが、コードを公開しています。オープンモデルへの移行にあたり、ご不明な点やご不満な点がございましたら、お知らせください。
Bazel の一部はオープンソース化されないのですか?
はい。コードベースの一部は Google 固有のテクノロジーと統合されているか、Google が削除する理由を探している(またはその両方の組み合わせ)ものです。コードベースのこれらの部分は GitHub で入手できません。今後も入手できない可能性があります。
チームに連絡するにはどうすればよいですか?
bazel-discuss@googlegroups.com までお問い合わせください。
バグはどこに報告すればよいですか?
GitHub で問題を報告してください。
コードベースの「Blaze」という単語は何ですか?
これはツールの内部名です。Blaze は Bazel と呼んでください。
他の Google プロジェクト(Android、Chrome)が他のビルドツールを使用しているのはなぜですか?
最初の(アルファ版)リリースまで、Bazel は外部で利用できなかったため、Chromium や Android などのオープンソース プロジェクトでは使用できませんでした。また、当初は Windows のサポートがなかったため、Chrome などの Windows アプリケーションの構築に問題がありました。プロジェクトが成熟し、より安定したため、Android オープンソース プロジェクトは Bazel への移行を進めています。
「Bazel」の発音は?
米国英語の「basil」(ハーブ)と同じように「ベイゼル」と発音します。「hazel」と韻を踏みます。IPA: /ˈbeɪzˌəl/