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

Flutter アプリのリリースフローを考える

swiftty
September 25, 2024

Flutter アプリのリリースフローを考える

【ハイブリット開催】Mobile勉強会 ウォンテッドリー × チームラボ × Sansan #16
https://teamlab.connpass.com/event/329937/

で発表した内容です

swiftty

September 25, 2024
Tweet

More Decks by swiftty

Other Decks in Programming

Transcript

  1. © 2024 Wantedly, Inc. 自己紹介 林達也 モバイルエンジニア @ ウォンテッドリー株式会社 github

    swiftty x _swiftty wantedly tatsuya_hayashi_ar 性格診断 - ハーモナイザー
  2. © 2024 Wantedly, Inc. 前提 • 初回リリースを終え次回以降のリリースは自動化させたい • iOS メインで

    Android はほぼ初めての対応 ◦ iOS でのリリースフロー周りは検討がついている • その上で Android 向けのリリースフローを構築したい • また、なるべくリリースタイミングを揃えたい ◦ 自動化する上でタイミングを揃えることができれば 逆にずらしたいケースも対応可能なはず
  3. © 2024 Wantedly, Inc. 署名管理の属人化 どちらのプラットフォームもストア向けの署名のための Key を取り扱う必要がある • iOS

    ◦ Cloud 管理署名用の App Store Connect API Key https://speakerdeck.com/swiftty/try-cloud-managed-certificates • Android ◦ Google Play Console に AppBundle をアップロードする際に署名する アップロードキー ◦ Google Play Developer API Key 用の JSON Key
  4. © 2024 Wantedly, Inc. 署名管理の属人化 どちらのプラットフォームもストア向けの署名のための Key を取り扱う必要がある • iOS

    ◦ Cloud 管理署名用の App Store Connect API Key https://speakerdeck.com/swiftty/try-cloud-managed-certificates • Android ◦ Google Play Console に AppBundle をアップロードする際に署名する アップロードキー ◦ Google Play Developer API Key 用の JSON Key どちらも本番向けの操作となるため 個人が管理したくない
  5. © 2024 Wantedly, Inc. iOS / Android 複数のリリース管理の必要 • Flutter

    アプリでは基本的に一回のリリースで 両プラットフォームに向けてリリース作業を行う • 単純に二倍の手順が必要となりヒューマンエラーが入り込み やすい&先の署名管理も合わせて CI/CD で管理したい
  6. © 2024 Wantedly, Inc. iOS / Android 複数のリリース管理の必要 • Flutter

    アプリでは基本的に一回のリリースで 両プラットフォームに向けてリリース作業を行う • 単純に二倍の手順が必要となりヒューマンエラーが入り込み やすい&先の署名管理も合わせて CI/CD で管理したい 以上からリリースフローを構築する上で CI/CD による自動化は考慮必須と判断
  7. © 2024 Wantedly, Inc. リリースフロー 概要 • ベースは iOS のリリースフローと

    合わせる ◦ リリース準備 ▪ バイナリのアップロード ▪ … ◦ 申請 ◦ 公開 • 各ワークフローは CircleCI 上に 構築 • 操作は fastlane を用いて実現 ◦ upload_to_app_store ◦ upload_to_play_store
  8. © 2024 Wantedly, Inc. リリース準備 • CI から prepare_release ワークフローをキック

    ◦ release/x.x.x を作成し master へ向けた PR をオープンする ◦ PR に記載の手順に沿ってリリースの準備を進める(QA など) ◦ release/x.x.x に更新があると iOS / Android のリリースビルド を行いバイナリがアップロードされる ▪ 修正を取り込むと新しいバイナリがアップロードされる • 📝 Android → internal トラック向けにアップロード prepare_release
  9. © 2024 Wantedly, Inc. 申請 • CI から submit ワークフローをキック

    ◦ アップロードされたバイナリを審査に提出する • 📝 Android → internal トラックを production トラックに変更 ◦ ※iOS と同様に審査フェーズがあるため 管理対象の公開 をオンとし 審査後自動でリリースされないように設定 submit
  10. © 2024 Wantedly, Inc. 申請 • CI から submit ワークフローをキック

    ◦ アップロードされたバイナリを審査に提出する • 📝 Android → internal トラックを production トラックに変更 ◦ ※iOS と同様に審査フェーズがあるため 管理対象の公開 をオンとし 審査後自動でリリースされないように設定 submit iOS 側で審査に時間がかかったりリジェクトされたときに Android の公開が始まってしまうと バージョンがずれるなど管理が煩雑になってしまうため
  11. © 2024 Wantedly, Inc. 公開 • prepare_release で作成された PR をマージ

    ◦ iOS は自動で段階的リリースを開始 ◦ GitHub Releases を作成し master → develop へのマージ PR を オープンする • 📝 Android → 手動で Google Play Console から公開を開始する ◦ ※Google Play Developer API には 管理対象の公開 の際に 公開状態を変更するための API がない(?) https://stackoverflow.com/questions/74123544/automate-play-store-release-with-managed-publishing-google-play-api https://issuetracker.google.com/issues/179708468?pli=1 release
  12. © 2024 Wantedly, Inc. リリースフロー 概要 • ベースは iOS のリリースフローと

    合わせる ◦ リリース準備 ▪ バイナリのアップロード ▪ … ◦ 申請 ◦ 公開 • 各ワークフローは CircleCI 上に 構築 • 操作は fastlane を用いて実現 ◦ upload_to_app_store ◦ upload_to_play_store