GitHub Actions で Flutter アプリの CI/CD をやってます #ゆるWeb札幌

ゆるWeb勉強会@札幌 #29 の発表資料。
https://mild-web-sap.connpass.com/event/349770/

Transcript

1. GitHub Actions で Flutter ア プリの CI/CD をやってます 2025/04/26 生活協同組合コープさっぽろ デジタル推進本部システム企画部 木原 卓也
2. 木原 卓也 Kihara, Takuya / @tacck 生活協同組合コープさっぽろ デジタル推進本部システム企画部 Software Engineer / Flutter, TypeScript, Vue.js, React ゆるWeb勉強会@札幌 主催 Amplify Japan User Group 運営メンバー AWS Community Builder Since Q2 2021 Frontend Web and Mobile 好きなフィギュアスケートの技 スプレッド・イーグル
3. 目次 • GitHub Actions とは ◦ GitHub Actions とは ◦ GitHub Actions 費用 • コープさっぽろの CI/CD 環境変遷 • Flutter アプリを CI/CD する ◦ Flutter アプリを CI/CD する ◦ Flutter アプリのビルド手順 ◦ 開発中の検証ビルドの改善話 • GitHub Actions キャッシュ • まとめ
4. GitHub Actions とは • GitHub 謹製のワークフロー実行環境。 ◦ ブランチ操作・Pull Request操作など、トリガーは豊富。 • 下記のランナー (実行OS) が用意されている。 ◦ Linux (Ubuntu) x64 / ARM64 ◦ macOS x64 / ARM64(M1) ◦ Windows Server x64
5. GitHub Actions 費用 • 基本的な費用 (各OSの最小スペックでの分単位の料金 米ドル) ◦ Linux x64 2-core: $0.008 ◦ Windows x64 2-core: $0.016 (Linuxの2倍) ◦ macOS x64 4-core: $0.08 (Linuxの10倍) ◦ macOS M1 3-core: $0.08 (Linuxの10倍) • プランごとに無料枠あり (Linuxの費用基準、Windows/macOSはLinux料金で換算) ◦ GitHub Free: 2,000分 = $16 ◦ GitHub Pro: 3,000分 = $24 ◦ 組織の GitHub Free: 2,000分 = $16 ◦ GitHub Team: 3,000分 = $24 ◦ GitHub Enterprise Cloud: 50,000分 = $400
6. コープさっぽろの CI/CD 環境変遷 • 無の時代 → CircleCI 導入 • CircleCI → GitHub Actions へ移行
7. 無の時代 → CircleCI 導入 • アプリの内製化を進める中で、CD/CIを導入することに。 • 当時のメンバーによって、 CircleCI に決定。 ◦ 4年ほど前は、iOS アプリをいい感じにビルドできる選択肢は少なかった。 • テスト、ビルド、デプロイが自動になることで、開発者依存から脱却。 ◦ 特にアプリは本番用証明書を手元で管理しなくて良くなった。
8. GitHub Actions へ移行 • 時は流れ、 GitHub Actions が高機能化 → iOS アプリも十分にビルド可能に。 • メンバーの入れ替えもそれなりに起こり、GitHubで集中管理の方向へ。 • GitHub Actions だと ◦ すでに GitHub の Organization に入っているので、追加のユーザー管理不要。 ◦ そのため、新規リポジトリでの導入障壁が低くなった。 ◦ 費用の最適化もしたい。(GitHub Actions は完全従量課金) • 書き換えは、基本を抑えればそこまで難しくはなかった。 ◦ どちらもジョブの大半はシェル芸なので。
9. Flutter アプリを CI/CD する • Ubuntu と macOS のランナーがあるので、 Flutter アプリもビルド可能。 ◦ ランナーのイメージ情報 https://github.com/actions/runner-images/tree/main ◦ 色々とランタイムがインストール済み。 ◦ それぞれのイメージには Android 環境も含まれている。 ▪ が、 macOS は時間単価高いので Android ビルドするのはもったいない。 • Flutter は入っていないので、 Action でインストールする必要あり。 ◦ flutter-action https://github.com/marketplace/actions/flutter-action
10. Flutter アプリのビルド手順 • 三段階のビルドトリガーを用意 ◦ 開発中の実機検証ビルド ◦ リリース前の検証ビルド ◦ 申請用の本番ビルド
11. 開発中の検証ビルド • 私の参加前〜参加直後 (CircleCI時代〜GitHub Actions初期) ◦ 開発用ブランチから test/〜〜 のようなブランチを派生 ◦ アプリのビルド番号を他の開発者と事前調整 ◦ そのブランチへの push でビルドワークフロー実行 ◦ 両OS とも Firebase App Distribution へアップロード・実機配信 • 課題 ◦ ブランチへの push でビルドされるので、 細かい修正の push で不要なビルド多発!! ◦ ビルド番号の事前調整が手間。 →改善話は後ほど 1.2.3 (456) のような バージョン + ビルド番号 が、被らないようにしないといけ ない。
12. リリース前の検証ビルド • dev → stg へマージでビルドワークフロー実行 ◦ Android ▪ Firebase App Distribution へアップロード・実機配信 ◦ iOS: 検証用アプリ ▪ App Store アップロード・Testflightで実機配信 • 課題 ◦ OSごとに配信環境が異なる。 ◦ プロダクトに関わるメンバーが増えたため、リリース前検証の機会が増加し、手間 が増えた。 ◦ →iOS は Firebase App Distribution も併用するように調整
13. 申請用の本番ビルド • stg → main へマージでビルドワークフロー実行 ◦ 各ストアへアップロード。 ◦ ここは特に変更無し。
14. 開発中の検証ビルドの改善話 macOS での無駄なビルドが発生しないように、ビルドトリガーを調整。 • ブランチのプッシュ → PR へ特定のラベル設定 ◦ ビルドは意図した時 (ラベル設定時) のみ ◦ ブランチを派生させる手間も無し • ビルド番号を事前調整 → ワークフロー実行中に自動採番 ◦ ビルド完了後にコメントし、Firebase App Distribution で見つけやすくする。 ビルドも楽になり、費用も削減。🤗
15. ラベルでのビルド実行 / ビルド番号の自動採番 実行日時ベースで自動採番
16. ラベルでのビルド実行 / ビルド番号の自動採番 特定のラベル名のみ実行。 ここで弾くと、ランナーが起動しないので 費用がかからない。
17. GitHub Actions キャッシュその1 Actions のキャッシュの効果範囲を意識する必要がある。 基本は、Actions を実行したブランチ単位。 下記の階層で、上位のキャッシュは下位で参照できるが、逆はできない。 Flutter のように追加したランタイム、NPMなど大きくなりがちなライブラリ、 ビルドの中間オブジェクトなど、うまく上位でキャッシュを作っておくと効率よくビルドできる。 上位ブランチの キャッシュは参照可能 default branch feature1 feature2 feature1-1 feature2-1 下位ブランチの キャッシュは参照不可 派生関係のないブランチのキャッシュは参照 不可
18. GitHub Actions キャッシュその2 その他キャッシュの制限 • リポジトリごとのキャッシュ容量上限 ◦ 10 GB • キャッシュの有効期限 ◦ 最終アクセスから 7 日間 容量を超えたら、有効期限の古いものから自動で無効化・削除されていく。 「その1」をきちんとやっておかないと、全然キャッシュが効かないことになる!!
19. まとめ • GitHub Actions は手軽に始められて、便利。 ◦ シェル芸おじさんが輝ける場所。 • キャッシュポリシーがやや独特なので、そこはうまく設計しないといけない。 • macOS のランナーはお高いので、最小限のビルドで使うような工夫を。 • ARM64 のランナーは少し安くなるけど、無料枠に入らないらしい。 ◦ 十分に使っているところであれば、検討しよう。 • パブリックリポジトリは無料なので、まずは気軽にやってみよう！