[解決済み] BazelとGradleの違いは何ですか？

質問

Googleだけ オープンソース そのビルドツール バゼル . このツールは グラードル ? Gradleにできなくて何ができるのか、何が優れているのか、そしてGradleは何が優れているのか？

どのように解決するのですか？

免責事項: 私はBazelで働いており、Gradleに精通しているわけではありません。 しかし、同僚の一人がこの2つのシステムの比較を書いてくれたので、ここで言い換えることにします。

BazelとGradleは、ビルドエクスペリエンスの異なる側面を重視しています。Gradleは柔軟性と控えめさを求めるあまり、ビルド構造に置ける制限を制限し、一方Bazelは信頼性とパフォーマンスを求めるあまり、譲れない制限を必然的に強いてしまうのです。

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

ニュアンスとしては、Gradleは良い習慣を促進したいのに対して、Bazelはそれを要求したいのです。Gradleは、Antの経験（支離滅裂な結果を伴う独自のプロジェクト構造を定義する自由）とMavenの経験（様々なプロジェクトのニーズに対応できない強制されたベストプラクティス）の間の中間を目指します。Bazelは、強力なワークフローを可能にする強力な保証を犠牲にすることなく、柔軟なプロジェクトサポートが可能であると信じています。

どちらの考え方が「正しい」ということはなく、どのツールがプロジェクトに最も適しているかは、そのプロジェクトの価値観によります。

Gradleの概要

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

Gradleは以下のような特徴を重視しています。

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

Bazelの概要

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

これにより、再現可能なビルドを中心とした強力な開発ワークフローの基盤が構築され、「ビルド」は、参照、反復、異なるマシンへの受け渡し、任意のプログラムやサービスへの受け渡しが可能で、すべてのインスタンスが完全に同じであることが分かっている抽象的な存在となります。

バゼルは次のような特徴を強調している。

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