Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GitHub ActionsとDeployGateで始めるAndroidアプリのCICD

GitHub ActionsとDeployGateで始めるAndroidアプリのCICD

Yuhei FUJITA

March 20, 2023
Tweet

More Decks by Yuhei FUJITA

Other Decks in Programming

Transcript

  1. 目次 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
  2. クルクル - QRコードリーダー • QRコード読み取り ◦ 高速・高精度 • QRコード作成 ◦

    地図・連絡先 • クルクル Wi-Fi ◦ Wi-Fi接続 • クルクル チャンネル ◦ メッセージ配信 4 ※QRコードの商標はデンソーウェーブの登録商標です。
  3. 開発の現状 • リリース頻度 ◦ 最大で月に一回のリリース • 開発規模 ◦ モバイルアプリエンジニア:3人 ◦

    Webアプリエンジニア:2人 ◦ デザイナー(フロントエンド):5人 • テスト ◦ 手動テスト(エンジニア・デザイナー) • リリース ◦ 手動リリース 5
  4. 開発の現状 • リリース頻度 ◦ 最大で月に一回のリリース • 開発規模 ◦ モバイルアプリエンジニア:3人 ◦

    Webアプリエンジニア:2人 ◦ デザイナー(フロントエンド):5人 • テスト ◦ 手動テスト(エンジニア・デザイナー) • リリース ◦ 手動リリース 6 CI/CDが皆無
  5. 手動テストによる問題 8 • 増えるテスト項目 ◦ 毎回手動でテストしているとテストそのものに時間がかかる ◦ 再テストも考えると憂鬱 • コードレビュー

    ◦ 動作が保証されていないコードレビューは大変 ◦ コードレビューは実装そのものに集中したい • 想定外の不具合 ◦ 副作用のあるコードを変更した結果、予期しない不具合が生まれる ◦ 毎回フルテストするのは時間もかかる
  6. いつ自動テストを実行するか 9 いつ どこで なぜ git commit 開発者のローカルマシン バグのあるコードを git

    commitしないため Pull Request 作成時 GitHub ActionsなどCIツール コードレビューに専念するため Pull Request Merge時 GitHub ActionsなどCIツール リリース対象のBranchの動作保証
  7. いつ自動テストを実行するか 10 いつ どこで なぜ git commit 開発者のローカルマシン バグのあるコードを git

    commitしないため Pull Request 作成時 GitHub ActionsなどCIツール コードレビューに専念するため Pull Request Merge時 GitHub ActionsなどCIツール リリース対象のBranchの動作保証
  8. 社内向けにアプリをリリースする手段 15 apkファイルを直接配布 Google Playの内部テストで配布 メリット • 自由に出来る • 審査不要

    • 通常のリリースと近い • インストールが簡単 デメリット • バージョン管理が大変 • インストール手順が複雑 • アプリ開発者が必須 • 審査がある • 頻繁なリリースには 向いてない
  9. 社内向けにアプリをリリースする手段 16 apkファイルを直接配布 Google Playの内部テストで配布 メリット • 自由に出来る • 審査不要

    • 通常のリリースと近い • インストールが簡単 デメリット • バージョン管理が大変 • インストール手順が複雑 • アプリ開発者が必須 • 審査がある • 頻繁なリリースには 向いてない どちらも一長一短
  10. DeployGateで社内向けリリースを配信 18 • 審査不要 ◦ 迅速なリリースが可能 ◦ 毎日PRが飛び交うような場合でも常に最新を配信できる • 専用アプリ

    ◦ apk直配布よりインストール手順が簡単 ◦ 非エンジニアでも利用できる • 複数の配布ページ ◦ 同一アプリの配布ページを複数作成出来る ◦ ロールなどによって配布するバージョンなどを分けられる • Slack連携 ◦ Deploy通知などをSlackと連携できる
  11. DeployGateで社内向けリリースを配信 19 • 審査不要 ◦ 迅速なリリースが可能 ◦ 毎日PRが飛び交うような場合でも常に最新を配信できる • 専用アプリ

    ◦ apk直配布よりインストール手順が簡単 ◦ 非エンジニアでも利用できる • 複数の配布ページ ◦ 同一アプリの配布ページを複数作成出来る ◦ ロールなどによって配布するバージョンなどを分けられる • Slack連携 ◦ Deploy通知などをSlackと連携できる
  12. ReleaseNoteにほしい情報 29 • リリースノート ◦ リリースの概要 • 変更内容 ◦ どんなPull

    RequestがMergeされたのか • apkファイル ◦ このバージョンの各Variantのapkファイル
  13. ReleaseNoteにほしい情報 30 • リリースノート←これは手で書く必要がある ◦ リリースの概要 • 変更内容←Pull Requestから引っ張ってきたい ◦

    どんなPull RequestがMergeされたのか • apkファイル←DeployGateにDeployしたapkファイルがある ◦ このバージョンの各Variantのapkファイル ◦ ReleaseNoteに紐付いていたほうがわかりやすい
  14. 問題点 37 • 点在する共通処理 ◦ GitHub Actionsのセットアップは基本同じ ◦ UnitTestとBuildに同じ部分が存在する ◦

    メンテナンス性的にも共通処理はまとめたい • GitHub Actionsの実行時間 ◦ 3つのVariantがある ▪ develop, debug, release ◦ 1つあたり5〜6分かかる ▪ 順番にBuildしていると15~20分もかかる
  15. Buildを3回もやっていたら遅い • Variantが3つ ◦ develop ◦ debug ◦ release •

    各Buildにかかる時間は5~6分 ◦ 3つしていると15~20分くらいかかる 45
  16. 今後の課題 48 • まだまだテストコードが少ない ◦ テストコードを書き始めたのはここ最近 ◦ まだUnitTest程度しか存在しない • App

    Linkのテストができない ◦ App Linkの検証にはPlay Consoleで配信する必要がある ◦ DeployGateだけでは解決できない • テストコードが増えたときの実行時間 ◦ 今回、GitHub Actionsそのものの高速化はできていない ◦ 今後テストコードが増えたときの実行時間を考えないといけない
  17. 参考情報 • 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