14.7K Views
June 02, 23
スライド概要
JJUG CCC 2023 Spring資料
サンプルコード(GitHub レポジトリ)
https://github.com/simplexinc/jjug-ccc-2023-spring-sample
シンプレクスは1997年の創業以来、メガバンクや大手総合証券を筆頭に、日本を代表する金融機関のテクノロジーパートナーとしてビジネスを展開してきました。現在では、金融領域で培った豊富なノウハウを活用し、金融機関以外の領域でもソリューションを展開しています。2019年3月にはAI企業のDeep Percept株式会社、2021年4月には総合コンサルティングファームのXspear Consulting株式会社がグループに加わり、創業時より付加価値の創造に取り組んできたシンプレクスとワンチームとなって、公的機関や金融機関、各業界をリードする企業のデジタルトランスフォーメーション(DX)の推進を支援しています。
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.
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.
コンポジットビルドを利⽤すると直⾯する課題 • 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.
サンプルコードでの説明 • 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.
サンプルコードでの説明 • 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.