Gradleと仲良くなる第一歩　～小規模PJから大規模PJへ～

Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ ⼩林 政友 シンプレクス株式会社 © 2023 Simplex Inc.

⾃⼰紹介 • ⽒名: ⼩林 政友 (こばやし まさとも) • 所属: シンプレクス株式会社 • 好きな⾔語: Kotlin • 好きなIDE: IntelliJ IDEA • これまでの経験: • 銀⾏向けの⼤規模分散計算基盤の開発〜性能検証 • 証券会社向けCFD取引システムの導⼊PJ開発リード Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

シンプレクスについて 1997年創業のITコンサルティング企業 IT戦略から開発、運⽤まで⼀気通貫で担い、 トータルソリューションを提供 しています 創業当時より ⾦融フロント・ミドル領域 に強みを持ち、 市場業務、リテール⾦融業務に多数の実績 2013年より 保険領域 にビジネスを拡⼤し、現在に⾄るまで実績多数 各種領域で ⾃社パッケージ・フレームワーク・ライブラリの開発・活⽤ により 業界知識集約・⽣産性向上を図っています 近年は⾮⾦融領域へもビジネスを展開しています Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

Build Tool https://insights.stackoverflow.com/trends?tags=gradle%2Cmaven%2Cbazel%2Csbt%2Cant Gradle およびびそのロゴは、Gradle Inc. の⽶国及びその他の国における登録商標または商標です。 Maven およびそのロゴは、 Apache Software Foundation の⽶国及びその他の国における登録商標または商標です。 Apache Ant およびそのロゴは、 Apache Software Foundation の⽶国及びその他の国における登録商標または商標です。 sbt およびそのロゴは、 Lightbend, Inc. の⽶国及びその他の国における登録商標または商標です。 Bazel およびそのロゴは、 Alphabet Inc. の⽶国及びその他の国における登録商標または商標です。 Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

• https://insights.stackoverflow.com/trends?tags=gradle,maven,bazel,sbt,ant

Gradleにつまずいたことありませんか…でも︕ • カスタマイズ性の裏返し バージョン による差異 癖が強い プラグイン 関連ファイ ルが多い 記法が 分かりづらい • 充実したドキュメント • 困った時に頼れるところがある スクリプト の読込順 が不明瞭 コードが ⾃動⽣成 される • ⼤⼩さまざまなPJに適⽤できる • 痒い所に⼿が届く設定 • Java以外の⾔語にも対応 • KotlinDSLで型安全に • IDEのサポートも受けられる Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

⼩規模開発から⼤規模開発へ 機能/サービスの増加 新しい機能を サービスとして切り出す ボトルネックが⽣じて プロセス構成を変更する 依存ライブラリの増加 Databaseの種類が増える API仕様が増える 帳票の出⼒を⾏う セキュリティを強化する ビルド対象/種別の増加 新しいサービスを ︖ Kotlinで書く 共通ロジックをライブラリとし て切り出す Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring ︖ © 2023 Simplex Inc.

⼤規模PJでの Gradle Proejctの構成 Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

複数のプロジェクトを扱う際の戦略 • コンポジットビルド (≠マルチレポ) • マルチプロジェクトビルド https://primer.style/design/foundations/icons Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

• https://primer.style/design/foundations/icons

コンポジットビルドを利⽤すると直⾯する課題 • PJは本質的に独⽴している • ビルドがPJ間で直列に動く (仕組みとしては並列に動くが、依存関係がある場合) • PJの規模が⼤きくなるとビルドの設定が極端に複雑化する • CI/CDサイクルでのビルドで順序性の担保が煩雑化する • 場合によっては… • 共通ロジックの多重実装が多発する • Pull Requestがリポジトリを跨ぐ デメリットは︖ ① CI/CDの制御が複雑化する傾向にある ☞ 変更箇所を正しく判定して必要なビルドをかける ☞ 依存しているサブプロジェクトのビルドも合わせて実⾏ ② Gradleの仕組みをより深く知らないと嵌って抜け出せない ☞ ⼀部は今⽇の発表で解消 ☞ ドキュメント⾃体は充実している ☞ マルチプロジェクトビルドを使おう︕ Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

マルチプロジェクトビルドを使おう︕(おまけ) • ChatGPTもそう⾔っている。 Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

サンプルコードでの説明 • ディレクトリ構成 • ⾒た⽬(親ディレクトリがあるか) • .gradleが各ルートに • settings.gradleも複数に • 依存関係の書き⽅ • includeBuild • dependenciesブロック • IntelliJでの設定 • CompositeBuildSetting Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

複雑化する ライブラリの管理 Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

依存関係の管理は… • 複数のPJで共通(外部)ライブラリを使うとバージョンの衝突が起きうる Build-time Version 1.X Runtime Version 1.Y Version 1.X Version 1.Y Versionを合わせておきたい Class Loader が先に⾒つけた⽅を利⽤ Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

version catalogを使おう︕ • PJ間でライブラリの定義を共有できる機能 • Gradle7.0から利⽤可 ※ 7.2で⼤幅な変更あり、7.4以降でstable • 公式Docは https://docs.gradle.org/current/userguide/platforms.html • メリット • Versionの共有が簡単になる ※ buildSrcなどに定義するプラクティスなどもあったが公式にサポート • 型安全に書けるため、(定義が終わっていれば)スペルミスなどに強い • 複数の依存関係をグループ化できるため、使⽤箇所が簡素になる • Spring-bootやKotlinを使いたい場合などに強⼒ • リポジトリ経由で別PJ間でも共有可能 Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

• https://docs.gradle.org/current/userguide/platforms.html

サンプルコードでの説明 • settings.gradle.ktsでの書きっぷり • tomlファイルの読み込みもできるが今回は割愛 • サブプロジェクトでの書き⽅の紹介 (build.gradle.kts) • 単純な依存関係 • version情報の取得 • bundleを使うことによる可読性の向上 Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

サブプロジェクトの 共通設定の整理 Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

共通設定をどう扱う︖ • PJが⼤きくなってくると種別が増えてくる • (web⽤の)staticなコンテンツをサブプロジェクトで管理したい • Libraryとサーバーを分けたい (fat-jarを作成したい) • 内部通信はgRPC通信を利⽤したい • Kotlinで書きたい pluginを使って既に実現している︕︕ カスタマイズをどう扱うか • allprojectsやsubprojectsブロックは使いづらい • 階層化⾃体は良いがプロジェクトの種別ごとに階層が⽣まれ、業務的な階層とずれてしまう。 • 深くなると設定値をどこに書いたかが分かりづらくなる • repositoryの設定などはglobalに設定したいからよい • やりたいことは共通設定/処理を⼀か所に集めておきたい Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

Pluginとして利⽤するためにbuildSrcを活⽤しよう︕ • buildSrc⾃体はGradle1.4頃から使える • 本体スクリプトを宣⾔的に記述するために、 命令的な宣⾔を別定義するもの • 各build.gradle.ktsにて共通利⽤できるスクリプト群を定義 • (今回の⽤途での)公式Doc: https://docs.gradle.org/current/userguide/custom_plugins.html • setup.ktを配置 • ベース/Java/Kotlin/gRPC などの定義を記載 (詳細は後ほど) • resources配下も編集 • Plugin化するために必要 ※ 「build-logic」などのgradleプロジェクト別途作成するプラクティスもあるが、 共通化/plugin化の⽂脈では本質的な差はない Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

• https://docs.gradle.org/current/userguide/custom_plugins.html

サンプルコードでの説明 • buildSrcの配置を確認 • Setup.ktを⼀通り⾒る。 • resourcesの書き⽅も • サブプロジェクトでの書き⽅ • 微調整(property)の扱い⽅ • ⾃分でConfigクラスを書くのもあり • 本題から少しずれるけど、buildSrcのbuildディレクトリはcleanで消えない… • 本体のtaskで追加定義するといいかも Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

⼩規模開発から⼤規模開発へ 機能/サービスの増加 Gradleプロジェクトを 成⻑させる場合には マルチプロジェクトビルドを 積極的に使う 依存ライブラリの増加 version catalogの 仕組みを利⽤する ビルド対象/種別の増加 共通のセットアップロジックは plugin化して buildSrcに書く 依存関係を 整理する 共通部分を モジュール化する Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.

Thank you for your attention! Gradleと仲良くなる第⼀歩 ~⼩規模PJから⼤規模PJへ~ @JJUG CCC 2023 Spring © 2023 Simplex Inc.