よくある質問

ご不明な点またはサポートのご要望がございましたら、サポートをご覧ください。

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 は各アクションの処理を正確に理解できます。これにより、並列処理と再現性が向上します。
  • パンツ、バック: どちらのツールも、Twitter と Foursquare、Facebook で元 Google 社員がそれぞれ開発と開発を行いました。いずれも Bazel を基にモデル化されていますが、機能セットが異なるため、Google は代替のツールとして使用できません。

Bazel の開発元

Bazel は、Google がサーバー ソフトウェアを社内でビルドするために使用するツールです。Google のサーバーに接続するモバイルアプリ(iOS、Android)など、他のソフトウェアもビルドするように拡張されました。

内部ツールをオープンソースに書き換えましたか?これはフォークですか?

Bazel はほとんどのコードを内部ツールと共有し、そのルールが毎日何百万ものビルドに使用されます。

Google が Bazel を開発したのはなぜですか?

Google は以前から、サイズの大きな Makefile を使用してソフトウェアを構築していました。その結果、ビルドが遅くなり、信頼性も低くなり、デベロッパーの生産性や会社のアジリティを損なう結果となりました。こうした問題を解決するのが Bazel でした。

Bazel にはビルドクラスタが必要ですか?

Bazel は、デフォルトでローカルでビルド オペレーションを実行します。Bazel はビルドクラスタに接続して、ビルドとテストをさらに高速化することもできます。詳細については、リモート実行とキャッシュおよびリモート キャッシュに関するドキュメントをご覧ください。

Google の開発プロセスの仕組み

サーバーコード ベースでは、次の開発ワークフローを使用します。

  • サーバーコードはすべて、1 つの巨大なバージョン管理システムにあります。
  • 全員が 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 は正常に動作するはずです。試験運用版ではないルールへの変更には、下位互換性を持たせます。機能のサポート状況について詳しくは、サポート ドキュメントをご覧ください。

バイナリとしての 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 プログラムや、サブプロセスとして別のプログラムを実行する 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 を使用できますか?

Bazel は拡張可能です。新しい言語のサポートは誰でも追加できます。さまざまな言語がサポートされています。推奨事項の一覧についてはビルド 百科事典を、より包括的なリストについては Awesomebazel.com をご覧ください。

拡張機能の開発や動作の詳細については、Bazel の拡張のドキュメントをご覧ください。

Bazel コードベースに貢献できますか?

詳しくは、寄付に関するガイドラインをご覧ください。

すべての開発がオープンに行われていないのはなぜですか?

Bazel の公開コードと内部拡張機能間のインターフェースを頻繁にリファクタリングしなければなりません。その結果、オープン環境で多くの開発を行うことが難しくなります。

Bazel のオープンソース化を完了していますか。

Bazel のオープンソース化は進行中です。特に、Google は現在もオープンソース化に取り組んでいます。

  • 単体テストと統合テストの多く(パッチ提供が容易になるはずです)
  • IDE との完全な統合

コードの他には、最終的に Bazel コミュニティに関し、すべてのコードレビュー、バグ トラッキング、設計上の決定を一般公開したいと考えています。まだ変更が行われているため、変更内容が Bazel リポジトリに表示されるだけで、明確な説明はありません。Google はこのような透明性に欠けているものの、外部デベロッパーをサポートし、協力したいと考えています。したがって、開発の一部がまだ Google 内部で行われている場合でも、コードをオープンにします。オープンモデルへの移行に伴い、不明確な点や不当と思われる点がありましたら、お知らせください。

オープンソースに決してオープンソース化されない Bazel はありますか?

はい、一部のコードベースは Google 固有のテクノロジーと統合されているか、Google が除去する口実を求めています(または両者の組み合わせ)。コードベースのこの部分は GitHub では使用できず、おそらくないでしょう。

チームに問い合わせるにはどうすればよいですか?

bazel-discuss@googlegroups.com までお問い合わせください。

バグを報告する場所

GitHub でイシューを作成します。

コードベースの「Blaze」という語句はどうなっているのですか?

ツールの内部的な名前です。Bazel として参照してください。

他の Google プロジェクト(Android、Chrome)で他のビルドツールを使用する理由

最初の(アルファ版)リリースまで Bazel は外部で利用できなかったため、Chromium や Android などのオープンソース プロジェクトでは使用できませんでした。また、当初は Windows サポートの欠如が Chrome などの Windows アプリケーションの構築における問題でした。プロジェクトが成熟し、安定性が改善されたため、Android オープンソース プロジェクトは Bazel への移行を進めています。

「Bazel」の発音は?

アメリカ英語の「バジル」(ハーブ)と同じ意味で、「BAY-zel」です。 「ヘーゼル」とよく結びつきます。 IPA: /いたします!