Slide 1

Slide 1 text

© LY Corporation LINEヤフー株式会社 山道 大地 単一Gitレポジトリから 独立しました 2025/06/07 JJUC CCC 2025 Spring

Slide 2

Slide 2 text

© LY Corporation 山道 大地 Local/UGC Company 2 2022 LINE Fukuoka 2024 LY Corporation © LY Corporation

Slide 3

Slide 3 text

© LY Corporation 3 ウォレットタブの紹介

Slide 4

Slide 4 text

© LY Corporation リポジトリ分割をどこから始めるべきか知り、作業の見積もりを正確にする 分割のメリット・デメリットを知り、移行が適切か判断する 大規模なGradleプロジェクト開発構成についての実践事例を知り、Gradle構成を見直す 移行作業の落とし穴や教訓を知り、移行計画を見直す リポジトリ分割の実際のメリットを知り、ステークホルダーを説得する材料を持ち帰る 4 本セッションの目的

Slide 5

Slide 5 text

© LY Corporation 5 Agenda 1. 背景 2. 分割計画 3. 分割・改善 4. まとめ 5. Q&A

Slide 6

Slide 6 text

© LY Corporation 6 Agenda 1. 背景 2. 分割計画 3. 分割・改善 4. まとめ 5. Q&A

Slide 7

Slide 7 text

© LY Corporation 背景 7

Slide 8

Slide 8 text

© LY Corporation 8 分割前の元レポジトリの規模 ファイル数 12,650files Javaの行数 6,458files, 604,009lines Kotlinの行数 23,148files, 149,351lines 総行数 12,142files, 1,441,705lines masterのコミット数 59,277commits 総容量 268MB 2023年の1週間の平均commit数 (masterのsquashされたcommit数) 約67commits/week

Slide 9

Slide 9 text

© LY Corporation 64万行 Gradle 83万行 Spring Framework 35万行 Elasticsearch 9 元リポジトリはJavaとKotlin合わせて75万行 大規模開発 注)2025年5月10日時点のheadでclocを用いて調査 注)JavaとKotlinを合わせた行数の概算

Slide 10

Slide 10 text

© LY Corporation 10 プロジェクト毎に細かく分離されている GradleのMulti-Project structureで構成 Repository Team1 Project1 Project2 Project3 Team2 Team3 Common Module1 Module2

Slide 11

Slide 11 text

© LY Corporation 分割に至った経緯 11

Slide 12

Slide 12 text

© LY Corporation Repository Team1 Project1 Project2 Project3 Team2 Team3 Common Module1 Module2 12 隣のチームが改編後に全く別の部署に異動 新組織図

Slide 13

Slide 13 text

© LY Corporation • 既存の権限設定が適切では無くなった • 他チームによるコード変更 • クラウド資源の共有 • 予算の負担部署が分かれ一緒に計上ができなくなった • Quotaの枯渇リスク • コミュニケーション機会の減少 • 問題点の共有 • PRのレビューコスト上昇 13 部署異動によりおきた問題点

Slide 14

Slide 14 text

© LY Corporation • 大規模なGradle設定 • 不要な依存の混入 • 新規メンバーの障壁 • 影響範囲 • ライブラリ更新 • CI/CD • リリースブランチが増加しやすい 14 以前からあった問題点

Slide 15

Slide 15 text

© LY Corporation レポジトリを分割して諸問題を解決 15

Slide 16

Slide 16 text

© LY Corporation 16 具体的には Repository1 Team1 Team2 Team3 Common module build.gradle Repository1 Team1 Team2 Common module build.gradle Repository2 Team3 Common module build.gradle

Slide 17

Slide 17 text

© LY Corporation 17 Agenda 1. 背景 2. 分割計画 3. 分割・改善 4. まとめ 5. Q&A

Slide 18

Slide 18 text

© LY Corporation 分割計画 18

Slide 19

Slide 19 text

© LY Corporation 19 分割手順概要 リファクタリング Gradle CI/CD クリーンアップ ソースコード CI/CD Secrets 新リポジトリに移行 開発 デプロイ テスト 新レポジトリ作成 ソースコード CI settings 依存関係の分離 共通モジュール

Slide 20

Slide 20 text

© LY Corporation 20 1. 依存関係の分離 Repository1 Team1 Team2 Team3 Common module build.gradle Repository1 Team1 Team2 Team3 Team3 Common module Team1,2 Common module build.gradle

Slide 21

Slide 21 text

© LY Corporation 21 2. 新リポジトリ作成 Repository1 Team1 Team2 Team3 Team3 Common module Team1,2 Common module build.gradle Repository1 Team1 Team2 Team1,2 Common module build.gradle Repository2 Team3 Team3 Common module build.gradle

Slide 22

Slide 22 text

© LY Corporation 22 おおよそ5MM 分割にかかった時間 2024 年 1月 2 3 4 5 6 7 8 9 10 11 12 1 2 2025 3月 依存関係解決 2MM(他タスクを優先したため) 移行 1MM 改善 2MM

Slide 23

Slide 23 text

© LY Corporation 23 Agenda 1. 背景 2. 分割計画 3. 分割・改善 4. まとめ 5. Q&A

Slide 24

Slide 24 text

© LY Corporation 分割・改善 24

Slide 25

Slide 25 text

© LY Corporation 権限問題 複雑なGradle構成 ライブラリ更新がしにくい CI/CD リポジトリのコピー 25 主な分割・改善作業

Slide 26

Slide 26 text

© LY Corporation 権限設定 26

Slide 27

Slide 27 text

© LY Corporation 27 GitHubの権限設定が適切でないと起こり得ること 他チームの実装で共通モジュールに変更が入る レビュー漏れが発生 サービスに影響

Slide 28

Slide 28 text

© LY Corporation 28 GitHubのOrganizationのリポジトリロール 主なアクション Read Triage Write Maintain Admin Pull ✓ ✓ ✓ ✓ ✓ Issue管理 ╳ ✓ ✓ ✓ ✓ Merge ╳ ╳ ✓ ✓ ✓ 保護されたブラ ンチへPush ╳ ╳ ╳ ✓ ✓ 権限管理 ╳ ╳ ╳ ╳ ✓

Slide 29

Slide 29 text

© LY Corporation 29 ディレクトリ毎にチームが分類されている Repository Team1 Project1 Project2 Project3 Team2 Team3 Common Module1 Module2

Slide 30

Slide 30 text

© LY Corporation • BypassしてMergeすることが可能 • CODEOWNERファイル自体の所有者 • CommonなどのReviewer CODEOWNERによるReviewを必須にする 30 考えられる対策とそのデメリット ディレクトリ毎に適用することはできない • BypassしてMergeすることが可能 • Workflowの管理が必要 • 実行時間 • Workflowファイル自体の所有者 Workflowを活用する

Slide 31

Slide 31 text

© LY Corporation Gradle構成 31

Slide 32

Slide 32 text

© LY Corporation buildSrc ├ buildSrc │ └ build.gradle ├ subproject │ ├ build.gradle │ └ subsubproject │ └ build.gradle ├ build.gradle ├ gradle.properties └ settings.gradle バージョンカタログ利用前 • 各所にバージョン情報が散在 • 人によって書き方が異なる buildSrc ├ buildSrc │ └ lib.versions.toml └ subproject └ subsubproject └ build.gradle バージョンカタログ利用後 • libs.version.tomlファイルに集約 • 型セーフなアクセサー • 人による書き方の揺れがなくなる 32 バージョンカタログを使う

Slide 33

Slide 33 text

© LY Corporation gradle/libs.versions.toml [versions] groovy = "3.0.5” checkstyle = "8.37” [libraries] groovy-core = { module = "org.codehaus.groovy:groovy", version.ref = "groovy" } groovy-json = { module = "org.codehaus.groovy:… groovy-nio = { module = "org.codehaus.groovy:… commons-lang3 = { group = "org.apache.commons", … [bundles] groovy = ["groovy-core", "groovy-json", "groovy-nio"] [plugins] versions = { id = "com.github.ben-manes.versions", version = "0.45.0" } 33 バージョンカタログの利点 観点 Version Catalog なし Version Catalog Version 情報 分散 libs.vers ion.toml ファイ ルのみ IDE補完 なし あり Buldle なし あり build.gradle dependencies { implementation libs.groovy.core implementation libs.groovy.json implementation libs.groovy.nio }

Slide 34

Slide 34 text

© LY Corporation Cross-Project構成 • 影響範囲が可視化されづらい • 例外処理がスパゲッティ化しやすい • build.gradleが巨大になりがち Convention Plugin • 影響範囲が可視化される • ロジックをまとまりで分割できる 34 Cross-Project構成よりConvention Pluginを使う 画像引用: https://docs.gradle.org/

Slide 35

Slide 35 text

© LY Corporation 35 buildSrc VS 複合ビルド 観点 buildSrc 複合ビルド ディレクトリ buildSrc固定 SettingsにincludeBuildを明示 リビルド 全てのサブプロジェクト 変更ビルドのみ 再利用性 リポジトリ内のみ 別リポジトリでもOK 学習コスト 低 中

Slide 36

Slide 36 text

© LY Corporation ライブラリ更新 36

Slide 37

Slide 37 text

© LY Corporation 37 共有ライブラリ更新の困難 Library v1 Common Project1 Project2 Project3

Slide 38

Slide 38 text

© LY Corporation 38 共有ライブラリ更新の困難 Library v1 Common Project1 Project2 Project3 新しいAPIが使いたい

Slide 39

Slide 39 text

© LY Corporation 39 共有ライブラリ更新の困難 Library v2 Common Project1 Project2 Project3 Libraryを更新して実装

Slide 40

Slide 40 text

© LY Corporation 40 共有ライブラリ更新の困難 Library v2 Common Project1 Project2 Project3 今忙しいので対応できません

Slide 41

Slide 41 text

© LY Corporation 41 共有ライブラリ更新の困難 Library v2 Common Project1 Project2 Project3 一旦保留

Slide 42

Slide 42 text

© LY Corporation 42 共有ライブラリ更新の困難 Library v1 Common Project1 Project2 Project3 一旦保留

Slide 43

Slide 43 text

© LY Corporation CI/CD(GitHub Actions) 43

Slide 44

Slide 44 text

© LY Corporation • 共有Moduleを変更すると巨大なCIが動く • 他チームも利用しているCI/CDを変更しにくい • Self-hosted runner資源 • 誤った設定で不要なCIが動いてしまう(ことに気付きにくい) • リリースブランチが増加しやすい 44 元リポジトリで気になっていたこと

Slide 45

Slide 45 text

© LY Corporation • Gradleのバージョン指定 • Gradle/actions/setup-gradleを使用してCacheを有効活用 • キャッシュの使用状況のレポート 45 setup-gradle action

Slide 46

Slide 46 text

© LY Corporation レポジトリのコピー 46

Slide 47

Slide 47 text

© LY Corporation • GitHub Importer • Transfer repository • Issue, PR等も移行可能 • git push –mirror • Branch, Tag等も可能 レポジトリ全体をコピー 47 リポジトリの様々なコピー方法 レポジトリの一部をコピー • git format-patch • git-filter-repo • Git subtree split • GitHub CLI

Slide 48

Slide 48 text

© LY Corporation 48 コピー方法比較 方法 Issues, PRs Branches, Tags History Transfer repository git push –mirror git filter-repo ╳ git filter-repo git format-patch ╳ ╳

Slide 49

Slide 49 text

© LY Corporation 49 Agenda 1. 背景 2. 分割計画 3. 分割・改善 4. まとめ 5. Q&A

Slide 50

Slide 50 text

© LY Corporation 分割前と分割後で変わったこと 50

Slide 51

Slide 51 text

© LY Corporation • 他チームに影響を与えないで変更が加えられる • 不要なモジュールを削除できる • 依存関係が複雑になりにくい • リリースで他チームに依存しなくなった 51 分割で改善されたこと

Slide 52

Slide 52 text

© LY Corporation • 一度に更新を行える • ダイヤモンド依存問題に対処しやすい • 依存関係を探しやすい Merit 52 モノレポの利点 • 更新には多くのコストが必要 • バージョンを統一しないと大変 • 共有モジュールに不要な部品が混入する Demerit

Slide 53

Slide 53 text

© LY Corporation 53 Diamond Dependency Problem A B C D A B C D.1 D.2

Slide 54

Slide 54 text

© LY Corporation ファイルやディレクトリの所有権が曖昧 覚えられないほど構成が複雑 ビジネスドメインが無関係 gRPCなどRPCのインターフェース定義を共有していない 他チームのコードを変更しにくい 54 当てはまればマルチレポへ移行してもいいかも 分割後に感じたトレードオフの境界

Slide 55

Slide 55 text

© LY Corporation • 組織改編をきっかけに権限の最適化・独立・単純化のためにリポジトリ分割を決定 • 移行作業は、依存関係分離・新レポジトリ作成・移行・クリーンアップと手順を踏むことで安全か つ分かりやすく進行した • 分割作業全体で約5MMかかった • レポジトリの所有権を得て自由になった • Gradleのリファクタリングを行い再利用性や可読性が高まった • setup-gradleを導入してCI時間を短縮した • 現在のところ問題なく運用中 55 まとめ

Slide 56

Slide 56 text

© LY Corporation Q&A 56

Slide 57

Slide 57 text

© LY Corporation