【実務・中級編】Gradleのタスク実行をカスタマイズ！doFirstとdoLastを駆使したビルド前後の処理注入 – ビルド・パッケージ管理ツール生産性向上バイブル

こんにちは。テックリードの私だ。

日々の開発で、MavenからGradleへ移行したものの、結局 `build` や `assemble` を漫然と叩くだけになっていないだろうか？ 「なんか速いから良し」としているなら、Gradleが持つ本当の狂気的なまでの拡張性と生産性ドジの大部分をブッ捨てていると言っていい。

今回は、Gradleのライフサイクルを完全にハックし、ビルドの構造体に独自の処理をねじ込む `doFirst` と `doLast` の極意を授ける。単なる「ログを出す」「ファイルを消す」といったお遊戯ではない。エンタープライズの現場でCI/CDパイプラインを強靭化し、開発スピードを次元の違うレベルへ引き上げるための実践知をコードと共に焼き付ける。

—

1. なぜ「タスクのライフサイクル理解」がプロの条件なのか

多くのエンジニアは、Gradleを「上から順にスクリプトが実行されるツール」だと誤解している。だが、Gradleの本質は 「DAG（有向非巡回グラフ）の構築と実行エンジン」 だ。

Gradleのビルドは、以下の3つのフェーズで厳密に駆動している。

1. 初期化フェーズ (Initialization): マルチプロジェクトの構成を決定する。
2. 構成フェーズ (Configuration): 全タスクのスクリプトを評価し、タスク間の依存関係グラフ（DAG）を構築する。
3. 実行フェーズ (Execution): 構成フェーズで決定された順序に従って、タスクのアクションを実行する。

ここで多くの者がハマる罠が、「構成フェーズで重い処理を書いてしまい、何もビルドしていないのに異様に時間がかかる」 という現象だ。`doFirst` と `doLast` は、まさにこの 「実行フェーズ」のジャストなタイミングに処理を遅延・介入させる ための最強のメスである。

—

2. `doFirst` と `doLast` の内部挙動：クロージャとタスクアクション

Gradleのタスク（`Task`）は、内部にアクションリスト（Action List）を保持している。
タスクを定義したときに書く処理は、デフォルトでこのアクションリストの「末尾」に追加されていく。

• `doFirst { … }`: アクションリストの最先頭に新しい処理を割り込ませる。
• `doLast { … }`: アクションリストの最末尾に新しい処理を追加する（実は `task.doLast` は `task.actions.add()` と同義である）。

これを利用することで、既存のタスク（例えばJavaプラグインの `compileJava` や `jar`）の挙動を1行も書き換えることなく、「直前の前処理」と「直後の後処理」を安全にインジェクションできるのだ。

—

3. 実践：現場で即効性を発揮する `build.gradle.kts` ベストプラクティス

現代のGradle開発では、Groovyではなく型安全かつIDEの補完が圧倒的に強力な Kotlin DSL (`build.gradle.kts`) がデファクトスタンダードだ。

以下に、実務でそのまま使える、ログ出力・成果物の動的改変・外部APIへのWebhook通知を盛り込んだプロダクションレベルの設定例を示す。

plugins {
java
application
}

group = “com.enterprise.core”
version = “2.4.1”

repositories {
mavenCentral()
}

java {
toolchain {
languageVersion.set(JavaLanguageVersion.of(17))
}
}

// —————————————————————————
// 実践的カスタムタスク: アーティファクトの署名・検証とメトリクス通知の模倣
// —————————————————————————
val securePackageTask by tasks.registering {
group = “DevOps”
description = “プロダクションリリース前の厳密なセキュリティチェックとパッケージングを行う”

// 1. 依存関係の明示：jarタスクが完了していなければこのタスクは実行されない
dependsOn(tasks.jar)

// — 【doFirst】 実行フェーズの直前（jarの生成が終わり、このタスクが動く直前）に走る —
doFirst {
println(“==================================================”)
println(“[SECURITY HOOK] 厳格なパッケージング処理を開始します…”)
println(“ターゲットバージョン: ${project.version}”)

// 実行直前にビルドディレクトリの整合性を最終確認（ファイルが存在するかチェック）
val libsDir = layout.buildDirectory.dir(“libs”).get().asFile
if (!libsDir.exists()) {
throw GradleException(“致命的エラー: libs ディレクトリが存在しません。ビルドフローが破損しています。”)
}
println(“[SECURITY HOOK] 整合性チェック完了。問題なし。”)
println(“==================================================”)
}

// — 通常のアクション（必要に応じてここにメイン処理を書くが、今回は委譲） —
doFirst {
// doFirstは複数記述可能。記述した順に「さらに前」に割り込む（LIFOではなくFIFOでリストに追加される点に注意）
println(“[INFO] タイムスタンプ付与: ${java.time.Instant.now()}”)
}

// — 【doLast】 すべての処理が正常終了した「直後」に走る —
doLast {
val buildDir = layout.buildDirectory.get().asFile
println(“==================================================”)
println(“[NOTIFY HOOK] ビルド成果物のハッシュ値を計算してSlack/Teamsへ通知します…”)

// 生成されたJARファイルをスキャンし、ダミーの監査ログを出力
fileTree(“$buildDir/libs”).matching {
include(“.jar”)
}.forEach { file ->
println(” -> 検出された成果物: ${file.name} (サイズ: ${file.length()} bytes)”)
// 実務ではここでSHA-256ハッシュを計算し、API経由でセキュリティ基盤へ送信する
}

println(“[SUCCESS] すべてのパイプラインフックが正常に完了しました。”)
println(“==================================================”)
}
}

// 既存のプロセス（assemble）にカスタムタスクを組み込む場合
tasks.assemble {
// assemble（jarやdistributionをまとめる親タスク）の直後に securePackageTask を走らせる
finalizedBy(securePackageTask)
}

このコードのアーキテクチャ的優位性

1. 既存タスクへの非侵入型フック: `jar` や `assemble` といったGradle標準タスクの内部コードを汚染せず、外側から安全に処理を拡張している。
2. 構成フェーズの軽量化: すべての重いロジック（ファイル走査やタイムスタンプ取得）を `doFirst`/`doLast` のクロージャ内（＝実行フェーズ）に閉じ込めているため、タスクグラフ構築のオーバーヘッドがゼロに等しい。

—

4. 開発スピードを極限まで高める：プロの秘技・神設定

ここからは、単なる機能解説にとどまらず、あなたの毎日の開発体験を劇的に変える「隠しコマンド」と「共有化ルール」を伝授する。

A. 開発スピードを跳ね上げる IntelliJ IDEA / CLI の極意

Gradleのデフォルトのビルドは、プロジェクトが巨大化すると遅くなる。これを限界まで加速させる。

• デーモンの常時起動と並列実行の強制 (`gradle.properties`)

プロジェクトルートの `gradle.properties` に以下の設定を記述せよ。これだけで体感速度が2〜3倍になる。

Gradleデーモンをバックグラウンドで常時アライブさせ、JVMの起動コストをゼロにする
org.gradle.daemon=true

依存関係のダウンロードやモジュールビルドを並列実行（マルチコアをフル活用）
org.gradle.parallel=true

設定キャッシュ（Configuration Cache）を有効化し、構成フェーズの時間を極限まで削る（Gradle 7.4+）
org.gradle.configuration-cache=true

JVMヒープサイズをプロジェクトの規模に合わせて最適化（OOMを完全に防ぐ）
org.gradle.jvmargs=-Xmx4g -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

• IDE（IntelliJ IDEA）でのビルド処理の委譲設定

IntelliJのデフォルト設定は、独自のGradleラッパーではなくIDE独自のビルダーを使おうとしてビルド差異を生む。

• `Settings` -> `Build, Execution, Deployment` -> `Build Tools` -> `Gradle`
• “Build and run using:” および “Run tests using:” を、必ず “Gradle” に変更しろ。

これによって、CLIで実行する挙動とIDEでデバッグ実行する挙動が100%一致し、「手元では動くのにCIで落ちる」という悪夢から解放される。

B. チーム開発で絶対に守るべき規約：Gradle Wrapperの死守

チームメンバーの誰かが「ローカルに入っているGradleのバージョン（例: 8.5）」でビルドし、CIが「8.1」で動いているような現場は、プロの仕事とは言えない。

1. 必ずプロジェクトに `gradlew` (Gradle Wrapper) をバージョン管理（Git）に含めよ。
2. 開発者全員に、ローカルのグローバルGradleコマンドではなく、常に `./gradlew` を使う ことを規約化する。
3. CI/CDパイプラインでも、必ず `./gradlew build` を叩かせる。

これにより、マシン環境の差異によるビルド破綻を物理的に根絶できる。

—

5. テックリードからの総括

`doFirst` と `doLast` は、ただの「便利メソッド」ではない。
Gradleという強大なビルドオーケストレーターを、自社の開発フローやセキュリティガバナンスに完全に適応させるための「制御棒」である。

構成フェーズと実行フェーズの境界を意識し、適切なタイミングでタスクに処理をインジェクションできるようになれば、あなたも真のGradleマスタリーに到達したと言えるだろう。

明日のビルドから、この知見をフル活用し、チームの生産性を圧倒的な高みへと引き上げてくれ。