本番リリースのチェックリスト

本番リリース前に次の項目を確認する

ネイティブパッケージを最適化する

異なる利点はベースラインの品質に依存します。つまり、ベースラインがより小さく、よりクリーンであるということは、パッチがより小さいことを意味します。

iOS

同じアーカイブ (バージョン、ビルド時間、埋め込みバンドルはエクスポート オプションに関係なく固定されます) について、異なるオプションで ipa を数回エクスポートし、最小のものをホット アップデート ベースラインとしてアップロードします。エクスポート中に重複リソース (冗長なイメージ スケール、未使用のアーキテクチャ スライス) をクリーンアップするのが最も安上がりです。

アンドロイド

• crunchPngs false (インストールを参照): ビルド間でリソース バイトを安定に保ちます。これは、意味のある差分を取得するための前提条件です。

• apkanalyzer を使用して、重複したリソースと未使用のネイティブ ライブラリを検索します。

• 署名付きリリース APK をベースラインとして登録します。デバッグ ビルドとリリース ビルドを決して混合しないでください。

アップデートパッケージのサイズを制御する

.ppk には、JS バンドルとアセットのみが含まれます。通常、画像がバルクになります。

• 大きな画像を CDN から送信し、バンドルするのではなくオンデマンドでダウンロードします。

• 新しい画像アセットが更新パッケージが増加する主な理由です。公開する前にアセットの差分を確認します。

• Hermes を有効にすると、CLI はベースライン バイトコードを自動的に再利用するため (--hermesBase auto)、パッチは通常完全なパッケージよりもはるかに小さくなります。パッチに価値がない場合、プラットフォームは手動介入なしで完全なパッケージに戻ります。

ロールアウト規律

• 最初に内部: 本番チャネルでステージングする前に、内部テスト チャネルですべてのリリースを検証します (チャネル公開 を参照)。

• パーセントラダー: 10% → 30% → 100%、各ステップで一時停止して バージョン health。

• スケジュールを超える信号: ロールバックまたは失敗率が正しくないと思われる場合は、すぐに一時停止します。出荷が遅れるよりも遅い方が良いです。

• 拡張ごとのスナップショット: ロールアウトの各ステップは導入管理に明確な記録を残すため、「どのステップが問題を解決したか」は常に答えがあります。

アプリストアのレビューウィンドウ

提出された行動をレビュー資料と一致させてください。更新を使用して機能を非表示にしたり、レビューを回避したりしないでください。チャネルは承認ではなく配信を制御します。 【Apple公式レビューガイドライン](https://developer.apple.com/app-store/review/guidelines/#software-requirements)および対象ストアの要件】をご確認ください。

ロールバック計画

• 毎回のリリース前に、以前のバージョンが一覧に残っていて再配信できることを確認します。履歴パッケージは、いつでも新しい完全配信として再利用できます。ロールバック手順を参照してください。

• チーム内でアラートのしきい値について合意します。ロールバック/失敗率を誰が監視するか、およびその応答速度はどれくらいですか。

• ホット アップデートがクラッシュすると、SDK は自動的に最新の正常なバージョンにロールバックします。重要な初期化が 正常性確認 構成と一致していることを確認してください。そうしないと、時期尚早の自動確認によって保護がスキップされる可能性があります。

習慣をアーカイブする

• すべての publish --sourcemap でソースマップをアーカイブするため、実稼働スタックを常にシンボル化できます (エラー監視 を参照)。

• バージョン リスト自体が読み込まれるように、追跡可能な --name 値 (チケット番号または CI 実行 ID) を使用します。