# CodePushの代替案とPaktaへの移行

App Center CodePush終了後の選択肢を比較し、SDKの置き換え、ネイティブアプリの更新、配信対象と復旧手順を含む移行計画を立てます。

## App Center CodePush に代わるものは何ですか? {#answer}

Pakta は、アップデート SDK を置き換えて新しいネイティブ ビルドを出荷したいチームのための React Native OTA オプションです。これはドロップイン CodePush サーバーではありません。`rn-update`、`.ppk` アーティファクトおよび Pakta アプリケーション/チャネル ターゲティングは、異なる統合コントラクトを使用します。既存の CodePush バイナリは、デプロイメント キーを変更するだけでは Pakta アップデートを受け取ることができません。

Microsoft は、2025 年 3 月 31 日に App Center CodePush を廃止しました。Microsoft はスタンドアロン サーバーも公開したため、ホスト型サービスの廃止は、CodePush ベースのすべてのオプションが消滅することを意味するものではありません。 「廃止通知](https://learn.microsoft.com/en-us/appcenter/retirement)」および「スタンドアロンCodePushサーバー](https://github.com/microsoft/code-push-server)」を参照してください。

## 移行パスを比較 {#options}

|パス |何が変わるのか |何を検証するか |
| --- | --- | --- |
|スタンドアロンの CodePush |ホスティング、エンドポイント、および場合によってはクライアントの構成 |サーバーの操作と SDK/ランタイムの正確な互換性 |
| Expo EAS アップデート | `expo-updates` と EAS ワークフローに移動 |ネイティブ統合、ランタイム バージョンおよびチャネル |
| Pakta | `rn-update` に移行し、ネイティブの基準ビルドを登録して `.ppk` 更新を配信します | ネイティブ連携、配信対象の識別、デバイスの復旧 |

Microsoft のオリジナルの [React Native CodePush リポジトリ ](https://github.com/microsoft/react-native-code-push) はアーカイブされてお​​り、新しいアーキテクチャをサポートしていないと記載されています。 CodePush クライアントを保持している場合は、正確なフォークとバージョンを確認してください。 Expo のパスについては、[Expo の移行ガイド](https://docs.expo.dev/eas-update/codepush/) を使用してください。

## コードを変更する前に概念をマップする {#mapping}

| CodePush のコンセプト | Pakta ワークフロー |移行の結果 |
| --- | --- | --- |
|導入キー |アプリケーション `appKey` とネイティブ チャネル ID |資格情報と識別子は再利用できません。
|ターゲットバイナリバージョン |登録されたネイティブ パッケージとチャネル/バージョン ターゲット |最初に正確に新しいインストーラーを登録します。
|リリースバンドル | CLI で生成された `.ppk` |ソースから再構築します。古い CodePush アーティファクトをアップロードしないでください。
|インストール モードと準備完了の通知 |アップデート戦略と健全性確認 |アクティベーションと起動時の正常性動作を再確認する |
|ロールアウトとロールバック |目標の割合と回復の展開 |コンソールの状態だけでなく、デバイスの動作をテストする |

これはワークフロー マッピングであり、API の互換性ではありません。実際の契約については、[SDK 統合 ](/docs/integration) および [チャネル ](/docs/channels) をお読みください。

## 段階的に Pakta に移行する {#migration}

1. React Native バージョン、ネイティブ モジュール、Hermes 構成、インストールされているバイナリ バージョン、デプロイメント キー、および起動フックのインベントリを作成します。最新の安定版リリースのソースとソースマップを保持します。
2. 移行ブランチで、CodePush の JavaScript ラッパーとネイティブのバンドル読み込み統合を削除します。[Pakta のネイティブ接続手順](/docs/getting-started)または[Expo の接続手順](/docs/expo)に従ってください。バンドルを選択する更新システムは 1 つだけにします。
3. ターゲット プラットフォーム用の Pakta アプリケーションを作成します。内部ネイティブ チャネルを構成し、ルート プロバイダー、アクティブ化戦略、および [健全性確認](/docs/integration#health)。
4. 新しいリリース バイナリをビルドしてインストールします。 [最初のリリース ](/docs/publish#register-native) の説明に従って、その正確な APK/IPA を登録します。
5. 1 つのラベルの更新を内部チャネルに公開します。更新ハッシュ、コールドスタート、オフライン起動、安定版パッケージへのロールバックを確認してください。
6. 通常のリリース プロセスを通じて、新しいネイティブ ビルドを配布します。古い CodePush 集団とは別に採用を追跡し、互換性のある Pakta アップデートを段階的に公開します。

## 既存のインストールはどうなりますか? {#existing-users}

CodePush のみを含むアプリでも、`rn-update` を含めるためにネイティブ アップグレードが必要です。これらのデバイスは Pakta リリースの対象としてカウントしないでください。アップグレードしていないユーザー向けに、インストールされているバイナリで利用できるサポートされている回復ルートを含む、明確な計画を立ててください。

Paktaの配信を停止しても、すでにインストールされた更新は削除されません。初回の本番配信前に、[チャネルのライフサイクルと復旧手順](/docs/channels#lifecycle)を確認してください。

## どのように決定すればよいでしょうか? {#next}

クライアント プロトコルの維持、Expo のアップデート エコシステムの採用、および Pakta のリリース ワークフローの選択は、異なる要件です。本番環境を移行する前に、1 つのリリース ビルドをエンドツーエンドで検証します。 [React Native OTA の基礎 ](/docs/react-native-ota-update)、[Expo の更新と Pakta](/docs/expo-updates-vs-pakta) または [クイック スタート ](/docs/introduction)。