初回セットアップのチェックリスト
インストール手順と、このプラグインの完全なMarkdownガイドを含むセットアッププロンプトをコピーします。
完了しました オンボーディング. 次に Capgo を設定します 一度だけ. その後は、日々の作業は upload → test → deploy のみ.
ルール: channel はリリースレーンであり、development, productionチケットや機能、開発者名ではありません。
初回セットアップのチェックリスト
「初回セットアップ・チェックリスト」セクション-
channel を作成する: 最小限のセットを選択してください（詳細は以下）。
-
デフォルトの upload チャンネルを設定 における アプリ設定:
- Solo アプリ →
production - Team →
development
- Solo アプリ →
-
本番用チャンネル: public: on, device self-set: off, native 以下の update をブロック: on, auto-update guard: on
major. -
テスト用チャンネル (
development/staging): public: off, QA 用に device self-set: on。 -
CI からの upload を使用して
--delta(チェックサムとNative Buildの依存関係は自動です):ターミナル npx @capgo/cli@latest bundle upload \--channel development \--bundle "1.8.0-${BUILD_NUMBER}" \--comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \--deltaこの
--bundle値 必ず が有効である セマンティックバージョニング. これを SemVerテスター で検証してからアップロードしてください。 -
本番環境へデプロイ テスト完了後に、以下から ダッシュボード または CLI を使用して
-
チームとセキュリティ: 招待は一度のみ、最小限の権限で、 2FA を組織に設定し、CIには API キーを1つ用意します。
暗号化、 min_update_versionメタデータ、およびプレビューは オフにしてください 明確な理由がない限り。
プランを選択
「プランを選択」セクションシンプル: 1アプリ、1チャンネル: production
チーム: development + production. devへアップロード、prodへデプロイ。
Native Buildのバージョン: 必要に応じてチャンネルを追加（例： production-9.0 + test-9.0. ストアのユーザーはメインのproductionチャンネルに維持します）。
複数アプリ: アプリごとに同じシンプルなモデル（通常は1アプリにつき1 production チャンネル）。組織が大きくても、不要にチャンネルを増やさないでください。
リリース・トレイン (任意): staging → rc → production. 必要なすべてのアプリで同じテンプレートを使用してください。
Bundle名 vs コメント
「Bundle名 vs コメント」セクションBundle名は 必須です 以下のルールに従う必要があります セマンティックバージョニング. Capgo は、互換性チェック、チャンネルの自動更新ルール、およびロールバックに semver を使用します。すべての名前を以下で検証してください: SemVerテスター upload する前に。
- 名称 = CI からの semver、例：
1.8.0,1.8.0-beta.1、または1.8.0-20260629.42 - コメント = 人間向けの自由記述 →
commit abc1234 run 28059070270
semver を使用 pre-release ラベル（ -) を使用します。同じ MAJOR.MINOR.PATCHで多くの build をリリースする場合です。例えば、 1.8.0 pre-release部分に日付やビルドカウンターを追加してください： 1.8.0-20260629.1, 1.8.0-beta.2独自のカスタムフォーマットは使用しないでください。 fix-login-bug または 2.5.2026062306これらは有効なsemverではないため、アップロードの失敗や予期しない動作の原因となります。
リリースノートは --commentではなく、
あわせて参照： バージョン指定（version targeting） と bundleのバージョニング.
Delta upload
「Delta upload」というタイトルのセクション--delta アップロード deltaファイル これにより、デバイスは毎回フルバンドルではなく変更されたファイルのみをダウンロードします。チェックサムは常に自動で計算されます。チェックサムフラグを渡す必要はありません。
デフォルト: --delta (deltaファイル + zipバックアップ)
セクション「デフォルト: --delta (deltaファイル + zipバックアップ)」npx @capgo/cli@latest bundle upload \ --channel development \ --bundle "1.8.0-${BUILD_NUMBER}" \ --deltaこれはほとんどのアプリに推奨されるデフォルト設定です。Capgo はdeltaファイルを保存し、 と フルサイズのzipをバックアップとして保持します。Deltaをサポートしていない古いプラグインバージョンのデバイスは、このzipを使用します。ストレージコストをあまり気にしない場合に適しています。
ストレージ削減: --delta-only
「Storage saving: --delta-only」セクションnpx @capgo/cli@latest bundle upload \ --channel development \ --bundle "1.8.0-${BUILD_NUMBER}" \ --comment "commit ${GIT_SHA:0:7} run ${CI_RUN_ID}" \ --delta-only使用する --delta-only 〜したい場合 Capgo のストレージ容量を削減したい場合に使用します。フルサイズのzipではなく、差分（delta）ファイルのみが保存されます。アプリのサイズが大きい場合や、アップロード頻度が高くストレージ消費を抑えたい場合に適しています。
トレードオフ：サーバーにzipバックアップがないため、完全に差分ファイルに依存することになります。また、Deltaサポートのない古いプラグインバージョンのデバイスはアップデートできません。ストレージ節約が本当に必要な場合を除き、このオプションはスキップしてください。 --delta-only ストレージ節約が本当に必要な場合を除き、このオプションはスキップしてください。
デバイス側での追加のプラグイン設定は不要です。アップデーターが差分ファイルのリストを読み取り、変更されたファイルのみを取得します。
日々のワークフロー
「日々のワークフロー」セクションUpload to development (--delta) → test → deploy to production → don't touch channel settings againよくある間違い
「よくある間違い」セクション| 間違い | 解決策 |
|---|---|
| ストアの新規リリース前にOTAができると誤解している | プラグイン追加後のNative Buildとリリース |
| Bundleをアップロードするが、Channelにはデプロイしない | BundleをChannelに割り当てる（例： production) |
| 機能、チケット、または開発者ごとにChannelを作成 | 永続的なリリースレーンのみを使用する |
| CIでChannel名を動的に生成 | 固定名を使用： development, production |
| シンプルなアプリに対してChannelが多すぎる | まずは1〜2個のChannelから始める |
| 本番環境でのデバイスによる自動設定 | 本番はオフ、テスト用Channelはオン |
スキップ --delta | 追加 --delta アップロードする場合： --delta-only ストレージ容量を節約したい時のみ使用してください |
| Semver形式ではないbundle名 | 遵守してください セマンティックバージョニング および、以下で検証してください SemVerテスター |
| 時間の経過とともにバージョニング方式を変更すること | Semverを維持してください。追加のビルドにはプレリリースラベルを使用します（1.8.0-20260629.1) |
| 理由なく有効化されたMetadata / preview | デフォルトではオフにしてください |
