Pay for Businessのgradle.ktsへの移行の小噺

Transcript

1. Pay for Businessのgradle.kts移行の小噺 モバチキ 〜Mobile Tips 共有会〜 #1 2023/08/02 キクチコウダイ
2. 自己紹介 菊池 広大（キクチコウダイ） 2023年6月 株式会社マネーフォワードに入社 埼玉出身、香港育ち、 Iターンで東京から福岡に引越し Github: https://github.com/BigBackBoom
3. どんな人向き - 既存プロジェクトをこれから KTSに移行することを考えている - Gradleの記述をスリムにしていきたい - 移行時に起きた障害のポイントなどを知りたい。
4. Pay for Businessとは？
5. Pay for Businessとは？ ウォレット残高からカード支払ができる「 マネーフォワード ビジネスカード 」と呼ばれるビジネス向け プリペイドカードを発行して、カードやウォレット払いなど、多様な決済手段を通じてキャッシュレス 化を促進するサービス。 

6. Pay for Businessとは？ プロダクトの技術的な特徴： • リリースから２年の新しめのプロジェクト • 技術的特徴 ◦ Jetpack ComposeでUIを全て作成 ◦ ダークモードに対応済み ◦ Kotlin coroutine・Flowなどモダンな言語機能を利用 • 未対応箇所 ◦ gradleがGroovy　←　今日のトピック ◦ In-App Review / In-App Updateなどは未対応
7. KTS移行 パオン
8. KTS移行当初の印象 移行と言っても、ktsファイルに右から左に記述を変換 して移していくだけなので、楽勝でしょう
9. 移行方針 1. モジュール毎に build.gradleを変換していく 2. Gradle Taskのリファクタはしない 3. できるだけ最小限で、大きな変更は加えない
10. 受難１： GroovyのlambdaとKotlinからの 呼び出し コンニチハ
11. GroovyのlambdaとKotlinからの呼び出し buildscript { ext { enableJacoco = { Project project, String variant -> // Jacocoの設定周りを記述 } } } • トップレベルのgradleにJacoco設定用のClosureが定義されている。 • 各モジュールで、Closureを呼び出して、全てのモジュールで同じ Jacocoの設定を適用する。 build.gradle(project_name)
12. GroovyのlambdaとKotlinからの呼び出し build.gradle(:features:common) plugins { alias libs.plugins.android.library alias libs.plugins.kotlin.android alias libs.plugins.kotlin.parcelize } enableJacoco(project, 'Debug') plugins { alias(libs.plugins.android.library) alias(libs.plugins.kotlin.android) alias(libs.plugins.kotlin.kapt) } rootProject.project.ext["enableJacoco"]( project, 'debug' ) build.gradle.kts(:features:common) • build.gradleをktsに置き換えて Closureを呼び出そうと思いました。 • extからデータを取り出して呼び出してみたが、 syntaxエラーとなる
13. GroovyのlambdaとKotlinからの呼び出し • 結局、試行錯誤してもわからず、 Gradle Pluginを作る方針に変更 • nowinandroidに倣い、build-logicというプラグイン専用の独立プロジェクトを立てて、そちらを呼び出す 形に変更 • 下記のようにプロジェクトファイルを構成 pay_project ├ build-logic/ ├ convention/ ├ src/main/kotlin/com/moenyeforward/pay_project/build/logic ├ Jacoco.kt └ ProjectExtension.kt ├ AndroidJacocoConventionPlugin └ build.gradle.kts └ settings.gradle ├ app/ . .
14. GroovyのlambdaとKotlinからの呼び出し • モジュールそのものの書き方は省きま す。 • build-logic/convention/build.gradle.kts にpluginの登録をしておく。 • 対象モジュールの、pluginsにidを設定 しておけばビルド時に自動で動く Tips： build-logicではなくて、buildSrcでも可能だが、実は buildSrcは１行でも変更すると全モジュールに再ビルド がかかる ので効率が良くない *1。 // build-logic/convention/build.gradle.kts gradlePlugin { plugins { register("androidJacoco" ) { // なんでもいいけど、呼び出し用のユニークな名前 id = "bizpay.android.jacoco" // クラス名 implementationClass = "AndroidJacocoConventionPlugin" 　 } } } // Jacocoの設定対象モジュールの plugins { alias(libs.plugins.android.library) alias(libs.plugins.kotlin.android) alias(libs.plugins.kotlin.kapt) id("bizpay.android.jacoco") }
15. GroovyのlambdaとKotlinからの呼び出し • 対応は無事完了したが、結果的に大きめの変更 が必要となった。 • 当初の見積もりから作業時間が大きくずれるこ ととなった
16. 受難２： Gradleのビルドバージョンが下 がる謎現象 ｺｯﾄリーン
17. Gradleのビルドバージョンが下がる謎現象 • Pay for Businessのビルドツール ◦ Gradle Plugin: 8.0.2 ◦ Gradle Version: 8.2.1 • 最新に近いバージョンが利用されている • そんな中、AppモジュールのKTS移行で異変が・・・・
18. Gradleのビルドバージョンが下がる謎現象 他のモジュールで利用できた記述が全く利用できない
19. Gradleのビルドバージョンが下がる謎現象 特徴： • Android Studio側では記述にエラーなどは検知していない。 • Syncの段階で突然落ちる • build.gradleでは問題なく動作する • 動く記述や動かない記述、非推奨になっているものなどがある
20. Gradleのビルドバージョンが下がる謎現象
21. Gradleのビルドバージョンが下がる謎現象 • バージョンが古いものが使われていると仮定して調査開始。 • 結果、８系から追加された DSLが利用できないことから、７系の Gradleが利用 さていることがわかる。 • ログを見ると、Gradle Syncの際に7.0.4のプラグインがダウンロードされてるのも 発見 • 問題は何が原因で、Gradleバージョンが変わっているのか？
22. Gradleのビルドバージョンが下がる謎現象 Syncの段階で問題が起きているので、 plugin/dependencyを一つづつ外して、ビルドが通るか 確認する。
23. Gradleのビルドバージョンが下がる謎現象 • androidx.navigation.safeargs. kotlinを入れると、Gradle 7.0.4が 使われてしまうことが発覚 • 原因はモジュール間でのバージョ ン固定のための設定の記述漏れ でした // build.gradle.kts(:app) plugins { alias(libs.plugins.android.application) alias(libs.plugins.kotlin.android) alias(libs.plugins.kotlin.kapt) alias(libs.plugins.hilt) // ⇩androidx.navigation.safeargs.kotlin // alias(libs.plugins.androidx.navigation.safeargs.kotlin) alias(libs.plugins.google.services) alias(libs.plugins.firebase.crashlytics) alias(libs.plugins.firebase.perf) } // build.gradle.kts(:pay_project) plugins { alias(libs.plugins.androidx.navigation.safeargs.kotlin) apply false . . . }
24. Gradleのビルドバージョンが下がる謎現象 • KTSではclasspathなどのバージョン を示す記述が完全になくなり 、plugins とversionの二つのタグだけで、 plugin 利用する形になっている。 • トップレベルのモジュールで apply falseとversionをつけることで全モ ジュールでのバージョン固定をする • その記述を忘れていたことで、おかし な挙動をしていた。 // build.gradle.kts(:app) plugins { alias(libs.plugins.android.application) alias(libs.plugins.kotlin.android) alias(libs.plugins.kotlin.kapt) alias(libs.plugins.hilt) // ⇩androidx.navigation.safeargs.kotlin // alias(libs.plugins.androidx.navigation.safeargs.kotlin) alias(libs.plugins.google.services) alias(libs.plugins.firebase.crashlytics) alias(libs.plugins.firebase.perf) } // build.gradle.kts(:pay_project) plugins { alias(libs.plugins.androidx.navigation.safeargs.kotlin) apply false . . . }
25. Gradleのビルドバージョンが下がる謎現象 • ただ追加調査したが、apply falseの有無で発生する理 由がわからず • GroovyのBuild.gradleでは発生しない • 趣味のプロジェクトでも同様の症状が起きました。環境 の問題ではなし • バグの可能性もあり？
26. まとめ
27. まとめ • Kotlin → GroovyのClosure呼び出しの仕方がわからない • Closure呼び出しするよりも、Plugin化すると便利。 • Pluginを別プロジェクト(build-logic)として切ると、ビルド時間も短縮 • KTSではまだ謎の挙動が起きることがある。 ◦ Gradleのバージョンが特定モジュールだけ変わる • Pluginやdependencyに引っ張られている可能性があるのでログを要チェック。
28. まとめ ぴえん🥺を通り越した先に、パオン 🐘KTSの便利さを体 験できるようになります。
29. Reference
30. Reference *1 Stop using Gradle buildSrc. Use composite builds instead