GitHub ActionsとDeployGateで始めるAndroidアプリのCI/CDCI/CD Conference 2023 by CloudNative Days2023-03-20Yuhei FUJITA
View Slide
目次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_FUJITAhttps://fujita.dev
クルクル - QRコードリーダー● QRコード読み取り○ 高速・高精度● QRコード作成○ 地図・連絡先● クルクル Wi-Fi○ Wi-Fi接続● クルクル チャンネル○ メッセージ配信4※QRコードの商標はデンソーウェーブの登録商標です。
開発の現状● リリース頻度○ 最大で月に一回のリリース● 開発規模○ モバイルアプリエンジニア：3人○ Webアプリエンジニア：2人○ デザイナー（フロントエンド）：5人● テスト○ 手動テスト（エンジニア・デザイナー）● リリース○ 手動リリース5
開発の現状● リリース頻度○ 最大で月に一回のリリース● 開発規模○ モバイルアプリエンジニア：3人○ Webアプリエンジニア：2人○ デザイナー（フロントエンド）：5人● テスト○ 手動テスト（エンジニア・デザイナー）● リリース○ 手動リリース6CI/CDが皆無
第1の課題手動テスト7
手動テストによる問題8● 増えるテスト項目○ 毎回手動でテストしているとテストそのものに時間がかかる○ 再テストも考えると憂鬱● コードレビュー○ 動作が保証されていないコードレビューは大変○ コードレビューは実装そのものに集中したい● 想定外の不具合○ 副作用のあるコードを変更した結果、予期しない不具合が生まれる○ 毎回フルテストするのは時間もかかる
いつ自動テストを実行するか9いつ どこで なぜgit commit 開発者のローカルマシンバグのあるコードをgit commitしないためPull Request作成時GitHub ActionsなどCIツール コードレビューに専念するためPull RequestMerge時GitHub ActionsなどCIツール リリース対象のBranchの動作保証
いつ自動テストを実行するか10いつ どこで なぜgit commit 開発者のローカルマシンバグのあるコードをgit commitしないためPull Request作成時GitHub ActionsなどCIツール コードレビューに専念するためPull RequestMerge時GitHub ActionsなどCIツール リリース対象のBranchの動作保証
GitHub ActionsによるUnitTestの実行(1)11実行するのはPull Request・develop/masterへのpush時
GitHub ActionsによるUnitTestの実行(2)12JavaとGradleの実行環境をセットアップシークレットな情報を`secrets` から取得UnitTestを実行
自動テストはなんとかなった13
第2の課題社内向けリリース14
社内向けにアプリをリリースする手段15apkファイルを直接配布 Google Playの内部テストで配布メリット● 自由に出来る● 審査不要● 通常のリリースと近い● インストールが簡単デメリット● バージョン管理が大変● インストール手順が複雑● アプリ開発者が必須● 審査がある● 頻繁なリリースには向いてない
社内向けにアプリをリリースする手段16apkファイルを直接配布 Google Playの内部テストで配布メリット● 自由に出来る● 審査不要● 通常のリリースと近い● インストールが簡単デメリット● バージョン管理が大変● インストール手順が複雑● アプリ開発者が必須● 審査がある● 頻繁なリリースには向いてないどちらも一長一短
DeployGate17
DeployGateで社内向けリリースを配信18● 審査不要○ 迅速なリリースが可能○ 毎日PRが飛び交うような場合でも常に最新を配信できる● 専用アプリ○ apk直配布よりインストール手順が簡単○ 非エンジニアでも利用できる● 複数の配布ページ○ 同一アプリの配布ページを複数作成出来る○ ロールなどによって配布するバージョンなどを分けられる● Slack連携○ Deploy通知などをSlackと連携できる
DeployGateで社内向けリリースを配信19● 審査不要○ 迅速なリリースが可能○ 毎日PRが飛び交うような場合でも常に最新を配信できる● 専用アプリ○ apk直配布よりインストール手順が簡単○ 非エンジニアでも利用できる● 複数の配布ページ○ 同一アプリの配布ページを複数作成出来る○ ロールなどによって配布するバージョンなどを分けられる● Slack連携○ Deploy通知などをSlackと連携できる
Gradle DeployGate PluginでcliからDeploy20● DeployGateにアプリを配信するためのGradle Plugin● Gradleタスクとして実行が出来る
/build.gradle（Project Rootの`build.gradle`）21
/app/build.gradle（app-moduleの`build.gradle`）22
Deployの設定を記述23DeployGateの配布ページに表示されるこの中に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)32secrets.GITHUB_TOKENでghコマンドからDraftとして作成artifactに保存していたファイルをReleaseNoteにアップロード
ghコマンド33tagをターゲットに指定自動でReleaseNoteのテキストを生成Draftとして作成tag名をタイトルとして指定
作成されたReleaseNote34差分のPull Requestartifactから追加したファイル
CI/CDできた！35
ほんとうに？36
問題点37● 点在する共通処理○ GitHub Actionsのセットアップは基本同じ○ UnitTestとBuildに同じ部分が存在する○ メンテナンス性的にも共通処理はまとめたい● GitHub Actionsの実行時間○ 3つのVariantがある■ develop, debug, release○ 1つあたり5〜6分かかる■ 順番にBuildしていると15~20分もかかる
処理の共通化38
全く同じ部分39セットアップはどこも同じシークレット情報を取得
ほぼ同じ部分40Variantごとでほぼ同じ特定のVariantだけ実行
処理を共通化して呼び出す(1)41GitHub 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を分けて同時実行する46develop VariantのBuild Jobdebug VariantのBuild Jobrelease VariantのBuild Job各VariantのBuild Jobを待ってからReleaseNoteを作成
Jobを並行実行して時間を短縮する476分程度まで短縮に成功
今後の課題48● まだまだテストコードが少ない○ テストコードを書き始めたのはここ最近○ まだUnitTest程度しか存在しない● App Linkのテストができない○ App Linkの検証にはPlay Consoleで配信する必要がある○ DeployGateだけでは解決できない● テストコードが増えたときの実行時間○ 今回、GitHub Actionsそのものの高速化はできていない○ 今後テストコードが増えたときの実行時間を考えないといけない
まとめ● 社内向けリリース（ベータ版）はDeployGateが便利● Gradle Pluginを使えばCI/CDに簡単に組み込める● GitHub Actionsの共通処理はまとめるべし● GitHub ActionsのJobsをうまく活用して処理時間を短縮49
参考情報● gradle-deploygate-pluginhttps://github.com/DeployGate/gradle-deploygate-plugin/blob/master/README_JP.md● About custom actions - GitHub Docshttps://docs.github.com/en/actions/creating-actions/about-custom-actions● About GitHub CLI - GitHub Docshttps://docs.github.com/en/github-cli/github-cli/about-github-cli50
余談51
リリース文言もGASで自動生成52
CI/CDもドキュメントに残す53
CI/CDもドキュメントに残す54
yuhei_fujita
horie1024
ymotongpoo
satoshi7190
shoheihosaka
tomokusaba
ledsun
yuzuy
pyama86
skume
vrallev
honma12345
yumakann
soudai
jnunemaker
destraynor
mongodb
ddemaree
chriscoyier
geeforr
maltzj
philhawksworth
jmmastey
roundedbygravity