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 時点の情報になります)

この記事が気に入ったらサポートをしてみませんか?