# 最初のアップデートを配信する

ネイティブビルドを登録し、更新パッケージを作成してチャネルと配信対象を設定し、端末で受信を確認します。

## 公開前 {#overview}

デバイスにはプロバイダーを備えたリリース アプリがあり、`Pakta demo A` と表示されます。 **別のネイティブ パッケージをインストールせずに** `Pakta demo B` に変更します。

別のテスト アプリケーションを 100% で使用します。本番環境には [段階的ロールアウト ](/docs/channels) を使用します。

## リリース パスを選択します {#release-flow}

| JS、スタイル、および JS 参照アセットのみ |ネイティブ コード、権限、依存関係、またはランタイム |
| :---: | :---: |
| **アップデートを公開** | **ネイティブ インストーラーを公開する** |
| JS の編集とテスト |ネイティブ プロジェクトの編集とテスト |
| ↓ | ↓ |
| `pakta bundle` は `.ppk` を生成します |ビルド リリース APK / AAB / IPA / APP |
| ↓ | ↓ |
|更新パッケージをアップロード | `pakta uploadApk` / `uploadAab` / `uploadIpa` / `uploadApp` |
| ↓ | ↓ |
|登録済みチャンネルとネイティブ バージョンを選択する |その正確なインストーラーを保持し、配布します。
| ↓ | ↓ |
|パーセンテージの設定、プレビュー、公開 |今後の更新ではこのネイティブ バージョンを対象にする |
| ↓ | ↓ |
| **インストールされているデバイスの一致を確認、ダウンロード、アクティベートします** | **ユーザーは最初に新しいネイティブ バージョンをインストールします** |

最初の統合では、左の分岐の前に右の分岐を完了します。このウォークスルーでは Android を使用します。ステップ 2 には、iOS および HarmonyOS のアップロード コマンドがリストされています。

## 1. アプリケーションとネイティブバージョンの確認 {#setup}

アプリのルートから実行します。 `me` は現在の ID を確認します。

```bash
pakta me
pakta selectApp --platform android
```

例では、`android`、チャネル `default`、ネイティブ バージョン `1.0.0` を使用します。 **`1.0.0` をデバイスに表示されているネイティブ バージョンに置き換えます。** 例に一致させるためだけに更新名を使用したり、アプリを再構築したりしないでください。

## 2. インストール済みの正確なビルドを登録する {#register-native}

この APK パスは、フレーバーのない標準 Gradle プロジェクト用です。実際のアーティファクトのパスを置き換えます。

```bash
pakta uploadApk ./android/app/build/outputs/apk/release/app-release.apk
pakta packages --platform android
```

CLI とコンソールのネイティブ パッケージ ビューには、チャネル、バージョン、ビルドが含まれています。インストールされているパッケージを新しく再構築したパッケージに置き換えないでください。

|フォーマット |登録コマンド |注 |
| --- | --- | --- |
| APK | `uploadApk PATH` |最も簡単なローカル Android 演習 |
| ＡＡＢ | `uploadAab PATH` |分散ビルドと関連する分割を一致させる |
| IPA | `uploadIpa PATH` |インストールされたビルドに対応するアーカイブ |
|ハーモニーアプリ | `uploadApp PATH` | DevEco に組み込まれた `.app` |

チャネルはネイティブ メタデータから取得され、デフォルトは `default` です。 `--channel` は、ID を書き換えるのではなく、アサートします。アップロードでは、ストア パッケージ全体を OTA コンテンツとして送信するのではなく、縮小されたベースラインを使用します。

## 3. ラベルを変更して更新をバンドルする {#bundle}

`Pakta demo A` を `Pakta demo B` に変更します。ネイティブの依存関係、ネイティブ バージョン、Hermes または RN を変更したり、アプリを再インストールしたりしないでください。

```bash title="App root"
pakta bundle --platform android --output .pakta/output/android.ppk --no-interactive
```

`.pakta/output/android.ppk` が存在し、バンドルはエラーなく完了しました。デフォルトのソースマップは `.pakta/intermedia/android/index.bundlejs.map` です。カスタム設定のビルド ログを確認してください。 Expo プロジェクト用に `--expo` を追加します。

ここでは `--name` を省略します。バンドルがすぐに公開に入ります。

## 4. プレビューしてテスト端末に公開する {#publish}

バージョン、チャネル、パスを置き換えます。これらの単一行コマンドは、PowerShell、Bash、および zsh で機能します。

```bash title="Preview only"
pakta publish .pakta/output/android.ppk --platform android --name demo-b --channel default --packageVersion 1.0.0 --rollout 100 --dryRun --no-interactive
```

プレビューはターゲットとパーセンテージを解析します。デバイスの互換性、アップロード接続、または公開を証明するものではありません。ターゲットが正しくなったら、次のように公開します。

```bash title="Publish to the separate test application"
pakta publish .pakta/output/android.ppk --platform android --name demo-b --channel default --packageVersion 1.0.0 --rollout 100 --sourcemap .pakta/intermedia/android/index.bundlejs.map --no-interactive
```

`packageId` と `deploymentIds` を保存します。アプリケーションの更新/デプロイメント ビューで、アクティブなターゲット、ネイティブ バージョン、チャネル、および 100% の割合を確認します。デバイスは、差分タスクが保留されている間も完全ダウンロードを使用できます。

## 5. デバイスで確認する {#verify}

1. **元のアプリを開きます**: 登録されたリリース ビルドをインストールしたままにして、ネットワークに接続します。
2. **アップデートの確認**: [アップデートの確認] を押すか、フォアグラウンドに戻ります。ダウンロード イベントを監視し、完了を待ちます。
3. **完全に閉じて再度開く**: `silentAndLater` は画面をすぐには変更しません。ダウンロード後にプロセスを終了し、アンインストールまたはデータの消去を行わずに再度開きます。
4. **両方の変更を確認します**: ラベルには `Pakta demo B` と表示されます。 `currentHash` は、埋め込みハッシュから新しいハッシュに変更されます。
5. **動作を確認**：重要な画面を開き、[テレメトリー分析](/docs/analytics)で成功またはロールバックのイベントを確認します。

| |前 |後 |
| --- | --- | --- |
|ラベル | Pakta デモ A | Pakta デモ B |
|ネイティブバージョン | 1.0.0 | 1.0.0 (変更なし) |
|現在のハッシュ |空、埋め込みとして表示 |新しい更新ハッシュ |

Aが表示されたままですか？[更新が届かない場合のトラブルシューティング](/docs/faq#no-update)を確認し、アクティベーション前に更新をダウンロードできているか調べてください。

## 後続のリリース {#versions}

互換性のある JS/アセットについては、手順 3 ～ 5 を繰り返します。ネイティブの変更では、そのバージョンをターゲットにする前に、新しいネイティブ パッケージを配布して登録する必要があります。

```bash
pakta versions --platform android
```

コンテンツとハッシュは不変です。名前と説明は編集できます。ネイティブ ベースライン、`.ppk` ファイル、一致するソースマップ、およびデプロイメント レコードを保持します。

## 運用インシデントからの回復 {#rollback}

|アクション |まだ更新されていないデバイス |不正なアップデートをすでに実行しているデバイス |
| --- | --- | --- |
|不適切な展開を一時停止する |その展開の受信を停止する |インストールされたコンテンツは元に戻されません。
|割合を減らす |後続の一致が少なくなる |アクティブなロールバックはありません |
|安定した履歴パッケージを元のターゲットに 100% 再デプロイ |安定したコンテンツを受信できる |その後のチェックとアクティベーションで戻ることができます |

コンソールで保持されている安定したパッケージを選択し、同じチャネルとネイティブ バージョンに対して新しい完全なデプロイメントを作成します。送信する前に、影響を受けるターゲットを確認してください。新しい展開シーケンスにより、古いコンテンツが新しいリリースとして適格になります。リカバリは、リモートで瞬時に元に戻すのではなく、デバイスのチェック/アクティブ化ポリシーに従います。

次へ: [チャネルとロールアウト](/docs/channels) · [制作チェックリスト](/docs/bestpractice)。