Gradleとは？詳しく説明させていただきます

TOP
コラム
Gradleとは？詳しく説明させてい

Gradleの概要について

ここでは、Gradleについて説明させていただきます。
GradleはApache AntやApache Mavenのコンセプトに基づくオープンソースビルド自動化システムであり、プロジェクト設定の宣言にはApache Mavenが利用するXML形式ではなくGroovyベース、もしくはKotlin Scriptベースのドメイン固有言語（DSL）を採用します。 Gradleはタスクの起動順序の決定に有向非巡回グラフ（DAG）を利用します。 Gradleの理解を深めるために簡単にGradleにおける有向非巡回グラフ（DAG）について説明させていただきます。
有向非巡回グラフ（DAG）は、多くの種類の関係をモデル化するために使用できるデータ構造の一種です。有向非巡回グラフという名前は、ノードとエッジの有限セットを持ち、有向非巡回グラフの両方を持っていることを意味します。有向非巡回グラフ（DAG）はグラフ理論における閉路のない有向グラフとなります。有向グラフは頂点と有向辺（方向を示す矢印付きの辺）からなり、辺は頂点同士を繋ぎます。一方である頂点から出発し、辺をたどり、頂点に戻ってこないのが有向非巡回グラフ（DAG）です。有向非巡回グラフ（DAG）は、さまざまなタイプの関係をモデル化するために使用できるデータ構造のタイプです。このタイプのグラフは、人工知能やデータ構造などのコンピューターサイエンスアプリケーションにとっても重要です。また、有向非巡回グラフ（DAG）はデータが1つのステージから別のステージにどのように移動するかを示すために、多くの業界やビジネスプロセスで使用されています。有向非巡回グラフ（DAG）が組織またはビジネスプロセスのワークフローを表すために使用することも、プロジェクトを完了するために完了する必要のあるタスクを表すために使用することもできます。
Gradleにおける有向非巡回グラフ（DAG）についても説明させていただきます。 Gradleは、そのビルドをタスク（作業単位）の有向非巡回グラフ（DAG）としてモデル化します。これが意味するのは、ビルドは基本的に一連のタスクを構成し、それらの依存関係に基づいてそれらを相互に接続して、その有向非巡回グラフ（DAG）を作成することです。タスクグラフが作成されると、Gradleはどのタスクをどの順序で実行する必要があるかを判断し、それらの実行に進みます。ほとんどすべてのビルドプロセスは、この方法でタスクのグラフとしてモデル化できます。これが、Gradleが非常に柔軟である理由の1つとなります。また、そのタスクグラフは、プラグインと独自のビルドスクリプトの両方で定義でき、タスクはタスク依存関係メカニズムを介してリンクされます。

タスクについて

Gradleのタスクに関しても説明させていただきます。アクションは、ファイルのコピーやソースのコンパイルなどの行う作業です。入力は、アクションが使用または操作する値、ファイル、およびディレクトリです。出力は、アクションが変更または生成するファイルとディレクトリです。タスクはタスク依存関係メカニズムを介してリンクされます。 Gradleのタスク依存関係メカニズムはその名の通り、他のタスクに依存するタスクを宣言するための記述です。
Gradleは、ドメイン固有言語（DSL）を使用してプロジェクトの依存関係を定義し、タスクのライフサイクルを制御し、ビルドプロセスを構成するという点がその特徴となります。 Gradleはさまざまなプログラミング言語をサポートしており、MavenリポジトリとIvyリポジトリの両方で使用することが可能です。 Gradleは、コードのコンパイル、テスト、レポートの生成、JavaやC++ファイルなどの複数のソースからのアプリケーションのビルドを行うことができるという点で多くのソフトウェア開発者に利用されており、それらはオープンソースとして無料で使用できます。 Gradleがソフトウェアエンジニアに人気のある理由は柔軟性、信頼性、直感性を備えた設計になっていることが最大の理由と言うことができ、その中でも特に柔軟性については特筆すべき点があります。

GradleではGroovyを何故採用したのかという点についても簡単に触れておきます。そもそもビルドスクリプトを記述するということを考えたとき最適なプログラミング言語は複数存在します。 Gradleはチームメンバーに対してできるだけ分かりやすいものであるべきだと考えています。そのためには多くの開発者にとって最も認知度の高いプログラミング言語であるJavaを採用すべきと考える方が多いかもしれません。ところがGradleでは、Javaはビルド用の言語として使うには表現力や機能に限界があり、 Groovy、Python、Rubyのような言語の方が向いているとしております。その中でもJavaエンジニアにとって理解しやすいGroovyを選択したというのがその背景になります。そもそもGroovyの文法は、型システム、パッケージ構造、その他諸々についてJavaをベースにしていることがその理由です。 Groovyは、スクリプトやWeb開発に使用できる動的言語として多くのユーザーに利用されております。その特徴はすべての主要なオペレーティングシステムにインストールでき、インストールを必要とせず、メモリフットプリントも小さくなります。 Groovyは、Java仮想マシン（JVM）で実行されるオブジェクト指向プログラミング言語でもあり Webアプリケーションを開発するためのJavaの代替として2005年に最初にリリースされたという歴史を持ちます。 Groovyは主にJavaプログラミング言語で記述されており、一部のクラスはPythonやRubyなどの他の言語で記述されています。 Gradleでは、オンデマンドで適用できるさまざまなプラグインを介してビルドを構成する方法を提供します。これにより、追加の構成を必要とせずに、Gradleがあらゆる種類のプロジェクトで作業できるようになります。
Gradleはインクリメンタルビルドを提供するため、信頼性が高いことも特徴の一つです。具体的にはGradleではコードに1つだけ変更を加えた場合でも、Gradleはプロジェクトの必要な部分のみを再コンパイルするため、毎回すべてを最初から再ビルドするための時間とリソースを節約することが可能です。

また、GradleはJavaでのコマンドラインビルドに比べて多くの利点があります。さらに詳しくGradleの特徴についていくつか説明させていただきます。 GradleはJava、C ++、Python、または選択した言語で記述することが可能であり、任意のプラットフォームに展開することが可能です。 Gradleの大きな特徴である多様性を利用して、あらゆる構築を可能にする点もその特徴と言えるでしょう。また、Gradleは豊富なAPIとプラグインと統合を提供し、自動化をよりスムーズに実行するための支援を実現し、ソフトウェアの配信をエンドツーエンドでモデル化し、統合し体系化します。 Gradleのテクノロジーはエレガントかつ超高速のビルドで開発をスケールアウトします。コンパイルの回避から高度なキャッシングまで実行し、高いパフォーマンスを提供します。以上がGradleの概要についての説明とさせていただきます。
次にGradleについて具体的な手順を説明しながら紹介させていただきますので参考にしてみてください。

Gradleの詳細について

Gradleについて いくつかのトピックに分類し紹介させていただきますので、参考にしてみてください。
まずはGradleのインクリメンタルビルドについて説明させていただきます。インクリメンタルビルドは、前のビルド状態を利用して、前の状態が計算されてから変更されたリソースに対し、構成されているビルダーによる変換を適用するビルドを指します。継続的インテグレーションと継続的デリバリーのバックボーンとなり、これらは常にリリース可能な状態にあるソフトウェアリリースを作成する方法を提供します。開発者がコードの変更に関するフィードバックをできるだけ早く取得できるようにするために重要となることがポイントとなり、このフィードバックは、バグを本番環境に移行する前にキャッチするために重要です。さらに詳しく説明させていただきますと、インクリメンタルビルドは、継続的デリバリーのデフォルトとなります。これらは差分ビルドよりも高速で効率的ですが、すべてのプロジェクトに常に適しているとは限りません。
その理由の1つは、インクリメンタルビルドでは、ディファレンシャルビルドとは異なり、変更によって何かが壊れたときに検出できないことです。ディファレンシャルビルドは、変更によって何かが壊れているかどうかを検出するための追加の手順が必要になるため、インクリメンタルビルドよりも低速で効率が低くなります。ただし、差分ビルドには、何かが壊れたときにそれを検出できるという利点があります。そのため開発者は、稼働する前にそれを修正することができるという利点があります。いずれにせよ開発者は自身のプロジェクトに見合った方法を選択しビルドするといいでしょう。

もう少し詳しく説明させていただきます。 GradleにおいてJavaCompileなどの組み込みタスクは、一連の入力と一連の出力を宣言します。 Gradleはこの情報を使用して、タスクが最新であり、作業を実行する必要があるかどうかを判断します。入力または出力のいずれも変更されていない場合、Gradleはそのタスクをスキップできます。この動作はGradleのインクリメンタルビルドサポートと呼ばれております。これらのインクリメンタルビルドサポートを利用するには、タスクの入力と出力に関する情報をGradleに提供する必要があり、出力のみを持つようにタスクを構成することが可能です。タスクを実行する前に、Gradleは出力をチェックし、出力が変更されていない場合はタスクの実行をスキップします。実際のビルドでは、タスクには通常、ソースファイル、リソース、プロパティなどの入力も含まれます。Gradleは、タスクを実行する前に、入力も出力も変更されていないことを確認します。また、多くの場合、タスクの出力は別のタスクへの入力として機能します。これらのタスク間の順序を正しくすることが重要です。そうしないと、タスクが間違った順序で実行されるか、まったく実行されません。Gradleは、ビルドスクリプトでタスクが定義される順序に依存しません。新しいタスクは順序付けされていないため、実行順序はビルドごとに変わる可能性があります。例えばあるタスク間の依存関係を宣言することで、2つのタスク間の順序をGradleに明示的に伝えることができます。以上が簡単ではありますがGradleのインクリメンタルビルドに関する説明とさせていただきます。

並行処理

Gradleの並行処理について説明させていただきます。
これによってパフォーマンスを向上されることに繋がります。 WorkerAPIを介してタスクとタスク内作業を並行して実行することが可能となります。 WorkerAPIとは、タスクを自動化するように設計されたAPIの一種です。これらのAPIは特定のタスク用に構築されており、開発者がバックグラウンドジョブを作成および管理する機能を提供するオープンソースプロジェクトです。企業はさまざまな理由でWorkerAPIを使用していますが、主な理由の1つはビジネスの変革です。 Worker APIは、タスクを自動化し、生産性を向上させることで、企業がビジネスをより効率的にするのに役立ちます。
ワーカーAPIは、特定のプロセスを自動化するビジネスに非常に役立ちます。どのプラットフォームでも使用でき、さまざまなプログラミング言語からアクセスできます。タスクが実行する作業は、個別のユニットであり作業単位は互いに高度に独立して存在しております。 Gradleの並行処理については、これらの作業単位は任意の順序で実行し集約してタスクの全体的なアクションを形成します。
例えばシングルスレッド実行では、これらの作業単位は順番に実行されますが、複数のプロセッサがある場合は、独立した作業単位を同時に実行することが望ましいでしょう。そうすることで、ビルド時に利用可能なリソースを十分に活用し、タスクのアクティビティをより迅速に完了することができます。 Worker APIのテクノロジーによりこれらを実現し、タスクアクション中に複数の作業項目を安全に同時に実行することが可能となります。

Worker APIの利点は、タスクの作業を並列化することだけではありません。また、分離されたクラスローダーまたは分離されたプロセスで作業を実行できるように、必要なレベルの分離を構成することもできます。
その利点は、単一のタスクの実行を超えて拡張されます。Worker APIを使用すると、Gradleはデフォルトでタスクの並列実行を開始できますのでタスクが非同期で実行される作業を送信し、タスクアクションを終了すると、Gradleは同じプロジェクト内にある場合でも、他の独立したタスクの実行を並行して開始できます。以上が簡単ではありますがGradleの並行処理についての説明とさせていただきます。

実行オプション

Gradleの実行オプションに関する機能についてもいくつか紹介させていただきます。まずは継続的ビルドです。継続的インテグレーションは、すべての開発者のコード変更を複数回にわたり共有メインラインにマージするプロセスです。このプロセスの主な目標は、潜在的なバグをできるだけ早く特定することです。継続的インテグレーションは本番環境にバグを導入するリスクを軽減すること、ソフトウェア配信を加速すること、ソフトウェアの品質と保守性が向上することなどのメリットがあり、現在のソフトウェア開発において重要なキーワードとなっております。これらに関連するキーワードとしてDevOpsがあります。こちらも非常に重要なキーワードであり、特にクラウド時代におけるソフトウェア開発においては必須の知識と言えるでしょう。
DevOpsは、開発者がコードの変更をより簡単かつ迅速に本番環境にデプロイできるようにする一連のプラクティスです。タスクを自動化するプロセスは、自動化と呼ばれることは周知の通りですが、DevOpsのおけるソフトウェア開発は自動化を使用して、プロセスの効率と一貫性を高めることが重要なテーマです。もちろん本文で紹介させていただくGradleもそれらのために重要なテクノロジーの一つと言えるでしょう。 DevOpsを実現するために開発者は、テスト、展開、パッケージ化などのさまざまなタスクに自動化ツールを導入し、それぞれの工程におけ開発プロセスを改善し、より効率的で一貫性のある開発を実現します。また、DevOpsツールは、開発者と運用チームがより効率的に連携できるようにする目的で導入されます。これらにより、開発者と運用者のコラボレーションが向上し、アプリケーションのライフサイクルの可視性が高まり、結果として市場投入までの時間が短縮されビジネスの成功率を高めます。

DevOpsの目標は、新機能を入手するのにかかる時間を短縮することです。このため、ニーズに応じて使用できるDevOpsツールにはさまざまな種類があります。従来の開発における考え方では解決できない課題も、DevOpsによる様々な工程をオートメーションする手法や拡張性により解決する可能性が高まるという特徴を持ちます。開発工程はDevOpsツールチェーンと呼ばれる各プロセスによって分担されており、それらを繰り返すことで構築されます。
DevOpsツールチェーンは計画、コーディング、ビルド、テスト、導入、運用、監視から構成されております。また、それぞれのカテゴリーにおいて、自動化を行うために有効なツールが存在します。 DevOpsはアジャイルに近しい考え方や概念を持ちますが、DevOpsとアジャイルは両者共にソフトウェア配信を高速化できる構造とフレームワークを提供することが可能です。それらの違いは哲学やアプローチ、考え方は異なりますが両立しない概念ではありません。 DevOpsではソフトウェアの開発と配信のすべての段階に対応し、より迅速で信頼性の高いリリースを目指すことや、部門を超えたチームワークを育成する文化により、職場環境を向上させて、より効果的なチームを作り上げること、あるいはワークフローの自動化を行う機会を可能な限り見つけて、効率的な開発を行うことが目的です。一方でアジャイルでは使い慣れた計画ツールによって作業を追跡し、要件、タスク、進捗を整理しながら作業を行い一貫した開発周期を実践し顧客のニーズに応えていく形となります。

Gradleの実行オプションに関する機能は上記の説明と大きな関連性があります。 Gradleタスクが連続モードで実行されると、Gradleはこのタスクの入力の変更を自動的に監視します。入力が変更されるたびに、入力が自動的に実行したタスクが実施され、マルチプロジェクトビルドでは、複数のタスクを継続的に実行できます。
また、複合ビルドを使用すると、他の独立したプロジェクトを含めることができるため、たとえば、アプリケーションとそれが依存するライブラリを同時に開発できます。これらはデフォルトで並列に構築され、ネストすることができます。
また、Gradleでは最初の障害後もすぐに停止はせずに実行するすべてのタスクを実行します。その後そのタスクのすべての依存関係が失敗することなく完了します。1回のビルド実行で可能な限り多くの障害を検出でき、最後に非常に集約エラーレポートが表示されるため、自動的にスムーズなビルドを実現することが可能となります。

ソフトウェアドメインモデリング

Gradleのソフトウェアドメインモデリングについても説明させていただきます。
ドメインモデリングは、システムのドメインを分析および設計するプロセスです。これは、ドメインエンジニアリングの重要なステップです。また、これらはさまざまなコンポーネントとそれらの相互関係を特定することを含みます。ドメインモデリングは、問題のあるドメインを定義して理解するプロセスです。これは、システムの境界を定義し、システムの内部または外部にあるものを識別するのに役立ちます。ドメインモデリングはさまざまな方法で実行できますが、最も一般的な方法は次のとおりです。ドメイン駆動設計（DDD）、データ駆動型設計（D3）、オブジェクトロールモデリング（ORM）、統一モデリング言語（UML）、プロトタイピングなどです。 Gradleのドメインオブジェクトコンテナではリポジトリ、ソースディレクトリ、プラグイン、依存関係など、ビルドを説明するすべてのドメインオブジェクトは、リスナーを登録できるレスポンシブコンテナに保存されます。特定のビルドスクリプトがビルドに追加するものを完全に制御できます。追加されたものを拡張または変更し、ビルドを失敗させるか、警告を発行します。たとえば、ビルドが特定のプラグインを追加する場合にのみ追加される定義依存関係を追加することができる機能です。
また、Gradleオブジェクトは、どのタスクが特定のコンテンツを生成するかを認識しています。たとえば、Javaバイナリディレクトリを表すオブジェクトは、コンパイルタスクがバイナリを生成することを認識しています。入力としてJavaバイナリディレクトリを持つタスクは、自動的にコンパイルタスクに依存します。手動で宣言する必要はありません。これにより、ビルドの保守が容易になり、堅牢になります。
以上が簡単ではありますがGradleに関する説明とさせていただきます。

Gradle Enterpriseについて

Gradleでは、より高い機能を必要とする企業向けにGradle Enterpriseを提供しております。
Gradle Enterpriseを利用すると開発者はよりソフトウェアのビルドとテストのプロセスとデータ分析を高速化し、トラブルシューティンを効率的に実行することが可能となります。これは、開発者生産性エンジニアリングの新たな実践を可能にする重要なテクノロジーであり、多くの大手企業に導入されているのがGradle Enterpriseです。それではGradle Enterpriseの特徴についていくつか紹介させていただきます。

高速化

Gradle Enterpriseの機能の一点目が高速化です。
Gradle EnterpriseではGradle Enterprise Build Cache＆Test Distributionという機能を提供しております。 Gradle Enterprise Build Cache＆Test Distributionは、GradleおよびMavenビルドのフィードバックサイクルを高速化を実現し開発者の生産性を向上させ、より頻繁にビルドするように促すことでデバッグがはるかに簡単になり、ソフトウェアの品質が向上します。これによって開発者はビルドが完了するまでのアイドル時間を短縮すること、複数のプロセスを切り替えるためのコストやパフォーマンスの低下を実現することが可能となり、DevOpsにとって必要不可欠である高速フィードバックサイクルの実現を可能とします。
高速フィードバックサイクルは創造的な流れを維持し、迅速に反復し、機敏性を維持するために重要であることは言うまでもありません。また、高速フィードバックサイクルは開発者の行動の質を上げ品質の向上をあげることにも繋がります。 Gradle Enterprise Build Cache＆Test Distributionでは開発サイクルの後の段階に品質チェックをプッシュするのではなく、ビルドとテストをより頻繁に実行するように開発者を促します。これにより開発者が変更セットの複合化に関連する問題のデバッグに費やす時間が少なくて済むためテストやその他の安全対策をオフにしてより早く出荷するなどの手抜きをせず品質の担保に寄与します。

Gradle Enterprise Build Cache＆Test Distributionを導入することで、ビルドおよびテストに関するアクセラレーションテクノロジーを促進することができます。 Gradle Enterprise Build Cache＆Test Distributionでは様々な機能を提供しており、組み合わせることでより効率的なビルドとテストの高速化を実現することが可能です。キャッシュの構築、予測テストの選択、テストの配布、パフォーマンスの継続性の4つの大きな機能に分類されております。これらを組み合わせて利用することで、パフォーマンスアクセラレーションアプローチを促進し、平均フィードバックサイクル時間をさらに短縮し個々の時間やコストを削減することが可能となります。

キャッシュの構築

まずはキャッシュの構築から説明させていただきます。
Gradle EnterpriseではGradle Enterprise Build Cacheという機能を導入しておりビルド時間を大幅に短縮することが可能です。 Gradle Enterprise Build CacheはGradleビルドツールを使用する開発者のローカルフィードバックサイクルを高速化するために、2017年にリリースされました。また、2019年にはGradle Enterprise Maven拡張機能は、Mavenビルドツールユーザーに対してビルドキャッシュソリューションをリリースしました。
これによりGradle Enterpriseのではパフォーマンスプロファイリングおよび分析機能とともに、非効率性の発見、最適化の機会の特定など多くの効率化とスケーラブルなバックエンドを提供することに成功しました。ビルドキャッシュは、コンパイル、テスト、ソースコード生成、Javadoc、checkstyle、PMDなどのビルドアクションに適用することが可能でありビルドキャッシングは、多くの標準的なGradleタスクとMavenの目標に対してすぐに機能します。
Gradle Enterprise Build Cache＆Test Distributionはローカル、リモート、およびCIビルドをサポートしておりクラウドのコストとリソース消費の効率も向上させるためにも適しております。

Gradle Enterprise Build Cacheのキャッシュ構築についてさらに詳しく解説させていただきます。 Gradle Enterprise Build Cacheでは、わずかな労力でステートレスキャッシュをデプロイして運用します。ローカルキャッシングはGradleBuildToolに組み込まれており、リモートキャッシュノードではDocker、Kubernetes、スタンドアロンのJARデプロイメントオプションを利用できます。また、Gradle Enterprise Build Cacheでは高度に観察可能な構成およびパフォーマンスデータを表示します。 Gradle Enterprise Build Cacheのビルドスキャンを使用して、キャッシュリクエスト、ヒット、ミス、キャッシュに保存された入力、構成設定など、すべてのローカル、リモート、およびCIビルドのビルドキャッシュ構成設定とパフォーマンスデータを表示します。
Gradle Enterprise Build Cacheではダッシュボードを利用することで様々なデータを監視し活用することが可能です。具体的にはPerformance and Trendsダッシュボードという機能を利用します。これを利用することで開発者はフィードバックサイクル時間に対するビルドキャッシュの影響を継続的に監視し、事前に修正が必要になる可能性のある速度の低下を監視することが可能となります。 Gradle Enterprise Build Cacheでは自動化されたターゲットキャッシュサイズ管理を実行します。これはキャッシュオブジェクトを格納するためにディスク上で利用可能な限り多くのスペースを使用するようにビルドキャッシュを構成し、ストレージボリュームサイズをターゲットキャッシュサイズと同期する必要をなくすことが可能です。また、Gradle Enterprise Build Cacheではデータのプライバシーとアクセス制御を実行し不正アクセスを防止します。以上が簡単ではありますがキャッシュの構築に関する説明とさせていただきます。

予測テストの選択

次に予測テストの選択について説明させていただきます。
Gradle EnterpriseではGradle Enterprise Predictive Test Selectionを利用することでテスト時間を大幅に短縮することが可能となります。機械学習モデルを採用しており、テストの実行中に有用なフィードバックを提供する可能性のあるテストのみを識別、優先順位付け、実行することで、テスト時間を節約することを実現します。利用することで付加価値のないテストを回避し、テスト時間を削減しながらも品質を担保します。また、開発者のアイドル時間を軽減しチーム全体に生産性を与えコスト削減やパフォーマンス向上に寄与することが可能です。
Gradle Enterprise Predictive Test Selectionを構成するコーポネントについて簡単に紹介させていただきます。一つが予測テスト選択シミュレーターです。予測テスト選択シミュレーターのダッシュボードを利用して、事前に実際のテスト結果と比較して予測をシミュレートすることができます。これによりどのテストを選択し最適化するかということを決定することができます。具体的にはPredictive Test Selectionという機能を利用することでGradle Enterpriseによってキャプチャされた幅広いテストデータを参照しモデルトレーニングからの不安定なテスト結果をフィルタリングできるようにします。これにより、非常に正確なテスト予測を実現できます。すでに説明させていただきましたように、Gradle Enterprise Predictive Test Selectionは機会学習モデルを取り入れ改善を行っております。機械学習モデルをトレーニングするために、Predictive Test Selectionは、バージョン管理システムから利用できるものだけでなく、プロジェクトリポジトリファイルシステムの内外のデータへの変更から学習しテスト予測の改善を実施します。また、Gradle Enterprise Predictive Test Selectionではリスク分析を実施しそれらを確認することができます。予測テスト選択を有効にする前に、実際のテスト結果とシミュレートされた選択結果を比較するため、リスクとメリットを完全に把握することが可能です。以上が簡単ではありますが予測テストの選択に関する説明とさせていただきます。

テスト配布

次にテスト配布について説明させていただきます。
Gradle EnterpriseではTest Distributionを利用することでテスト時間を大幅に短縮することが可能となります。 Test Distributionはテストの並列処理に対するアプローチとして機能し、既存のテストスイートを取得し、それらをリモートエージェント全体に分散し高速にテストを実行することでテスト時間の短縮を実現します。 Gradle Enterpriseではテストが過去の実行時間に基づいて分割および分散されます。コードカバレッジレポートなどのテスト出力ファイルは、エージェントから転送され、自動的にマージされます。リモートエージェントの数は、自動スケーリングを介してオンデマンドでスケーリングが実現されます。 Test Distributionのテスト配布はローカルビルドとCIビルドで機能するため、開発者はCIサーバーがテストを実行するのを待つ必要がなくなります。
Test Distributionの大きな特徴がテストにおける並列処理です。並列処理を実施することができないことでテストセットのサイズが大きくなることでコストと時間がかかる一方です。また、大規模または複雑なアプリケーションは、ビルドのテストフェーズに大部分の時間を費やしてしまう傾向があります。 Test Distributionでは並列されたテスト処理でそのようなリスクを防ぎます。また、単一マシンの並列処理は高速化を実現することができる一方で様々なリスクもあります。それは開発マシーンのリソースやコストなどです。 Test Distributionでは上記のような従来の問題を解決した最新のテスト配布ソリューションを提供し、すべてのローカルビルドとCIビルドで使用することができます。テストはローカルでなく分散された方法で自動的に実行されるため、開発者のワークフローに変更がないため開発者に支障を与えずスムーズにテストを実行することが可能です。また、ビルド呼び出しとCIジョブが1つしかないため、CIユーザーエクスペリエンスはCIファンアウトを比較した場合優れているといえるでしょう。以上が簡単ではありますがテスト配布に関する説明とさせていただきます。

パフォーマンスの継続性

次にパフォーマンスの継続性について説明させていただきます。
Gradle EnterpriseではGradle Enterprise Performance Continuityによってパフォーマンスの継続性を提供します。具体的にはGradle Enterprise Performance Continuityではビルド環境のビルド時間とテスト時間のパフォーマンス継続性を維持するための補完的な分析および診断ツールの包括的なセットを提供します。 Gradle Enterprise Performance Continuityではパフォーマンスプロファイリングデータと分析手法により、コードアーキテクチャ、テクノロジースタック、およびその他の制約を考慮して、ビルドのパフォーマンスレベルを長期にわたって最適化および維持することでビルドやパフォーマンスを可視化し、継続的監視することでチームの生産性を高めます。また、本文で紹介しておりますGradleEnterpriseの機能と連携することでGradle Enterprise Performance Continuityは様々な効果をチームに与えます。

では、Gradle Enterprise Performance Continuityの機能について簡単に紹介させていただきます。
一点目がパフォーマンストレンドダッシュボードです。パフォーマンストレンドダッシュボードは日、週、月といった検索条件とフィルターに一致するビルド全体のビルドパフォーマンスメトリックをインタラクティブかつ多次元で視覚化したものです。 Gradle Enterprise Performance Continuityの機能を利用することでビルド時間、タスクの並列化、増分ビルド、およびビルドキャッシュの有効性に関連する特定のパフォーマンス特性または異常を伴うビルドの検出と分析が容易になり、開発者を強力に支援して品質の担保に寄与します。
二点目がタイムラインプロファイルの作成です。これはビルドアクションが実行される順序、実行のクリティカルパスと同時実行性、実行期間、および入力のスナップショット、コードのコンパイル、依存関係のダウンロード、アノテーションの実行に費やされた時間などの詳細を視覚化することができる機能です。これらの機能を利用することで、開発者はどの機能やプロセスを最適化するかすぐに判断および評価することが可能となります。また、Gradle Enterprise Performance Continuityのビルドスキャンでは合計ビルド時間、初期化と構成時間と実行時間、合計ガベージコレクション時間、ピークヒープメモリ使用量など、すべてのビルドのパフォーマンスの詳細についてUIと記録を提供します。

Gradle Enterprise Performance Continuityの構成時間プロファイルも重要な機能の一つです。これは、合計構成時間を提供しビルドスクリプトのコンパイルに費やされた時間およびプラグインの適用に費やされた時間の間の構成実行時間を分割します。これによって開発者は構成時間を最小限に抑えるための投資に優先順位を付けることができます。それだけでなくライフサイクルコールバックのようにどのボトルネックに焦点を当てるべきかを判断するのに役立つためチーム全体の生産性を向上させることが可能となるでしょう。
Gradle Enterprise Performance Continuityの依存関係解決プロファイルについても紹介させていただきます。これはビルドスキャンの際に個々のビルドの依存関係の解決に費やされた時間の詳細を把握することができる機能です。また、それらを視覚化することで CIビルドのビルド時間コスト、ネットワークパフォーマンスの低下、または頻繁な依存関係の変更を特定することの役に立ちます。
Gradle Enterprise Performance Continuityのアクション実行プロファイルの作成では、サポートデータを使用した作業回避統計やビルドスキャン内のビルド実行の詳細の集約ビューが提供されます。このプロファイルは様々な集計統計と組み合わせて活用することができます。以上が簡単ではありますがパフォーマンスの継続性に関する説明とさせていただきます。

トラブルシューティング

Gradle Enterpriseの機能の二点目がトラブルシューティングとなります。
BuildScanを利用することでデバック時間を大幅に短縮することが可能となります。それらを実現するのが、Gradle Enterpriseのテクノロジーです。 Gradle EnterpriseのBuildScanでは開発者にすべてのビルドの詳細なデータを提供することで、壊れたビルドを再実行やビルドチームの助けを必要することなく根本原因をすばやく見つけて問題を修正することが可能となります。インシデントの原因を特定するためのデータを迅速に提供しトラブルシューティングに時間をかけません。そのため開発チームの生産性を向上させ、無駄なコストを削減することが可能となります。また、Gradle Enterpriseでは最適化を特定するため必要なデータを提供することにより、ビルドキャッシュと組み合わせてビルドを高速化することが可能です。 DevOpsのチームを成立させ効率的な開発を実現するために必要であることは各チームのスムーズな連携であることは言うまでもありません。 BuildScanでは開発チームにデータを提供して、ビルドチームを関与させずにビルドの問題を解決することが可能であり、そのプロセスでより簡単に共同作業できるようにすることによりスムーズな連携と開発を実現することが可能となります。
BuildScanについての技術的な説明についても簡単に紹介させていただきます。ビルドの共有可能な記録として活用することが可能で、ビルドスキャンをscans.gradle.comに公開するとGradleおよびMaven ビルドとそれらの環境に関する情報がGradleのサーバーに送信されます。情報には、ビルドの最後に印刷されたランダムに生成されたリンクを介してアクセスでき、終了したらビルドスキャンを削除することができます。これらを利用することで障害レポートを表示しチーム間で共有することができるようになります。ビルドアクションレベルのデータを使用すると、ビルド内のすべてのタスクと依存関係に関する豊富なデータにアクセスしメンバー間で共有することができるようになります。
以上が簡単ではありますがGradle Enterpriseのトラブルシューティングに関する説明とさせていただきます。

障害分析

Gradle Enterpriseの機能の三点目が障害分析となります。
Gradle Enterprise Failure Analyticsはビルドとテストの信頼性を向上させるためのソリューションを提供する機能です。様々なデータと分析から信頼性の低いビルドとテストを発見しその影響などを調査し、関係者に対して共有することで、開発者はより早くテストを修正し、生産性と効率、サービス品質、配信速度などビジネスの品質向上を実現することができます。
では、提供している機能について具体的に紹介させていただきます。 Gradle Enterprise Failure Analyticsでは、テスト失敗時の結果分析を実行します。例えば再試行メカニズムとBuildScanを使用することでローカルビルドを含むすべてのMavenおよびGradleビルドの不安定なテストを確実に検出することが可能です。
また、不安定なテスト履歴を観察しそれらの悪影響が時間の経過とともにどのように増加または減少しているかを測定し開発者に表示します。また、不安定なテストを効率的に修正します。これらの結果はダッシュボードに可視化され、すぐに問題内容や個所を特定できるようになっております。ビルドの障害分析も実行し影響に基づいて修復のために回避可能なビルドの失敗を検出して優先順位を付けます。以上が簡単ではありますがGradle Enterpriseの障害分析に関する説明とさせていただきます。

パフォーマンスの視覚化

Gradle Enterpriseの機能の四点目がパフォーマンスの視覚化となります。
Gradle Enterprise Trends and Insightsの機能を利用することで、開発者は主要な指標とベースラインに基づいて過去のパフォーマンスを視覚化できます。これにより、開発者は、再発する問題や長期的なパフォーマンスの低下にプロアクティブに対応するための洞察を得ることが可能となります。また、開発した後に何からの問題に気がつくのではなく、事前に対応を実施することでパフォーマンスを高めることが可能でありプロジェクトを健全な状態に保つことが可能となります。多くのプロジェクトにおいて一定のリグレッションが発生してしまうのは仕方がないと考えられるケースもありますが、導入することで問題を先取りし、解決することが可能となります。具体的には、開発をブロック疎外する要因や影響力のある不安定なテストやパフォーマンスの低下を軽減している最新の重大なバグのトラブルシューティングを特定し、それらの対処を行います。効率の悪いプロジェクトにおいては開発者やテストエンジニアは問題後の対応に時間を費やされているため、それらに役立つデータの獲得や今後の対応といった部分が疎かになってしまうという点は大きな問題です。 Gradle Enterprise Trends and Insightsではそれらの問題に対処したソリューションを提供します。例えば、システム上の問題や長期的なパフォーマンスの低下にプロアクティブに対応するためのプラットフォームの提供がそれらに該当します。これは、主要な指標とKPIをより観察可能で実用的なものにすることで、プロジェクトを支援します。

では、さらに詳しく解説させていただきます。 Gradle Enterprise Trends and Insightsではパフォーマンスと信頼性のベースラインと異常の可観測性を提供することにより、開発チームが積極的な姿勢を取ることを可能にします。プロジェクトにおいてパフォーマンス改善を実施するためには様々な指標を明確にし、測定することが必要となります。重要な指標をそもそも数値化していないプロジェクトも多いため、測定していないものを改善することは難しいと言えますが、導入することで常に学習し、継続的に改善する文化を構築するための基盤を構築することが可能となります。これらは長期的にみて組織のパフォーマンス向上に繋がることは間違いありません。
Gradle Enterprise Trends and Insightsのコンポーネントには、ローカルビルドとCIビルドのビルドとテストの失敗のトレンド、ローカルビルドとCIビルドのビルドとテストのパフォーマンスのトレンド、およびデータのエクスポートが含まれます。
これらのコンポーネントについて簡単に紹介させていただきます。テストの失敗のトレンドを理解することは非常に重要ですが、それらを視覚的に把握することが可能です。 Gradle Enterprise Trends and Insightsではビルドとテストの安定性の傾向を幅広く正確に把握します。例えば単一のプロジェクト、ビルドエージェント、およびgitブランチの正確なエラーメッセージなどをグラフ化し開発者やテストエンジニアが確認し、チームで共有することが可能になります。また、問題が再発した場合、履歴データによりタイムラインと障害パターンがすばやく表示され、解決時間が大幅に短縮されます。これによりテストの失敗のトレンドを素早く理解することができるようになります。
以上が簡単ではありますがパフォーマンスの視覚化に関する説明とさせていただきます。

まとめ

いかがでしたでしょうか？ Gradleについて紹介させていただきましたので、参考にしていただけましたら幸いです。