モバイルアプリをリリースするときに変わること
Webアプリケーションのリリースに長年携わってきた人にとって、モバイルアプリのデリバリーは別世界に足を踏み入れるように感じられるでしょう。Webアプリの場合、ビルドしてサーバーにアップロードすれば完了です。ユーザーがブラウザをリロードすれば、最新バージョンが表示されます。サーバー、インフラ、リリースのタイミング、すべてを自分たちでコントロールできます。
モバイルアプリはそうはいきません。その違いは根深く、CI/CDパイプライン全体を変える必要があります。
アプリは他人のデバイス上で動作する
最初で最も根本的な違いは、アプリケーションが実際に動作する場所です。モバイルアプリは自分たちが管理するサーバー上ではなく、誰かのポケットの中のデバイス上にあります。サーバーのファイルを差し替えることはできません。ホットフィックスをプッシュして即座に反映させることもできません。
新しいバージョンをリリースするたびに、アプリケーションを再ビルドし、デジタル署名し、アプリストアに提出する必要があります。そしてユーザー自身がアップデートをダウンロードしてインストールする必要があります。すぐにアップデートするユーザーもいれば、何週間も通知を無視するユーザーもいます。まったくアップデートしないユーザーもいます。
これにより、デリバリーに対する考え方が変わります。全員が最新バージョンを使っているとは想定できません。重大なバグを修正しても、数分ですべてのユーザーに届けることはできません。Webデリバリーで持っていたコントロールは失われます。
2つのプラットフォーム、2つのビルドシステム
モバイルデリバリーでは、複数のビルドシステムを扱う必要があります。AndroidはGradle、iOSはXcodeを使用します。それぞれにSDKバージョン、依存関係、出力形式に関する独自のルールがあります。macOSでAndroidアプリをビルドしてiOSユーザーに配信することはできませんし、その逆もできません。
パイプラインは2つの独立したビルドパスを処理する必要があります。セットアップによって並列または直列に実行できますが、決して同じではありません。Androidのビルド設定はGradleファイルに、iOSのビルド設定はXcodeプロジェクトファイルとスキームに記述されます。依存関係の管理方法も異なり、署名プロセスもまったく異なります。
両方のプラットフォームをサポートする場合、CI/CDパイプラインは実質的に、テストと通知のロジックを一部共有しつつ、ビルドステップで分岐する2つのパイプラインになります。
署名は必須
モバイルアプリをユーザーのデバイスにインストールする前に、デジタル署名する必要があります。この署名は、アプリがあなた（またはあなたの組織）から提供されたものであり、なりすました者からのものではないことを証明します。Androidはキーストアファイル、iOSは証明書とプロビジョニングプロファイルを使用します。
これらは秘密情報です。漏洩すると、他の誰かがあなたのアプリになりすましたアプリを公開できてしまいます。紛失すると、PlayストアやApp Storeで既存のアプリに二度とアップデートを配信できなくなります。復旧手段はありません。新しいアプリのリスティングを作成し、既存のユーザーをすべて失うことになります。
パイプラインでは、これらのファイルを安全に保管する必要があります。リポジトリにハードコードしたり、バージョン管理にコミットしたりしてはいけません。シークレットマネージャー、CIシステムの暗号化ストレージ、専用の署名サービスを使用してください。パイプラインは署名ステップでのみこれらのファイルにアクセスし、それ以外ではアクセスしないようにします。
ストアがリリースのタイミングをコントロールする
APKやIPAファイルを直接ユーザーに送ることはできません。アプリはアプリストアを通す必要があります。Google PlayストアとApple App Storeには、それぞれレビュープロセスがあります。Google Playは通常数時間以内にレビューします。Appleのレビューはより時間がかかることがあり、多くの場合より厳格です。
つまり、ビルドが完了してからユーザーが新しいバージョンを使い始めるまでの時間は、自分たちではコントロールできません。サードパーティがアプリの公開タイミングを決定します。提出が却下された場合、問題を修正し、再ビルドし、再提出する必要があります。時計はリセットされます。
これはロールバック戦略にも影響します。Webの場合、ロールバックは以前のバージョンをデプロイすることを意味します。モバイルの場合、ユーザーに強制的に元のバージョンに戻させることはできません。すでにアップデートしたユーザーは、修正版をリリースするまで壊れたバージョンを使い続けることになります。そしてその修正版も再びレビューを受ける必要があります。
段階的ロールアウトが不可欠になる
簡単にロールバックできないため、リリース方法を慎重に計画する必要があります。AndroidとiOSの両方で段階的ロールアウトがサポートされています。Androidでは「段階的ロールアウト」、iOSでは「段階的リリース」と呼ばれています。
考え方はシンプルです。まず新しいバージョンをユーザーのごく一部（たとえば1%や5%）にリリースします。クラッシュレポート、エラー率、ユーザーフィードバックを監視します。問題がなければ、ロールアウトを10%、25%、50%、100%と拡大します。問題が発生した場合はロールアウトを一時停止します。影響を受けるのは、すでにアップデートを受け取った少数のユーザーグループだけです。
これは本格的なモバイルデリバリーには必須です。即座にロールバックできない場合にリスクを軽減するための主要な方法です。
これがパイプラインに与える影響
これらの違いはすべて、Webパイプラインとは大きく異なるCI/CDパイプラインを生み出します。モバイルパイプラインは以下を処理する必要があります。
次のフローチャートは、Webとモバイルの2つのパスを並べて示し、モバイルで追加されるゲートを強調しています。
- 異なるツールチェーンを使用したプラットフォーム固有のビルド
- 絶対に漏洩してはいけないシークレットを使用した安全な署名
- 自動化された提出によるアプリストアへのアップロード
- 一時停止や拡大が可能な段階的ロールアウト戦略
また、テストの考え方も変える必要があります。エミュレーターやシミュレーターで多くの問題を発見できますが、完璧ではありません。特定のハードウェア、センサー、ネットワーク条件を持つ実機でしか再現しないバグもあります。パイプラインには、仮想デバイスでの自動テストと、フルリリース前の実機でのテストプロセスの両方を含める必要があります。
モバイルCI/CDのクイックチェックリスト
- 署名キーと証明書はリポジトリではなく、安全なシークレットマネージャーに保管する
- AndroidとiOS用にそれぞれのツールチェーンを使用した個別のビルドジョブを設定する
- Google Play ConsoleとApp Store Connectへのアップロードを自動化する
- パイプラインに段階的ロールアウトまたは段階的リリースを実装する
- 段階的ロールアウト中にアラートをトリガーするクラッシュレポートとモニタリングを追加する
- リリース率を拡大する前に、エミュレーターと実機の両方でテストする
まとめ
モバイルデリバリーは、ビルドステップが異なるだけのWebデリバリーではありません。アプリは自分たちがコントロールできないデバイス上で動作します。ストアがリリースのタイミングをコントロールします。ロールバックはボタン一つでできません。CI/CDパイプラインは、これらの現実を最初から考慮する必要があります。プラットフォームに合わせてビルドし、安全に署名し、段階的にリリースし、執拗に監視する。これが、次のレビューサイクルまで修正できない本番インシデントに悩まされることなくモバイルアプリをリリースする唯一の方法です。