Skip to main content

Release

Overview​

モバイルのリリース戦略

tip

モバイルの定期アップデートに関して
アプリのエラーの排除やバグの修正、全体的なパフォーマンスの向上、機能の追加・削除、規制要件への適合において重要な役割を果たす。
しかしアプリを頻繁にアップデートしすぎると、ユーザーに迷惑をかけ、アップデートを定期的にインストールしなくなる可能性がある。
リリース頻度が低すぎると、競合他社の機能改善に遅れをとるリスク。

リリース戦略​

モバイルのリリース戦略は以下のような3段階のブランチ構成で運用します：

develop ブランチ
├──  開発中の機能
├──  自動テスト
└──  Ad-hoc配布 (S3 + CloudFront)
    ↓
release/v1.0.0 ブランチ
├──  バグ修正のみ
├──  リリース準備
└──  ストア審査前テスト
    ├── iOS: TestFlight
    └── Android: 内部テスト
    ↓
main ブランチ
├──  本番リリース
├──  iOS: App Store審査
└──  Android: Play Store審査
tip

場合によっては、アプリ内でユーザーに最新バージョンへのアップデート（重大なバグの修正や主要機能のアップデートなど）を促すことが必要。

Hotfix対応​

リリース後にバグが見つかった場合は、hotfix/vX.X.X ブランチを切って修正します。

  • 修正後は main にマージし、再度ストア審査を通す必要があります。
  • App StoreもPlay Storeも、基本的にはhotfixでも再審査が必要です。
  • iOSでは「Expedited Review」を申請することで審査を早めることが可能です。
  • Androidでは段階的配信や内部テストによって影響範囲を限定することができます。

安全対策（Kill Switch）​

重大なバグに備え、アプリ内の特定機能をサーバー側の設定で無効化できるようにしておく（Kill Switch）ことで、再リリースを待たずに影響を最小限にできます。

リリースノート​

リリースノートとは、開発者がモバイルアプリの新規リリースで行われた変更点をすべてリストアップしたドキュメント。
アプリのユーザー向けに書かれておりあらゆるレベルのユーザーが理解しやすいよう専門用語はほとんど使用されていない。
リリースノートは、次のリリースや企業からユーザーへの約束について、全員が共通の認識を持つことができるため、エンジニアリングチームにも非エンジニアリングチームにも役立つ。

さらにリリースノートを活用して、ユーザーに最新情報を提供できる。
ユーザーは、バグ、互換性、デバイスやアプリのクラッシュ、セキュリティ、プライバシー、速度、データ損失などを懸念し、アプリのアップデートをためらう。
メジャーアップデートを事前に把握し、マイナーアップデートについても最新情報を提供すれば、エンゲージメントとダウンロード数の向上が期待できる。

caution

大規模で複雑なアプリでは、リリースごとに多くの変更が伴うため、リリースノートが長くなりすぎるリスクが常に存在する。
リリースノートが長すぎて、ユーザーがそれを無視してしまうような事態は避けたいもの。
新しいリリースに変更点が多すぎて簡潔に伝えられない場合は、複数のアップデートを要約したり、いくつかのアップデートをまとめてリリースノートを短くしたりすることができる。

リリースノートは、アプリ内アナウンス、ブログ、ビデオ、ニュースレター、またはプレスリリースを通じて配布できます。

開発者は、リリース後にリリースノートを公開します。しかし、新しいリリース、特に新機能や新機能を備えたメジャーリリースは、ユーザーにとって驚きとなるべきではありません。ゲーム業界の例に戻ると、ゲーム開発者はアイデア創出の段階から実際のリリース、そしてそれ以降もユーザーを関与させ続けます。例えば、人気ビデオゲーム「原神」の最新バージョン3.0は2022年8月にリリースされましたが、開発会社がバージョン3.0について語り始めたのは2022年3月でした。これにより、「原神」はユーザーからのフィードバックを収集し、修正を加え、リリースへの期待を高めるために、5か月間という十分な時間を持つことができました。

今後のリリースについて、ユーザーに最新情報を継続的に提供しましょう。計画内容、変更によってアプリのエクスペリエンスがどのように向上するか、そして新リリースのリリース時期についてお知らせします。ユーザーからのフィードバックや提案も忘れずにお聞かせください。これらの情報は、リリースノートの配布に推奨されているのと同じ配信チャネルで配信できます。パワーユーザーはアップデートへの準備を整え、リリース初日からのダウンロード数増加に貢献します。

tip

ゲーム業界はアップデートに関してユーザーとのコミュニケーションを非常に重視している。
『クラッシュ・オブ・クラン』の典型的なリリースノートには、修正されたすべての問題が記載されており、最新バージョンへのアップデートが推奨されている。
記載されている問題のいずれかを経験したユーザーは、アップデートをダウンロードするでしょう。

本番リリースの方法​

プラットフォーム内部テスト/TestFlightなしで本番UP可能？実務上の推奨フロー
Android（Google）技術的には可能だが非推奨内部テスト → 本番
iOS（Apple）不可。TestFlight経由が必須TestFlight → App Review → 本番

Google Play（Android）の場合​

本番リリースには「内部テスト」または「クローズドテスト」を経由するのが推奨（実質的に必須） Google Play Consoleでは、以下の段階を経てリリースを進める。

  • 内部テスト → クローズドテスト → オープンテスト → 本番（プロダクション）リリース

必ずしも内部テストを通さなければならないわけではないが、いきなり本番トラックにアップロードするのは以下の理由で実務上ほぼ行われない。

  • 本番リリースは審査に時間がかかる（通常数時間〜数日）
  • 一度公開すると巻き戻しが難しい
  • 署名や互換性のチェックが厳しい
tip

特に実機での挙動確認や、本番環境でのサブスクリプション/課金周りの動作確認をしたい場合は、内部テストかクローズドテスト経由で進めるのが推奨。

App Store（iOS）の場合​

TestFlightを通さないと本番に上げられない（＝実質的に必須）

  • App Store Connectでアプリを審査提出（本番公開）するには、ビルドの署名・確認が必要
  • そのため、XcodeやCIでビルドしてアップロードしただけでは不十分
  • TestFlightで審査用のビルドをアップロードし、Appleの審査を受けるプロセスがほぼ必須

具体的な流れ

  1. XcodeまたはCIからアプリをアップロード（Transporter経由など）
  2. App Store ConnectでTestFlight用にビルドを提出
  3. Appleの自動審査（+手動審査の場合もあり）
  4. 本番申請（App Review用に提出）

提案するFlutterアプリのリリースフロー（GitHub Actions）​

Flutterを利用し、GitHub ActionsをCI/CDパイプラインとして利用することを前提に、効率的なフロー

1. develop ブランチ（開発版）​

目的
日々の開発の成果を素早く検証・共有するための Adhoc版 を提供。

GitHub Actionsの処理

  • 自動ビルド (Web/Flutter)
  • S3にAdhoc用ページをデプロイ
  • ビルドしたFlutter WebアプリまたはAPKをS3バケットにアップロードし、検証チームがアクセスできるように設定。

成果物例

  • Web版URL（Adhoc環境）
  • APK（Androidの直接インストール用

2. release ブランチ（テスト版）​

目的
ストア審査を経てテスターに展開するための版を作成（内部テスト・TestFlight）

GitHub Actionsの処理（Flutterビルド & ストアへの自動アップロード）

  • Android:
    • FlutterでAPKまたはApp Bundleをビルド
    • FastlaneまたはGoogle Play APIで Google Play Console内部テスト版 へアップロード
  • iOS
    • FlutterでIPAをビルド
    • FastlaneまたはApp Store Connect APIで TestFlight へアップロード
    • 必要に応じてTestFlightの自動配信設定（内部・外部テスター）

3. main ブランチ（本番版）​

releaseブランチでテスト・検証済みのアプリを 本番リリース する。

GitHub Actionsの処理（推奨）
リリース承認プロセス（マニュアル承認）を含むGitHub Actionsフローを設定する
承認なしの自動デプロイは、本番環境では原則非推奨（リスクが高いため）

理由

  • 本番リリースには審査や予期せぬトラブルが伴う可能性が高い
  • 手動で最終確認・承認をするプロセスを入れることが安全で推奨されるため

推奨されるGitHub Actionsのステップ:

  1. GitHub ActionsでFlutterアプリの本番ビルドを作成（appbundle / ipa）。
  2. 承認待ちのワークフローでデプロイを保留（マニュアル承認ステップ）
  3. 手動承認後に以下を実行
  • Android
    • Google PlayのProductionトラックにApp Bundleをアップロード
  • iOS
    • App Store ConnectでApp Reviewにビルドを提出（Fastlane経由）

Resource​

Last updated on