段階的リリースとアップデート

新しいバージョンをすべてのユーザーに一度に配信するのは危険です。潜在的なクラッシュがあれば、すぐに全ユーザーに影響します。Google Play には、より安全な方法としてテストトラックと段階的な公開があります。

このレッスンでは、リリーストラック、まず少ない割合のユーザーに公開する方法、アップデートがユーザーに届く仕組み、問題が起きたときの対応について学びます。

Play では、公開範囲が小さいものから大きいものまで、リリースをトラックに分けて管理します。

• 内部テスト — 最大 100 人のテスターが数分以内に利用でき、チーム内での確認に使います。
• クローズドテスト — メールリストまたはグループで招待したテスターが利用します。
• オープンテスト — 誰でも公開ベータ版に参加できます。
• 本番 — ストアのすべてのユーザーが利用します。

望ましい流れは、ビルドを内部 → クローズド → オープン → 本番の順に昇格させることです。

どのトラックでも新しいリリースを作成をクリックし、.aab をアップロードするか、App Bundle Explorer から選択して、リリースノートを追加します。

リリースノートでは言語タグを使用するため、ロケールごとに別のテキストを設定できます。短く、ユーザーを意識した内容にしてください。

本番リリースでは、段階的な公開を行えます。まず10%など、少数のユーザーに配信してから、対象を広げます。

Play はアップデートを受け取るユーザーをランダムに選びます。クラッシュ率と ANR 率を確認し、割合を 10% → 25% → 50% → 100% と増やします。

指標が悪化した場合は割合を増やさず、大半のユーザーに影響が及ぶ前に停止できます。

段階的な公開で問題が見つかった場合は、Console から停止できます。停止すると、新しいユーザーにはアップデートが配信されなくなります。すでにアップデートしたユーザーには、そのまま残ります。

新しいバージョンで修正版を配信した後、公開を再開するか、新しい公開を開始します。停止すれば、完全な取り消しを行わずに時間を確保できます。なお、Play にはすでにインストールされたユーザー向けの完全な取り消し機能は実質的にありません。

だからこそ、最初は少ない割合から始めるのです。

デフォルトでは、Play ストア アプリがバックグラウンドで（多くの場合 Wi-Fi 接続時に）アプリを自動更新します。ユーザーが手動で「更新」をタップすることもあります。

versionCodeのルールを覚えておいてください。各リリースには、前回より大きい整数を設定する必要があり、そうでなければ Play に拒否されます。versionNameは、ユーザーに表示されるラベルにすぎません。

ユーザーにアプリ内でアップデートを促したい場合があります。In-App Updates API には 2 つのモードがあります。

• Flexible — ユーザーがアプリを使い続けている間に、バックグラウンドでダウンロードします。
• Immediate — 重要なアップデート向けの、全画面で操作をブロックするフローです。

アップデートの有無を確認し、利用可能な場合は選択したフローを開始します。

Flexibleアップデートは、ユーザーに気付かれない形でダウンロードされます。完了したら、インストールするために completeUpdate() を呼び出す必要があります。通常は、snackbar でユーザーに促してから呼び出します。

DOWNLOADED 状態を監視し、その後で再起動を案内します。

配信して終わりではありません。Play Console のAndroid vitals ダッシュボードでは、Play がアプリの評価にも使用する健全性指標を確認できます。

• クラッシュ率とANR 率（Application Not Responding）。
• 過剰なウェイクアップ、遅い描画、バッテリーに関する問題。

段階的な公開中は、これらを注意深く確認してください。急激な悪化は、公開範囲を広げる前に停止すべきサインです。

リリース後は、次の 2 つの習慣が重要です。

• Console でレビューに返信する。評価の向上につながり、実際のバグも見つけやすくなります。
• vitals またはクラッシュレポーターからクラッシュをトリアージし、修正して versionCode を増やし、新しい段階的な公開を行う。

リリースは、少しずつ配信し、計測し、修正して、再び配信するという循環です。

レッスン全体をまとめると、堅牢なワークフローは次のとおりです。

• 内部テストにアップロードし、チームでスモークテストを行う。
• クローズドテストまたはオープンテストに昇格させ、より幅広いフィードバックを得る。
• 本番環境で10%の段階的な公開を開始する。
• Android vitalsを確認し、問題がなければ割合を増やす。
• 指標が急上昇したら停止して修正し、新しいビルドで再開する。

小さな段階に分け、適切に監視すれば、リリースは怖い作業ではなく日常的な作業になります。

本番リリースをユーザーの 10% に配信したところ、クラッシュ率が急上昇しました。修正版を準備する間、問題のあるバージョンがこれ以上のユーザーに配信されないようにしたいとします。どうしますか。

これで、自信を持ってリリースできるようになりました。

• トラック（内部、クローズド、オープン、本番）を使用して、ビルドの公開範囲を段階的に広げる。
• 段階的な公開を行い、最初は少ない割合から始め、指標が健全な状態を保っている場合に範囲を広げる。
• vitals が急上昇したら公開を停止し、修正したうえで、より大きい versionCode の新しいビルドを配信する。
• 必要に応じて、In-App Updates API（Flexible または Immediate）でユーザーに通知する。
• Android vitalsとレビューを監視し、改善を繰り返す。

これで、署名済みリリースビルドから、安全に監視しながら段階的に公開するまでの「Google Play への公開」が完了します。