Skip to content
Capgo - Live Updates for Capacitor Apps Capgo

一回のセットアップチェックリスト

完了しました オンボーディングが終わりました。Capgoを一度 設定してください。次に、毎日作業はアップロード→テスト→デプロイ 最初に新しいストアビルドを発送してください.

ルール: チャンネルはリリースの流れ (development, production)、チケット、機能、開発者の名前ではありません。

一回限りのセットアップチェックリスト

セクション「一回限りのセットアップチェックリスト」

  1. チャンネルを作成する: 最小限のセットを選択してください (以下を参照)。

  2. デフォルトアップロードチャンネルを設定する アプリの設定 Soloアプリ →:

    • チーム → production
    • リリースチャンネル: development

  3. app settings パブリックオン、デバイス自律オフ、ネイティブオンの下で更新をブロック、オートアップデートガードオン major.

  4. テストチャネル (development / stagingパブリックオフ、デバイス自律オン(QA用)

  5. CIからアップロード with --delta チェックサムとネイティブ依存関係は自動で行われます:

    ターミナルウィンドウ
    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

    The --bundle 値 は有効でなければなりません 値 バージョニング. __CAPGO_KEEP_0__ で検証する SemVer テスター アップロードする前に

  6. 本番環境にデプロイする テストを終えた後、__CAPGO_KEEP_0__ から ダッシュボード or CLI.

  7. 招待するのは一度だけ、最小限の権限で 2要素認証 組織全体に、CI で 1 つの __CAPGO_KEEP_0__ キーを設定する API

暗号化をオフにし min_update_version, メタデータ、プレビュー オフ 理由が明確な場合のみ

サイズを選択

サイズを選択

シンプル: 1アプリ、1チャンネル: production

チーム: development + production。開発用にアップロード、プロダクション用にデプロイ

ネイティブ版: 必要な場合のみチャンネルを追加する、例えば production-9.0 + test-9.0. 本番チャネルにユーザーを保持するようにしてください。

多くのアプリ: 1 つのアプリごとに通常 1 つの production それぞれ) ごとに同じシンプルなモデルを使用しないでください。

リリーストレイン (任意): staging → rc → production. すべてのアプリに必要なアプリに同じテンプレートを使用するようにしてください。

バンドル名とコメントの区別

「バンドル名とコメントの区別」

バンドル名は 必要です セマンティック バージョニングを 遵守する必要があります。Capgoは、互換性のチェック、チャンネル自動更新のルール、ロールバックのためにsemverを使用します。 アップロードする前に、すべての名前を SemVer テスター

  • で検証してください。 名前 1.8.0, 1.8.0-beta.1CI からsemverを取得します。例えば、 1.8.0-20260629.42
  • 、または コメント commit abc1234 run 28059070270

セマンティック バージョニング (semver) を使用します。 プレリリース ラベル (バージョン番号の後ろの部分) -同じバンドル名の下で多くのビルドを配布する場合に使用します。 MAJOR.MINOR.PATCH例えば、 1.8.0 プレリリースに日付やビルドカウンタを追加します。 1.8.0-20260629.1, 1.8.0-beta.2日付やビルドカウンタを含まないプレリリースは使用しないでください。 fix-login-bug リリースノートは 2.5.2026062306に記載します。バンドル名に記載しないでください。

詳しくは --comment, not in the bundle name.

See also __CAPGO_KEEP_0__ と __CAPGO_KEEP_1__.

__CAPGO_KEEP_2__

セクション: デルタアップロード

--delta __CAPGO_KEEP_3__ をアップロードする __CAPGO_KEEP_4__

マニフェスト --delta したがって、デバイスは毎回全てのファイルをダウンロードするのではなく、変更されたファイルのみをダウンロードするようにします。チェックサムは常に自動的に計算されます。チェックサムフラグを渡す必要はありません。

デフォルト:
セクション: デフォルト: --delta (マニフェスト + zip バックアップ)
npx @capgo/cli@latest bundle upload \
  --channel development \
  --bundle "1.8.0-${BUILD_NUMBER}" \
  --delta

ほとんどのアプリでは推奨されるデフォルトです。Capgoはマニフェストを保存します そして ストレージを節約する

ストレージ節約: --delta-only --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_KEEP_0__のストレージを削減します reduce Capgo storagereduce __CAPGO_KEEP_0__ storage

サーバー上のzipバックアップがなければ、manifestパスに完全に頼ることになります。スキップ --delta-only 実際にストレージの節約が必要な場合に限り

デバイス上で追加のプラグイン設定は必要ありません。アップデーターはmanifestを読み取り、変更されたファイルのみを取得します。

動作のため

毎日のお仕事
Upload to development (--delta)
  → test
  → deploy to production
  → don't touch channel settings again

よくある間違い

「よくある間違い」のセクション
間違い修正
新しいストアのリリース前にOTAを期待するプラグインを追加した後、ネイティブアプリを再構築して配信する
バンドルをアップロードするが、チャンネルにデプロイしないバンドルをチャンネルに割り当てる (例えば production)
機能ごと、チケットごと、開発者ごとにチャンネルを分ける永久的なリリースレーンを使用する
ダイナミック CI チャンネル名固定名: development, production
複雑なアプリには多すぎるチャネル1-2チャネルから始めましょう
デバイスが自動でプロダクションモードに設定されているプロダクションモードではオフ、テストチャネルではオン
スキップ --delta追加 --delta アップロードに追加; ストレージを節約する必要がある場合のみ使用 --delta-only 非semverバンドル名
セマンティックバージョニングに従い、{0}で検証Follow semantic versioning and validate in the SemVer テスター
バージョニングスキームの変更セーヴァーを維持し、追加ビルド用にプレリリースラベルを使用する1.8.0-20260629.1)
メタデータ/プレビューが有効になっているが理由がないデフォルトではオフ

詳しく学ぶ

チャンネル
デフォルト、優先順位、ルーティング デルタアップデート
デルタアップデートの使用方法 CI/CD
CI/CD 自動アップロードとデプロイを自動化
バンドル チェックサム、依存関係、メタデータ