BazelとGradleの違いは何ですか？
免責事項：私はBazelで作業しており、Gradleに精通していません。しかし、同僚の1人が2つのシステムの比較を書いたので、ここで言い換えます
BazelとGradleは、ビルドエクスペリエンスのさまざまな側面を強調しています。ある程度、それらの優先順位は互換性がありません。Gradleの柔軟性と控えめさに対する欲求は、ビルド構造に課せられる制限を制限しますが、Bazelの信頼性とパフォーマンスへの欲求は必然的に交渉不可能な制限を強制します。
Gradleは、Bazelと同じ原則を重視しています。つまり、Gradleチームは、パフォーマンス（増分ビルド、並列化された構成と実行、Gradleデーモン）、正確性（コンテンツベースの「最新」チェック）、および再現性に多大な注意を払っています（宣言構文、依存関係のバージョン管理、明示的に宣言された依存関係の豊富なサポート）。また、Bazelは柔軟なプロジェクトレイアウトの必要性を尊重しています。
ニュアンスは、Grazelがグッドプラクティスを促進したいのに対し、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で失敗すると言われた場合、開発者は同じものをデバッグしているという自信を持って自分のマシンで忠実に再作成できます。
記事のリンクは死ぬ傾向にあるため、ここに BazelについてのGradleチームの見解 の要約を示します（ほとんどは2015年3月に発行された記事から直接引用されています）。
Google固有の問題を解決するために設計されました。巨大なモノリシックコードベース（数億のLOC）。
Bazelが現在提供している並列化の利点は、「今後の新しい構成およびコンポーネントモデル」と一致します（ここの記事の日付を念頭に置いてください）。
Bazelには、開発者がビルドを簡単に使用できるようにする高レベルの宣言型ビルド言語がありません。 Googleでは、ビルドツールを所有する専門のサービスチームでこれを補うことができます。
Bazelは拡張性のために構築されていません（ただし、Bazel開発チームはその後、拡張性に取り組んでいるという保証でこれに対抗しています）。
速度は、すべての推移的な依存関係が1つの大きなリポジトリに格納されるという考えに基づいて最適化されます。すべてのライブラリとツールはこの中央リポジトリにチェックインされます。ほとんどの企業には、より多くの分散依存関係管理要件があります。
Bazelは* nixのみで、Windowsでは実行されません。これにより、多数の潜在的な企業が排除されます。
プラグインエコシステムはありません。