Googleはビルド ツールBazelをオープンソース化しました。このツールとGradleの違いは何ですか? Gradle にできなくてできること、Gradle のほうが優れていること、Gradle の方が優れていることは何ですか?
3 に答える
免責事項: 私は Bazel に取り組んでおり、Gradle について詳しくは知りません。しかし、私の同僚の 1 人が 2 つのシステムの比較を書いています。
Bazel と Gradle は、ビルド エクスペリエンスのさまざまな側面を強調します。ある程度、それらの優先順位には互換性がありません。柔軟性と邪魔にならないことに対する Gradle の欲求は、ビルド構造に課すことができる制限を制限しますが、信頼性とパフォーマンスに対する Bazel の欲求は、必然的に交渉不可能な制限を強制します。
Gradle は Bazel と同じ原則を尊重しています。つまり、Gradle チームはパフォーマンス (増分ビルド、並列化された構成と実行、Gradle デーモン)、正確性 (コンテンツベースの「最新」チェック)、および再現性に細心の注意を払っています。 (宣言構文、依存関係のバージョン管理、明示的に宣言された依存関係の豊富なサポート)。また、Bazel は柔軟なプロジェクト レイアウトの必要性を尊重しています。
ニュアンスは、Bazel がそれを要求したいのに対し、Gradle は優れた実践を促進したいということです。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 は主に JVM エコシステム (Java、Ggroovy、Scala、Kotlin ...) で使用されます。プロジェクトがこの分野にあり、質問をしなければならない場合は、Gradle または Maven を選択することをお勧めします。Gradle ビルドのトラブルシューティングを行うには、Java および JVM エコシステムのみを扱います。
Bazel の心臓部には、増分変更 (および分散ビルド キャッシュ) を検出する機能があり、対応して、プラグイン/ルールを適用して増分ビルドを実現できます。これをセットアップして維持するには、CPP、Java、および Python(Skylark) の知識と、システム管理者の知識も必要でした。繰り返しになりますが、質問する必要がある場合は、Gradle または Maven の方が安価な投資になると思います。Bazel を使用すると、どの言語をどのように定義しても、より強力に構築できますが、コストがかかります。