OTAアップデートの本番運用プレイブック

段階的ロールアウト、リアルタイム監視、ロールバック戦略を使用して、本番環境でOTAアップデートを安全に実行し、自信を持ってリリースする方法を学びます。

ExpoのOTAアップデートサービス（EAS Update）は、わずか数分でユーザーにアップデートを配信できます。これは素晴らしいことですが、特に実際の環境でアップデートがどのように動作するかを観察したい場合は、少しゆっくりと進めることが役立つ場合があります。最も強いシグナルは、実際のユーザー、実際のデバイス、実際のトラフィックから得られます。

EAS Updateは迅速に伝播するよう設計されていますが、本番環境でのアップデートの導入方法や、実際にシグナルが現れる場所についてはコントロールを提供します。アップデートをテストする時間と表面積が多いほど、一般的により安全になります。しかし、本番環境では無制限の時間が与えられることは稀であり、ゆっくり進むことにも実際のコストがかかります。

EAS Updateはそのトレードオフを排除するものではありません。露出、タイミング、復旧をコントロールできるようにして、各アップデートでスペクトラムのどこに位置するかを選択できるようにします。

この投稿では、段階的ロールアウトと監視から中止とロールバックまで、EAS Updateを本番環境で実行する実践的な方法を、これらのメカニズムが実際の本番環境でどのように動作するかに焦点を当てて説明します。

Expoドキュメントでは、チームがEAS Updateで使用するデプロイメントパターンの例をいくつか説明しています。本番環境に直接公開する簡単な2コマンドフローから、リリース前により構造化されたテストをサポートするステージングチャネルとバージョン管理されたブランチを持つフローまでです。選択する特定のパターンは、アップデートの構築と検証方法を形作りますが、この投稿の運用原則（アップデートを段階的にロールアウトし、実際のシグナルを観察し、見たものに対応する）は、ワークフローに関係なく、アップデートが本番環境に到達した時点で適用されます。

意図的に小さくリリースする

本番環境のコンテキストでは、小さくリリースすることは多くの場合、露出を制限することを意味します。アップデートをユーザーベース全体にすぐに利用可能にする代わりに、まず少数のユーザーにロールアウトすることから始めることができます。これにより露出の範囲が制限され、さらに拡張する前に、アップデートが実際の環境でどのように動作するかを観察する機会が得られます。

ロールアウトは、アプリがアップデートをチェックする際にアップデートを受信できるユーザーの割合を制限します。他のすべてのユーザーは以前のアップデートを使用し続けます。

この投稿では、単一の公開されたアップデートで動作するアップデート単位のロールアウトに基づく例を使用します。例えば、初期ロールアウト割合でアップデートを公開できます：

eas update --rollout-percentage=10

これにより、コストと影響の両方が制限され、本番環境で実際のユーザーとアップデートがどのように動作するかを確認する時間が得られます。

EAS Updateはブランチベースのロールアウトもサポートしており、ユーザーを異なるブランチ（アップデートのストリーム）に段階的に切り替えます。これらのロールアウトモデルが実際にどのように異なるかに興味がある場合は、デプロイメントガイドに利用可能なロールアウトの種類の簡単な説明が含まれています。

その動作を評価する準備ができたら、次のステップは監視すべきシグナルとその解釈方法を理解することです。

アップデートサイズと帯域幅に関する注意

ユーザーがダウンロードするすべてのアップデートは帯域幅を消費します。例えば、週に1回アップデートを公開し、ユーザーが定期的にアプリを開く場合、1か月の間に複数のアップデートをダウンロードする可能性があります。

EAS Updateには十分な帯域幅が含まれているため、ほとんどのアプリでは通常の使用でこれに遭遇することはありません。アップデートサイズを削減することは主に信頼性を向上させ、頻繁にアップデートをリリースするためのより多くの余裕を提供します。

SDK 55リリースでは、Hermesバイトコード差分（現在ベータ版）にオプトインできます。これにより、アップデートは完全なJavaScriptバンドルではなくバイナリパッチとして配布されます。完全に新しいバイトコードファイルをダウンロードする代わりに、クライアントは既にインストールされているものに差分を適用し、ダウンロードサイズと帯域幅使用量の両方を削減します。

バイトコード差分により、利用可能な帯域幅のヘッドルームが大幅に増加し、ユーザーは以前よりも少ないデータを使用しながら、より多くのアップデートをダウンロードできるようになります。

本番環境でのロールアウトの観察

アップデートが少数のユーザーに対してライブになると、EASダッシュボードは、そのアップデートが本番環境でどのように動作しているかのほぼリアルタイムビューを提供します。

アップデートの採用とボリューム

最初に確認すべきことの1つは、実際にアップデートを取得しているユーザーの数です。例えば10%でのロールアウトは、10%のユーザーがすぐにアップデートを適用することを意味しません。

デフォルトでは、アプリはコールドスタート時にアップデートをチェックし、利用可能な場合はダウンロードします。アップデートは次回アプリが再起動されたときに適用されるため、ユーザーは一度にすべて採用するわけではありません。

チームがfallbackToCacheTimeoutを数秒調整して、アプリが起動中にアップデートのダウンロードを少し待機し、すぐに適用できるようにすることがあります。これにより採用が速くなりますが、アップデートのダウンロード中にスプラッシュスクリーンが表示されたままになる可能性があるため、起動動作にも影響します。

より一般的には、チームはupdates JS APIを通じてアップデートライフサイクルを観察し、反応します。useUpdatesなどのフックは、アップデートシステムの状態（例：アプリが現在アップデートをチェックしているか、アップデートが利用可能か、既にダウンロードされているかなど）を公開し、アプリがレンダリングされた後にアップデートの採用を調整することを可能にします。

設定に関係なく、ロールアウト中に通常探しているのは、時間の経過とともに段階的に採用が増加することであり、必ずしも即座の急増ではありません。採用が予想外に低い場合、それ自体がシグナルになる可能性があります：ユーザーがアップデートをトリガーするほど頻繁にアプリを起動していない、またはアップデートが期待するビルドに対して適格でない可能性があります（例：それらのビルドがサポートするものとは異なるランタイムバージョンをターゲットにしているため）。

クラッシュと致命的エラー

クラッシュデータは、初期ロールアウト中の最も明確なシグナルであることが多いです。起動クラッシュと致命的なランタイムエラーは、影響を受けるユーザーがアップデートが実行されるとすぐに遭遇するため、迅速に表面化する傾向があります。

通常、これに最初に気づくのは、Expoダッシュボードのデプロイメントとアップデートビューで、各アップデートの起動データと並んでクラッシュ数を確認できます。

アップデートがクラッシュしている理由を理解するために、これは通常、Sentryの統合などの外部クラッシュ監視と組み合わせて使用され、デプロイメントデータと並んでスタックトレースとセッションコンテキストが表示されます。

Sentryはほとんどのランタイムクラッシュと例外をキャッチしますが、非常に早期の起動クラッシュは、App Store ConnectやPlay Consoleレポートなどのプラットフォームクラッシュレポートを通じてのみ表示される場合があります。

EAS Updateには組み込みエラー回復も含まれています。新しく適用されたアップデートが起動の非常に早い段階でクラッシュした場合（アプリがコンテンツを正常にレンダリングする前）、アプリはそのアップデートを失敗としてマークし、以前に動作していたアップデートにフォールバックできます。これは、アプリが起動時にクラッシュし、修正をダウンロードするのに十分な時間実行されない使用不可能な状態になることを防ぐために設計された防御メカニズムです。

トレンドを探す

初期ロールアウトデータはノイズが多い場合があります。小さなサンプルサイズは、特に少数のユーザーのみがアップデートを受信した場合、スパイクや下落を誇張する可能性があります。単一のデータポイントに反応するのではなく、次のようなトレンドを探してください：

• より多くのユーザーがアップデートを受信するにつれて、クラッシュやエラー率は変化するか？
• クラッシュはアップデートが公開された時期の周辺に集中しているか？

これらのシグナルを使用して、露出を増やすことで見ている動作が変化するかどうかを決定します。より多くのユーザーがアップデートを取得するにつれてクラッシュとエラー率が許容範囲内に留まる場合、ロールアウトを拡張することは通常合理的です。採用が増加するにつれて悪化する場合は、露出を増やす前に一時停止してください。

ロールアウトの安全な拡張

アップデートが制限された露出で実行されたら、次の決定は、より多くのユーザーにそれを受信させるかどうかです。ロールアウトを拡張してもアップデート自体は変更されません。新しいものを公開しているわけではありません。より大きなデバイスセットが、次回アップデートをチェックする際に同じアップデートを受信する資格を得られるようにしているのです。

例えば、ロールアウト割合を増やすには：

eas update:edit

インタラクティブガイドが、アップデートの選択と新しい割合の設定を案内します。

監視しているシグナルが露出が増加するにつれて許容範囲内に留まる場合、アップデートが完全なオーディエンスに利用可能になるまでロールアウトを拡張し続けることができます。

アップデートのロールバック

ロールアウト中に問題が発生した場合、進行状況に応じて、アップデートを停止または元に戻す2つの方法があります。ロールアウトがまだ進行中の場合は、それを元に戻すことができます。アップデートが既に完全なオーディエンスに到達している場合は、ロールバックできます。

ロールアウトの復元

ロールアウトがまだ進行中の間は、それを復元できます。ロールアウトを復元すると、それを停止し、コントロールアップデートを再公開して、クライアントを以前の状態に戻します - 既にアップデートを受信していたユーザーも含めて。

復元は、シグナルがアップデートのロールアウトを継続すべきでないことを示し、完全なオーディエンスに到達する前にその影響を元に戻したい場合の適切なアクションです。

アクティブなロールアウトを復元するには：

eas update:revert-update-rollout

ロールアウト完了後のロールバック

ロールアウトが完了した後（例：100%に到達した後）、復元するロールアウトは残っていません。その時点で、アップデートが実行されるべきでないと決定した場合は、ロールバックを使用します。

ロールバックは、クライアントに以前のバージョンを実行するか、埋め込まれたアップデートにフォールバックするよう指示する新しいアップデートを公開します。ロールバックは、アップデートが既に完全にロールアウトされ、ユーザーを既知の良好な状態に戻す必要がある場合に使用されます。

以前のアップデートにロールバックするには：

eas update:rollback

インタラクティブガイドが、ロールバックの種類の選択とロールバックの実行を支援します。

永続化された状態の互換性に関する注意

ロールアウトを復元したり、以前のアップデートにロールバックしたりすることは、古いコードが新しいアップデートによって作成された永続化された状態で正しく実行できることを前提としています。アップデートが後方互換性のない変更（例：ローカルストレージやデータベーススキーマへの変更）を導入した場合、ユーザーを古いアップデートに戻すとクラッシュや望ましくない動作を引き起こす可能性があります。

安全にロールバックできない状況では、互換性を復元する新しいアップデートを公開することが必要な場合があります。

アップデートの問題のデバッグ

Expoドキュメントには、ビルドがアップデートを受信しない、ランタイムバージョンの不一致、起動直後のアップデートクラッシュ、アセットの読み込み失敗などの一般的な失敗シナリオを説明する徹底的なデバッグガイドが含まれています。また、expo-updatesログの検査、ランタイムバージョンの確認、アップデートマニフェストの調査などの実践的なデバッグ戦略もカバーしています。

ほとんどのアップデートの問題は、設定の不一致や期待するアップデートに対してビルドが適格でないことに起因し、どこを見るべきかを知れば通常は診断が簡単です。

まとめ

まだ本番環境でEAS Updateを使用していない場合は、試してみる価値があります。ユーザーに直接アップデートをリリースすることは最初は大きなステップのように感じるかもしれませんが、ロールアウト、監視、回復オプションが整っていれば、アップデートは自信を持って導入できるものになります。

EAS Updateは、コントロールを維持しながら迅速に行動する能力を提供します。変更を段階的に導入し、実際のユーザーとの動作を観察し、必要に応じて対応することができます - すべて同じワークフロー内で。

EAS Updateは優れた開発者体験を提供し、チームが世界クラスのユーザー体験と改善を迅速にリリースすることに集中できるようにします。適切な運用習慣が整っていれば、アップデートは毎日使用している人々のためにアプリを継続的に改善する自然で信頼できる方法になります。