Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GitHub ActionsとDeployGateで始めるAndroidアプリのCICD
Search
Yuhei FUJITA
March 20, 2023
Programming
2
940
GitHub ActionsとDeployGateで始めるAndroidアプリのCICD
Yuhei FUJITA
March 20, 2023
Tweet
Share
More Decks by Yuhei FUJITA
See All by Yuhei FUJITA
闇鍋VS Codeをプロファイル機能できれいにする / yami-nabe-vscode
yuhei_fujita
6
1.4k
GitHubとVitePressによる 開発ドキュメント運用 / escape-document-death
yuhei_fujita
3
430
進化したWeb技術でPWAをネイティブアプリに近づける / frontend-conf-2023
yuhei_fujita
6
4.6k
ChatGPTの機能を フル活用してChatGPTを 理想の彼女Botにする / nyanju-1st
yuhei_fujita
4
4.4k
手動テストの運用を GASで自動化した話 / gas-manage-test-operation
yuhei_fujita
1
560
開発ドキュメントの管理・閲覧に VitePress を使ってみて感じた良かった点と注意点 / document-with-vitepress
yuhei_fujita
0
1.3k
PWAで共有機能を実装する / pwa-web-share-api
yuhei_fujita
1
730
Other Decks in Programming
See All in Programming
来たるべき 8.0 に備えて React 19 新機能と React Router 固有機能の取捨選択とすり合わせを考える
oukayuka
2
800
AIネイティブなプロダクトをGolangで挑む取り組み
nmatsumoto4
0
120
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
41
26k
つよそうにふるまい、つよい成果を出すのなら、つよいのかもしれない
irof
1
290
Bytecode Manipulation 으로 생산성 높이기
bigstark
2
360
データの民主化を支える、透明性のあるデータ利活用への挑戦 2025-06-25 Database Engineering Meetup#7
y_ken
0
220
Cline指示通りに動かない? AI小説エージェントで学ぶ指示書の書き方と自動アップデートの仕組み
kamomeashizawa
1
540
Rails産でないDBを Railsに引っ越すHACK - Omotesando.rb #110
lnit
1
160
Practical Tips and Tricks for Working with Compose Multiplatform Previews (mDevCamp 2025)
stewemetal
0
130
Beyond Portability: Live Migration for Evolving WebAssembly Workloads
chikuwait
0
380
Kotlin エンジニアへ送る:Swift 案件に参加させられる日に備えて~似てるけど色々違う Swift の仕様 / from Kotlin to Swift
lovee
1
240
KotlinConf 2025 現地で感じたServer-Side Kotlin
n_takehata
1
220
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Typedesign – Prime Four
hannesfritz
42
2.7k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Site-Speed That Sticks
csswizardry
10
640
Optimizing for Happiness
mojombo
379
70k
How to Ace a Technical Interview
jacobian
276
23k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
137
34k
Documentation Writing (for coders)
carmenintech
71
4.9k
Music & Morning Musume
bryan
46
6.6k
Being A Developer After 40
akosma
90
590k
Transcript
GitHub Actionsと DeployGateで始めるAndroid アプリのCI/CD CI/CD Conference 2023 by CloudNative Days
2023-03-20 Yuhei FUJITA
目次 1. 自己紹介 2. それまでの開発の現状(No CI/CD) 3. GitHub ActionsによるUnitTest(CI) 4.
DeployGateによる配信(CD) 5. GitHub ActionsによるBuildとDeployGateへのDeploy(CI/CD) 6. GitHub ActionsによるReleaseNoteの生成(CD) 7. GitHub Actionsの改善(CI) 2
自己紹介 【名前】 藤田 悠平(フジタ ユウヘイ) 【所属】 アララ株式会社 ACシステム本部 ACアプリケーション開発部 【運営】
PWA Night(2021~) VS Code Meetup(2022~) Vue Fes Japan(2022~) 3 @Yuhei_FUJITA https://fujita.dev
クルクル - QRコードリーダー • QRコード読み取り ◦ 高速・高精度 • QRコード作成 ◦
地図・連絡先 • クルクル Wi-Fi ◦ Wi-Fi接続 • クルクル チャンネル ◦ メッセージ配信 4 ※QRコードの商標はデンソーウェーブの登録商標です。
開発の現状 • リリース頻度 ◦ 最大で月に一回のリリース • 開発規模 ◦ モバイルアプリエンジニア:3人 ◦
Webアプリエンジニア:2人 ◦ デザイナー(フロントエンド):5人 • テスト ◦ 手動テスト(エンジニア・デザイナー) • リリース ◦ 手動リリース 5
開発の現状 • リリース頻度 ◦ 最大で月に一回のリリース • 開発規模 ◦ モバイルアプリエンジニア:3人 ◦
Webアプリエンジニア:2人 ◦ デザイナー(フロントエンド):5人 • テスト ◦ 手動テスト(エンジニア・デザイナー) • リリース ◦ 手動リリース 6 CI/CDが皆無
第1の課題 手動テスト 7
手動テストによる問題 8 • 増えるテスト項目 ◦ 毎回手動でテストしているとテストそのものに時間がかかる ◦ 再テストも考えると憂鬱 • コードレビュー
◦ 動作が保証されていないコードレビューは大変 ◦ コードレビューは実装そのものに集中したい • 想定外の不具合 ◦ 副作用のあるコードを変更した結果、予期しない不具合が生まれる ◦ 毎回フルテストするのは時間もかかる
いつ自動テストを実行するか 9 いつ どこで なぜ git commit 開発者のローカルマシン バグのあるコードを git
commitしないため Pull Request 作成時 GitHub ActionsなどCIツール コードレビューに専念するため Pull Request Merge時 GitHub ActionsなどCIツール リリース対象のBranchの動作保証
いつ自動テストを実行するか 10 いつ どこで なぜ git commit 開発者のローカルマシン バグのあるコードを git
commitしないため Pull Request 作成時 GitHub ActionsなどCIツール コードレビューに専念するため Pull Request Merge時 GitHub ActionsなどCIツール リリース対象のBranchの動作保証
GitHub ActionsによるUnitTestの実行(1) 11 実行するのは Pull Request・develop/masterへのpush時
GitHub ActionsによるUnitTestの実行(2) 12 JavaとGradleの 実行環境をセットアップ シークレットな情報を `secrets` から取得 UnitTestを実行
自動テストはなんとかなった 13
第2の課題 社内向けリリース 14
社内向けにアプリをリリースする手段 15 apkファイルを直接配布 Google Playの内部テストで配布 メリット • 自由に出来る • 審査不要
• 通常のリリースと近い • インストールが簡単 デメリット • バージョン管理が大変 • インストール手順が複雑 • アプリ開発者が必須 • 審査がある • 頻繁なリリースには 向いてない
社内向けにアプリをリリースする手段 16 apkファイルを直接配布 Google Playの内部テストで配布 メリット • 自由に出来る • 審査不要
• 通常のリリースと近い • インストールが簡単 デメリット • バージョン管理が大変 • インストール手順が複雑 • アプリ開発者が必須 • 審査がある • 頻繁なリリースには 向いてない どちらも一長一短
DeployGate 17
DeployGateで社内向けリリースを配信 18 • 審査不要 ◦ 迅速なリリースが可能 ◦ 毎日PRが飛び交うような場合でも常に最新を配信できる • 専用アプリ
◦ apk直配布よりインストール手順が簡単 ◦ 非エンジニアでも利用できる • 複数の配布ページ ◦ 同一アプリの配布ページを複数作成出来る ◦ ロールなどによって配布するバージョンなどを分けられる • Slack連携 ◦ Deploy通知などをSlackと連携できる
DeployGateで社内向けリリースを配信 19 • 審査不要 ◦ 迅速なリリースが可能 ◦ 毎日PRが飛び交うような場合でも常に最新を配信できる • 専用アプリ
◦ apk直配布よりインストール手順が簡単 ◦ 非エンジニアでも利用できる • 複数の配布ページ ◦ 同一アプリの配布ページを複数作成出来る ◦ ロールなどによって配布するバージョンなどを分けられる • Slack連携 ◦ Deploy通知などをSlackと連携できる
Gradle DeployGate PluginでcliからDeploy 20 • DeployGateにアプリを配信するためのGradle Plugin • Gradleタスクとして実行が出来る
/build.gradle(Project Rootの`build.gradle`) 21
/app/build.gradle(app-moduleの`build.gradle`) 22
Deployの設定を記述 23 DeployGateの配布ページに表示される この中にVariantごとに記述 DeployGateの配布ページを指定 uploadDeployGateDevelopとして Gradleタスクに追加される DeployGateの配布ページに表示される
タスクが追加されたか確認 24
実行するとこんな感じ 25
GitHub Actionsに組み込む 26 まずはアプリをBuildする (./gradlew uploadDeployGateDevelopでも可能) DeployGateにDeployする 環境のセットアップは省略してます
GitHub ActionsでDeployGateに Deployできた 27
ReleaseNoteの作成 28
ReleaseNoteにほしい情報 29 • リリースノート ◦ リリースの概要 • 変更内容 ◦ どんなPull
RequestがMergeされたのか • apkファイル ◦ このバージョンの各Variantのapkファイル
ReleaseNoteにほしい情報 30 • リリースノート←これは手で書く必要がある ◦ リリースの概要 • 変更内容←Pull Requestから引っ張ってきたい ◦
どんなPull RequestがMergeされたのか • apkファイル←DeployGateにDeployしたapkファイルがある ◦ このバージョンの各Variantのapkファイル ◦ ReleaseNoteに紐付いていたほうがわかりやすい
GitHub ActionsによるReleaseNoteの作成(1) 31 まずはBuildする mapping.txtも同様 Buildしたファイルを artifactに一時保存
GitHub ActionsによるReleaseNoteの作成(2) 32 secrets.GITHUB_TOKENで ghコマンドからDraftとして作成 artifactに保存していたファイルを ReleaseNoteにアップロード
ghコマンド 33 tagをターゲットに指定 自動でReleaseNoteのテキストを生成 Draftとして作成 tag名をタイトルとして指定
作成されたReleaseNote 34 差分のPull Request artifactから追加したファイル
CI/CDできた! 35
ほんとうに? 36
問題点 37 • 点在する共通処理 ◦ GitHub Actionsのセットアップは基本同じ ◦ UnitTestとBuildに同じ部分が存在する ◦
メンテナンス性的にも共通処理はまとめたい • GitHub Actionsの実行時間 ◦ 3つのVariantがある ▪ develop, debug, release ◦ 1つあたり5〜6分かかる ▪ 順番にBuildしていると15~20分もかかる
処理の共通化 38
全く同じ部分 39 セットアップはどこも同じ シークレット情報を取得
ほぼ同じ部分 40 Variantごとでほぼ同じ 特定のVariantだけ実行
処理を共通化して呼び出す(1) 41 GitHub Actionsの共通処理 (/.github/actions/*/action.yaml) GitHub Actionsの本体 (/.github/workflows/*.yaml)
処理を共通化して呼び出す(2) 42 呼び出し時に`with` で指定できる これを指定することで呼び出せるようになる `inputs.properties` で `inputs` の値を呼び出せる
処理を共通化して呼び出す(3) 43 `uses` で呼び出せる `with` で `inputs` に値を渡す
GitHub ActionsのJobを分ける 44
Buildを3回もやっていたら遅い • Variantが3つ ◦ develop ◦ debug ◦ release •
各Buildにかかる時間は5~6分 ◦ 3つしていると15~20分くらいかかる 45
jobを分けて同時実行する 46 develop VariantのBuild Job debug VariantのBuild Job release VariantのBuild
Job 各VariantのBuild Jobを待ってから ReleaseNoteを作成
Jobを並行実行して時間を短縮する 47 6分程度まで短縮に成功
今後の課題 48 • まだまだテストコードが少ない ◦ テストコードを書き始めたのはここ最近 ◦ まだUnitTest程度しか存在しない • App
Linkのテストができない ◦ App Linkの検証にはPlay Consoleで配信する必要がある ◦ DeployGateだけでは解決できない • テストコードが増えたときの実行時間 ◦ 今回、GitHub Actionsそのものの高速化はできていない ◦ 今後テストコードが増えたときの実行時間を考えないといけない
まとめ • 社内向けリリース(ベータ版)はDeployGateが便利 • Gradle Pluginを使えばCI/CDに簡単に組み込める • GitHub Actionsの共通処理はまとめるべし •
GitHub ActionsのJobsをうまく活用して処理時間を短縮 49
参考情報 • gradle-deploygate-plugin https://github.com/DeployGate/gradle-deploygate-plugin/blob/master/README_JP.md • About custom actions - GitHub
Docs https://docs.github.com/en/actions/creating-actions/about-custom-actions • About GitHub CLI - GitHub Docs https://docs.github.com/en/github-cli/github-cli/about-github-cli 50
余談 51
リリース文言もGASで自動生成 52
CI/CDもドキュメントに残す 53
CI/CDもドキュメントに残す 54