BazelとGradleの違いは何ですか？

Google はビルドツールBazelをオープンソース化したばかりです。このツールとGradleの違いは何ですか？Gradleでできないこと、Gradleでできること、Gradleでできることは何ですか？

免責事項：私はBazelで作業していますが、Gradleには詳しくありません。ただし、同僚の1人が2つのシステムの比較を書いたため、ここで言い換えます。

BazelとGradleは、ビルドエクスペリエンスのさまざまな側面を強調しています。ある程度、それらの優先順位は互換性がありません-Gradleの柔軟性と邪魔にならないことへの欲求はビルド構造に課すことができる制限を制限しますが、信頼性とパフォーマンスへのBazelの欲求は必然的に交渉できない制限を強制します。

GradleはBazelと同じ原則を重視しています。つまり、Gradleチームは、パフォーマンス（増分ビルド、並列化された構成と実行、Gradleデーモン）、正確性（コンテンツベースの「最新」のチェック）、再現性に大きな注意を払っています（宣言構文、依存関係のバージョン管理、明示的に宣言された依存関係の豊富なサポート）。また、Bazelは柔軟なプロジェクトレイアウトの必要性を尊重しています。

微妙な違いは、Gradleは良い習慣を促進したいが、Bazelはそれを要求したいということです。Gradleは、Antエクスペリエンス（一貫性のない結果を使用して独自のプロジェクト構造を定義する自由）とMavenエクスペリエンス（さまざまなプロジェクトのニーズに対応できる余地のない強化されたベストプラクティス）の中間点を目指しています。Bazelは、強力なワークフローを可能にする強力な保証を犠牲にすることなく、柔軟なプロジェクトサポートが可能であると考えています。

どちらの哲学もより「正しい」ものではありません。プロジェクトに最適なツールは、その特定のプロジェクトの値に依存します。

Gradleの概要

Gradleは非常に柔軟なシステムであり、ユーザーがプロジェクトの編成方法を最小限に抑えて、完全で信頼性の高いビルドフローを簡単に構築できます。これは、ユーザーが希望するこれらのブロックを組み合わせることができる汎用のチューリング完全なスクリプトインターフェイスを備えた強力なビルディングブロック（たとえば、自動依存関係の追跡と取得、緊密に統合されたプラグインサポート）を提供することで実現します。

Gradleは次の機能を強調しています。

• 他のシステムからの簡単な移行。Gradleは、任意のワークフロー構成を簡単に実装するために、任意のプロジェクト組織に簡単に対応します。Antタスクをネイティブに理解し、MavenおよびIvyリポジトリーとネイティブに統合します。
• 高度に拡張可能なスクリプトモデル。ユーザーはGroovyスクリプトを作成して、すべてのビルドロジックを実装します。「ビルド」とは、基本的にオープンエンドのオーバーライド可能で拡張可能なメソッド定義である、汎用タスクの依存関係シーケンス実行のことです。
• 豊富な依存関係管理。バージョン付きの依存関係を宣言し、外部コードリポジトリ、ローカルファイルシステム、およびその他のGradleプロジェクトから自動的にステージングできます。同様に、ビルド出力をリポジトリや他の場所に自動公開できます。
• 緊密に統合されたプラグインシステム。プラグインは、望ましいワークフローを容易にするために編成されたタスクのバンドルです。Gradleの「コア」機能の多くは、実際にはプラグイン（Java、Androidなど）を介して実装されています。プラグインは（独自の裁量で）ビルドスクリプトロジックと緊密に相互作用します。プラグインは、Gradleのコアデータ構造に深くアクセスできます。

バゼルの概要

Bazelは、内部のGoogleプロジェクトを確実かつ効率的に構築する必要性から発展しました。Googleの開発環境は非常に大規模で複雑なため、Bazelはビルドの整合性とそれらを実現する際の非常に低いパフォーマンスオーバーヘッドについて非常に強力な保証を提供します。

これは、再現可能なビルドを中心に構築された強力な開発ワークフローの基盤を提供します。「ビルド」は、参照、繰り返し、さまざまなマシンに渡され、任意のプログラムやサービスに渡され、すべてのインスタンスが認識されるようになる抽象的なエンティティになります。まったく同じ。

Bazelは次の機能を強調しています。

• 正当性。Bazelビルドは、常に正しい出力、期間を生成するように設計されています。2人のユーザーが、異なるマシンで同じBazelフラグを使用して同じコミットで同じビルドを呼び出す場合、同じ結果が表示されます。インクリメンタルビルドはクリーンビルドと同様に信頼性が高く、後者は本質的に不要になります。
• パフォーマンス。ビルドは、利用可能なリソースを前提として、本質的に可能な限り高速に実行されるように設計されています。タスクは、依存関係チェーンが許す限り並列化できます。不要な作業は決して実行されません（つまり、「最新の」タスクは常にスキップされます）。当然、ローカルのマシン制限を克服するために、リモートエグゼキューターに作業を委託することができます。
• 再現性。ビルドのインスタンスは、どの環境でも忠実に再現できます。たとえば、バグレポートでソフトウェアYのバージョンXが本番環境Zで失敗した場合、開発者は自分のマシンで忠実に再現し、同じことをデバッグしていると確信できます。

記事へのリンクが途絶える傾向があるため、ここにGradleチームのBazelに対する見解の要約を示します（ほとんどは、2015年3月に公開された記事から直接取り上げられています）。

Google特有の問題を解決するために設計されました。大規模なモノリシックコードベース（数億のLOC）。

Bazelが現在提供している並列化の利点は、「今後の新しい構成とコンポーネントモデル」と一致します（この記事の日付を覚えておいてください）。

Bazelには、開発者がビルドを簡単に使用できるようにする高レベルの宣言型ビルド言語がありません。Googleでは、ビルドツールを所有する専門のサービスチームでこれを補うことができます。

Bazelは拡張性のために構築されていません（ただし、Bazel開発チームは、拡張性に取り組んでいることを保証して、これに対抗しています）。

速度は、すべての推移的な依存関係が1つの大きなリポジトリに格納されるという考えに基づいて最適化されています。すべてのライブラリとツールは、この中央リポジトリにチェックインされています。ほとんどの企業には、より多くの分散依存関係管理要件があります。

Bazelは* nixのみで、Windowsでは実行できません。これにより、多数の潜在的な企業が排除されます。

プラグインのエコシステムはありません。

Gradleは主にJVM ecoシステム（Java、Ggroovy、Scala、Kotlinなど）で使用されます。プロジェクトがこの領域にあり、質問をする必要がある場合は、GradleまたはMavenの方が適しています。Gradleビルドのトラブルシューティングを行うには、JavaおよびJVMエコシステムのみを使用します。

中心となるBazelには、増分変更（および分散ビルドキャッシュ）を検出する機能があり、プラグインやルールを適用して増分ビルドを実現できます。これをセットアップして維持するには、CPP、Java、Python（Skylark）に関する多少の知識とシステム管理者の知識も必要でした。繰り返しますが、質問をする必要がある場合は、GradleまたはMavenの方が投資が安くなると思います。Bazelを使用すると、どの言語をどの方法で定義しても、より強力に、しかもコストをかけて構築できます。