PHONE APPLI で使用している build.gradle の紹介 (サーバーサイド)
こんにちは、株式会社 PHONE APPLI サーバーサイドエンジニアの藤本です。
今回は、サーバーサイドで長年培われてきた build.gradle のノウハウを紹介します。 (おそらく Gradle の推奨に追従できているはず・・・)
※ 記事執筆時の Gradle 最新バージョンは 8.10 です
kts で記述
現在、JVM で動く PHONE APPLI プロダクトは基本的に Kotlin が採用されており、それにあわせられるため、 build.gradle も kts で記述しています。
dependencies の管理
プロダクトのソースコードは Gradle マルチプロジェクトになっていることが多く、基本的に dependencies を version catalog (libs.versions.toml ファイル) で一元管理しています。
なるべく BOM (Bill of Materials) で定義
管理対象 dependencies を減らすため、ライブラリ側が BOM を提供していれば、それを使用しています。
BOM の定義は gradle 標準の platform("xxx") を使用しています。
※ io.spring.dependency-management プラグイン はこの問題にぶつかったことがあるため、使用しなくなりました。
バージョンの固定あるいは BOM 提供バージョンの上書き
何らかの事情で特定バージョンに固定する必要がある場合、 constraints ブロックで記述しています。
また、 io.spring.dependency-management プラグインを使ってないため、 BOM が提供するバージョンを上書きする場合も constraints ブロックで記述しています。
Gradle プラグインの dependencies
Gradle プラグインも version catalog に定義していますが、 [plugins] ブロックではなく [libraries] ブロックを使用しています。
[libraries] ブロックで定義したプラグインを buildSrc/build.gradle.kts ファイルで読み込み、プラグインを適用したいスクリプトに id("xxx") を記述しています。
※ [plugins] ブロックの場合、プラグイン適用側で @Suppress("DSL_SCOPE_VIOLATION") が必要だったため、使用しなくなりました。(最新の Gradle だとこの問題は解決済です)
例 : app プロジェクトに org.springframework.boot プラグインを適用する場合
ビルドロジックの共通化
ビルドロジックの共通部分は、 buildSrc にカスタムプラグイン (xxx.gradle.kts 形式) として作成しています。
※ カスタムプラグインは Composite Build に作成した方がいい時もあったのですが、 Gradle 8.0 から buildSrc も Composite Build と同じメリットが得られるようになったようです。
カスタムプラグインは、以下のような形とすることが多いです。
ほとんどのプロジェクトの共通設定 (Maven リポジトリ, Java, Kotlin, フレームワーク, lint)
test タスクの共通設定
integrationTest タスクの共通設定
リモートビルドキャッシュの利用
Gradle リモートビルドキャッシュ (Docker イメージ) をクラウドにデプロイし、それをローカルや GitHub Actions から利用しています。
例 : ローカルと GitHub Actions を考慮したビルドキャッシュの設定
Gradle の設定からは外れますが、リモートビルドキャッシュを利用しているため、 GitHub ワークフローでは caches/build-cache-1 ディレクトリをキャッシュから除外しています。
Docker Compose の Gradle タスク化
ローカル開発時やテスト実行時のインフラは、 Docker Compose で構築してソースコードリポジトリに含めていることが多いです。
その場合、 com.avast.gradle.docker-compose プラグインで Docker Compose の操作を Gradle タスク化しています。
Gradle タスク化のメリットは以下になります。
IntelliJ の GUI から操作できる
他の Gradle タスクとの連携がしやすい
例 : test タスクとインフラの起動を連動させる場合、 test タスクの dependsOn に「インフラの起動 (composeUp)」タスクを設定する
最後に
以上のことが、 build.gradle 記述時の参考になれば幸いです。
(1 つ注意点として、以上は Gradle 8 時点の情報になります)