__CAPGO_KEEP_0__

このガイドでは、ユーザーのネイティブアプリバージョンに基づいて、最新の互換性のあるバンドルを自動的にユーザーに提供する方法を説明します。 このアプローチは、Ionic AppFlowのアプローチと似ています。このアプローチは、簡素化された更新管理と高速なロールアウトを実現し、互換性の問題を防ぎます。

Ionic AppFlowから移行する場合

Ionic AppFlowから来た場合は、このガイドは特に重要です。AppFlowは自動的に更新をネイティブバージョンにマッチさせていましたが、Capgoは同じ機能を提供し、より多くの制御と柔軟性を提供します。 AppFlow移行ガイド for step-by-step移行指示のために。

概要

Capgoのバージョン対象システムにより、

• ユーザーのネイティブアプリのバージョンに基づいて、 互換性のある更新を自動的に配信する
• 互換性のないアプリバージョンに到達する破壊的な変更を防ぐ 複雑なロジックなしで同時に複数のアプリバージョンを管理する
• 更新をスムーズに展開する simultaneously without complex logic
• Seamlessly roll out updates 特定ユーザー セグメントに特定

バージョン ターゲットの重要性 (特に AppFlow ユーザー向け)

あなたが「Ionic AppFlow」 をご存知の場合、ユーザーが互換性のある更新のみを受け取ることを保証することは、非常に重要です。 AppFlow は、ライブ アップデート バンドルをネイティブ アプリのバージョンと自動的にマッチさせ、互換性のない JavaScript が古いネイティブ __CAPGO_KEEP_0__ に配信されるのを防ぎました。codeは同じ安全性の保証

Capgo provides the same safety guaranteesバージョン マッチングのより細かい制御

• 複数の戦略 (チャネル、semver、ネイティブ制約)
• バージョン配布のよりよい可視性
• __CAPGO_KEEP_0__と__CAPGO_KEEP_1__はダッシュボード管理とともに制御
• API and CLI control alongside dashboard management

このアプローチは、特に以下のシナリオで便利です:

• ユーザーがアプリの異なるメジャーバージョン (例：v1.x、v2.x、v3.x) にある場合
• バージョンアップの際に破壊的変更を実施しながら、バックワード互換性を維持する必要がある場合
• 新しいバンドルが古いネイティブ code を破壊しないようにする場合
• ユーザーを一つのバージョンから別のバージョンに段階的に移行する場合
• AppFlow から移行し、更新の安全性を維持したい場合 How It Works

「How It Works」というセクション

Capgo uses a multi-layered approach to match users with compatible updates:

1. : 不互換なネイティブ バージョンに配布されるバンドルを防止するNative Version Constraints
2. チャネルベースのルーティング: 異なるアプリバージョンを異なるアップデートチャネルにルーティングする
3. 意味論的バージョン管理: メジャー/マイナ/パッチ境界を超えた更新を自動的にブロックする
4. デバイスレベルオーバーライド: 特定のデバイスまたはユーザーグループをターゲットする

バージョンマッチングフロー

graph TD
    A[User Opens App] --> B{Check Device Override}
    B -->|Override Set| C[Use Override Channel]
    B -->|No Override| D{Check defaultChannel in App}
    D -->|Has defaultChannel| E[Use App's defaultChannel]
    D -->|No defaultChannel| F[Use Cloud Default Channel]
    C --> G{Check Version Constraints}
    E --> G
    F --> G
    G -->|Compatible| H[Deliver Update]
    G -->|Incompatible| I[Skip Update]

戦略1: チャネルベースのバージョンルーティング

このは 推奨アプローチ バージョンアップやメジャーバージョンアップの管理に適したアプローチです。AppFlowの配信モデルと似ています。

例えば

• App v1.x (100,000ユーザー) → production チャンネル
• App v2.x (50,000ユーザーにバグ修正が含まれる) → v2 チャンネル
• App v3.x (10,000のベータユーザー) → v3 チャンネル

実装

各主バージョンごとにチャンネルを設定する

// capacitor.config.ts for version 1.x builds
import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'Example App',
  plugins: {
    CapacitorUpdater: {
      autoUpdate: 'atBackground',
      defaultChannel: 'production', // or omit for default
    }
  }
};

export default config;

// capacitor.config.ts for version 2.x builds
const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'Example App',
  plugins: {
    CapacitorUpdater: {
      autoUpdate: 'atBackground',
      defaultChannel: 'v2', // Routes v2 users automatically
    }
  }
};

// capacitor.config.ts for version 3.x builds
const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'Example App',
  plugins: {
    CapacitorUpdater: {
      autoUpdate: 'atBackground',
      defaultChannel: 'v3', // Routes v3 users automatically
    }
  }
};

チャンネルを作成する

# Create channels for each major version
npx @capgo/cli channel create production
npx @capgo/cli channel create v2
npx @capgo/cli channel create v3

# Enable self-assignment so apps can switch channels
npx @capgo/cli channel set production --self-assign
npx @capgo/cli channel set v2 --self-assign
npx @capgo/cli channel set v3 --self-assign

Step 3: バージョン固有のバンドルをアップロードする

# For v1.x users (from v1-maintenance branch)
git checkout v1-maintenance
npm run build
npx @capgo/cli bundle upload --channel production

# For v2.x users (from v2-maintenance or main branch)
git checkout main
npm run build
npx @capgo/cli bundle upload --channel v2

# For v3.x users (from beta/v3 branch)
git checkout beta
npm run build
npx @capgo/cli bundle upload --channel v3

自動ルーティング

アプリを起動したときに、ユーザーは自動的に指定されたチャンネルに接続します。これは、 defaultChannel in their installed app bundle. No JavaScript code changes required!

JavaScript __CAPGO_KEEP_0__ の変更が必要ありません!

• Zero code changes - チャンネルルーティングが自動的に行われます
• 明確な区別 - 各バージョンには独自の更新パイプラインがあります
• 柔軟なターゲット - 特定のバージョングループに更新をプッシュする
• 安全なロールアウト - 不相応のバージョンに破壊的な変更は届きません

Strategy 2: セマンティック バージョニング コントロール

Capgoの組み込みセマンティック バージョニング コントロールを使用して、バージョン境界を超える更新を防止します。

メジャー バージョンを跨いだ自動更新を無効にする

# Create a channel that blocks major version updates
npx @capgo/cli channel create stable --disable-auto-update major

この設定は次のことを意味します:

• アプリのバージョン 1.2.3 は、バージョン 1.9.9
• ユーザーは NO バージョン 2.0.0 自動的に
• Prevents breaking changes from reaching older native code

破壊的な変更が古いネイティブ

# Block minor version updates (1.2.x won't get 1.3.0)
npx @capgo/cli channel set stable --disable-auto-update minor

# Block patch updates (1.2.3 won't get 1.2.4)
npx @capgo/cli channel set stable --disable-auto-update patch

# Allow all updates
npx @capgo/cli channel set stable --disable-auto-update none

__CAPGO_KEEP_0__が必要です

__CAPGO_KEEP_0__を使用するには、semver (シーケンシャル バージョニング) に従ってアプリのバージョンを管理する必要があります。バージョン番号は、以下の形式でなければなりません。 MAJOR.MINOR.PATCH Strategy 3: Native Version Constraints

「Strategy 3: Native Version Constraints」

nativeVersion Delay Conditionを使用する

「nativeVersion Delay Conditionを使用する」

ターミナル画面

# This bundle requires native version 2.0.0 or higher
npx @capgo/cli bundle upload \
  --channel production \
  --native-version "2.0.0"

機能のしくみ

1.xのネイティブバージョンのデバイスは、このバンドルを受信しない。2.0.0以上のデバイスのみが受信する。新しいネイティブAPIまたはプラグインが必要なアップデートに適しています。

用途

1. 新しいネイティブプラグインが必要

   # Bundle needs Camera plugin added in v2.0.0
   npx @capgo/cli bundle upload --native-version "2.0.0"

2. ネイティブのAPIの変更

   # Bundle uses new Capacitor 6 APIs
   npx @capgo/cli bundle upload --native-version "3.0.0"

3. 段階的な移行

   # Test bundle only on latest native version
   npx @capgo/cli bundle upload \
     --channel beta \
     --native-version "2.5.0"

4. 自動ダウングレード防止戦略

ユーザーが古いバージョンのネイティブアプリにバンドルを受け取るのを防ぐ。

チャンネル設定で有効にする

Capgo ダッシュボードで:

1. 「 チャンネル → チャンネルを選択
2. 有効化 “ネイティブ下での自動ダウングレードを無効にする”
3. 変更を保存

または CLI: から

npx @capgo/cli channel set production --disable-downgrade

例

• ユーザーのデバイス：ネイティブ版 1.2.5
• チャンネルバンドル：バージョン 1.2.3
• 結果：アップデートはブロックされます (ダウングレードになります): アップデートはブロックされます (ダウングレードになります)

この機能は、以下の場合に便利です:

• ユーザーがアプリストアから最新バージョンを手動でインストールした場合
• ユーザーが常に最新のセキュリティパッチを保有することを確認したい場合
• ユーザーがバグの再現を防止したい場合

Strategy 5: Device-Level Targeting

特定のデバイスまたはユーザーグループにチャンネル割り当てをオーバーライドします。

Force Specific Version for Testing

import { CapacitorUpdater } from '@capgo/capacitor-updater'

// Force beta testers to use v3 channel
async function assignBetaTesters() {
  const deviceId = await CapacitorUpdater.getDeviceId()

  // Check if user is beta tester
  if (isBetaTester(userId)) {
    await CapacitorUpdater.setChannel({ channel: 'v3' })
  }
}

デバイスオーバーライド

CapgoのCapgoダッシュボードで:

1. Go to デバイス → デバイスを検索
2. Click チャネルを設定 または バージョンを設定
3. 特定のチャネルまたはバンドルバージョンで上書き
4. デバイスは上書きされたソースからアップデートを受け取ります

テストアップデート

デバイスのオーバーライドを使用して、すべてのユーザーに展開する前に、自分のデバイスでアップデートをテストします。

アプリフロー スタイルのワークフローを完了する

すべての戦略を組み合わせた完全な例があります。

1. 初期設定 (アプリ v1.0.0)

# Create production channel with semver controls
npx @capgo/cli channel create production \
  --disable-auto-update major \
  --disable-downgrade

capacitor.config.ts

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      autoUpdate: 'atBackground',
      defaultChannel: 'production',
    }
  }
};

2. バイナリ互換性のないアップデート (アプリ v2.0.0)

# Create v2 channel for new version
npx @capgo/cli channel create v2 \
  --disable-auto-update major \
  --disable-downgrade \
  --self-assign

# Create git branch for v1 maintenance
git checkout -b v1-maintenance
git push origin v1-maintenance

// capacitor.config.ts for v2.0.0
const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      autoUpdate: 'atBackground',
      defaultChannel: 'v2', // New users get v2 channel
    }
  }
};

バージョン 1 とバージョン 2 の両方にアップデートをプッシュする

# Update v1.x users (bug fix)
git checkout v1-maintenance
# Make changes
npx @capgo/cli bundle upload \
  --channel production \
  --native-version "1.0.0"

# Update v2.x users (new feature)
git checkout main
# Make changes
npx @capgo/cli bundle upload \
  --channel v2 \
  --native-version "2.0.0"

バージョン 1 とバージョン 2 の両方のバンドル採用率を監視する

Capgo ダッシュボードを使用して、以下を追跡する

• バージョン 1 とバージョン 2 の両方のユーザー数
• バージョン 1 とバージョン 2 の両方のバンドル採用率
• バージョンごとのエラーまたはクラッシュ

5. 旧バージョンの削除

v1 の使用率が閾値以下の場合:

# Stop uploading to production channel
# Optional: Delete v1 maintenance branch
git branch -d v1-maintenance

# Move all remaining users to default
# (They'll need to update via app store)

チャンネル順位

Capgo が使用する順位順序は次のようになります。

1. デバイスのオーバーライド (ダッシュボードまたはAPI) - 最高優先順位
2. クラウドオーバーライド via setChannel() エアショ
3. 安丛パトルート in capacitor.config.ts
4. パトルートコントエントルート パトルートコントエントルートバートエントルート

パトルートコントエントルートバートエントルートパトルートコントエントルートパトルートコントエントルートバートエントルート

パトルートコントエントルートバートエントルートパトルートコントエントルートパトルートコントエントルートバートエントルートパトルートコントエントルートバートエントルート。 defaultChannel: 'v2' パトルートコントエントルートバートエントルートパトルートコントエントルートパトルートコントエントルートバートエントルートパトルートコントエントルート。パトルートコントエントルートバートエントルートパトルートコントエントルートパトルートコントエントルートバートエントルート、パトルートコントエントルートバートエントルートパトルートコントエントルートパトルートコントエントルートバートエントルート。 'beta' パトルートコントエントルートバートエントルートパトルートコントエントルートパトルートコントエントルートバートエントルートパトルートコントエントルート。パトルートコントエントルートバートエントルートパトルートコントエントルートパトルートコントエントルートバートエントルート、パトルートコントエントルートバートエントルートパトルートコントエントルートパトルートコントエントルートバートエントルート。 'beta' パトルートコントエントルートバートエントルートパトルートコントエントルートパトルートコントエントルートバートエントルートパトルートコントエントルート。パトルートコントエントルートバートエントルートパトルートコントエントルートパトルートコントエントルートバートエントルート、パトルートコントエントルートバートエントルートパトルートコントエントルートパトルートコントエントルートバートエントルート。

ベスト プラクティス

1. メジャーバージョンでは常にdefaultChannelを設定する

// ✅ Good: Each major version has explicit channel
// v1.x → production
// v2.x → v2
// v3.x → v3

// ❌ Bad: Relying on dynamic channel switching
// All versions → production, switch manually

2. セマンティック バージョニングを使用する

# ✅ Good
1.0.0 → 1.0.1 → 1.1.0 → 2.0.0

# ❌ Bad
1.0 → 1.1 → 2 → 2.5

ターミナル ウィンドウ

# ✅ Good: Separate branches per major version
main (v3.x)
v2-maintenance (v2.x)
v1-maintenance (v1.x)

# ❌ Bad: Single branch for all versions

4. リリース前のテスト

# Test on beta channel first
npx @capgo/cli bundle upload --channel beta

# Monitor for issues, then promote to production
npx @capgo/cli bundle upload --channel production

5. バージョン分布の監視

ユーザーは最新のネイティブバージョンにアップグレードしていますか?

• 古いバージョンはまだ高トラフィックを受けているですか?
• 古いチャネルを非推奨にするべきですか?
• Ionic AppFlowとの比較

Ionic AppFlowとの比較

Ionic AppFlow から移行するチーム向け Ionic AppFlow から __CAPGO_KEEP_0__ のバージョン対象を比較する, here’s how Capgo’s version targeting compares:

Ionic AppFlow	__CAPGO_KEEP_0__	Capgo
ネイティブのバージョンに基づく自動	バージョンを使用した自動	+ 多くの戦略 defaultChannel バージョンシンタックス
Automatic via	基本サポート	高度な「{0}」 --disable-auto-update (メジャー/マイナー/パッチ)
ネイティブバージョン制約	AppFlow ダッシュボードで手動設定	組み込み --native-version flag in CLI
チャンネル管理	Web UI + CLI	Web UI + CLI + API
デバイスオーバーライド	デバイスレベル制限の制限	フルコントロール via Dashboard/API
自動ダウングレード防止	はい	はい via --disable-downgrade
マルチバージョンメンテナンス	手動ブランチ/チャネル管理	チャネル順位による自動化
自主ホスティング	いいえ	はい (フルコントロール)
バージョン分析	ベーシック	__CAPGO_KEEP_0__の詳細バージョンメトリクス

AppFlowの平等性とその超越

Capgoは AppFlowが提供したすべてのバージョン対象機能 の機能に加え、追加の制御メカニズムを提供します。 AppFlowの自動バージョンマッチングに依存していた場合、Capgoは安全性が同等で、より多くの柔軟性を提供します。

トラブルシューティング

ユーザーが更新を受け取っていない

確認すること

1. チャンネル割り当て: __CAPGO_KEEP_0__を正しいチャネルに設定しているか確認する

   const channel = await CapacitorUpdater.getChannel()
   console.log('Current channel:', channel)

2. バージョン制約: __CAPGO_KEEP_0__にネイティブバージョン要件があるか確認する

   • ダッシュボード → バンドル → 「ネイティブバージョン」列を確認

3. Semver設定: __CAPGO_KEEP_0__の disable-auto-update 設定

   npx @capgo/cli channel list

4. デバイスオーバーライド: デバイスが手動オーバーライドをしているか確認する

   • ダッシュボード → デバイス → デバイスを検索 → チャネル/バージョンを確認

不正バンドルが正しいバージョンに配信された

1. デフォルトのチャネルを確認: 正しいチャネルが選択されていることを確認 capacitor.config.ts
2. バンドルアップロードを確認: 意図したチャネルにバンドルがアップロードされたことを確認
3. ネイティブバージョンを確認: 正しく使用されたことを確認 --native-version 古いバージョンに影響を与える変更点

古いバージョンに影響を与える変更点

1. 即時修正: 有効デバイスを安全バンドルにオーバーライドする
   • ダッシュボード → デバイス → 一括選択 → バージョン設定
2. 長期的な修正: バージョン管理されたチャンネルを作成し、別々のブランチを維持する
3. 予防: リリース前に代表的なデバイスでアップデートをテストする

Ionic AppFlow からマイグレーション

Ionic AppFlow から移行する場合 Ionic AppFlow , version targeting works very similarly in Capgo, with improved flexibility:

概念マッピング

AppFlow コンセプト	Capgo の同等	ノート
デプロイ チャネル	Capgo チャネル	同じ概念、より強力なもの
ネイティブ バージョン ロック	--native-version フラグ	より詳細な制御
チャネル プライオリティ	チャンネル優先順位 (override → cloud → default)	より透明な優先順位
デプロイ対象	チャンネル + semver制御	複数の戦略が利用可能
プロダクション チャンネル	production チャンネル (または任意の名前)	柔軟な名前付け
Gitベースのデプロイ	CLI ブランチからバンドルアップロード	同じワークフロー
自動バージョンマッチング	defaultChannel + バージョン制約	複数の戦略を組み合わせた強化

AppFlowユーザ向けの主な違い

1. より多くの制御: Capgo は、複数の戦略 (チャネル、semver、ネイティブ バージョン) を組み合わせることができます
2. より良い可視性: ダッシュボードはバージョン分布と互換性の問題を表示します
3. API アクセス: バージョン目標の完全なプログラム制御
4. 自社ホスティング: 同じバージョンロジックを持つアップデートサーバーを実行するオプション

移行手順

1. アプリフロー チャンネルをマップする Capgo チャンネルにマップする (通常 1:1)
2. 設定 defaultChannel に capacitor.config.ts 各主バージョン
3. semver ルールを設定 自動的にバージョン境界でブロックしたい場合は
4. バージョンごとにアップロードする 使用 --native-version 旗
5. バージョン分布の監視 Capgo Capgo ダッシュボード内

完全な移行ガイド

For complete migration instructions including SDK replacement and API mapping, see the AppFlow to Capgo Migration Guide.

高度なパターン

バージョンごとの段階的なロールアウト

// Gradually migrate v1 users to v2
async function migrateUsers() {
  const deviceId = await CapacitorUpdater.getDeviceId()
  const rolloutPercentage = 10 // Start with 10%

  // Hash device ID to get deterministic percentage
  const hash = hashCode(deviceId) % 100

  if (hash < rolloutPercentage) {
    // User is in rollout group - migrate to v2
    await CapacitorUpdater.setChannel({ channel: 'v2' })
  }
}

バージョンごとの機能フラグ

// Enable features based on native version
async function checkFeatureAvailability() {
  const info = await CapacitorUpdater.getDeviceId()
  const nativeVersion = info.nativeVersion

  if (compareVersions(nativeVersion, '2.0.0') >= 0) {
    // Enable features requiring v2.0.0+
    enableNewCameraFeature()
  }
}

バージョン間のA/Bテスト

// Run A/B tests within same native version
async function assignABTest() {
  const nativeVersion = await getNativeVersion()

  if (nativeVersion.startsWith('2.')) {
    // Only A/B test on v2 users
    const variant = Math.random() < 0.5 ? 'v2-test-a' : 'v2-test-b'
    await CapacitorUpdater.setChannel({ channel: variant })
  }
}

概要

Capgo provides multiple strategies for version-specific update delivery:

1. : バージョンを自動的に分離する: メジャー/マイナー/パッチ境界を超えてアップデートを防止する defaultChannel
2. : セマンティックバージョニングバージョンごとのA/Bテスト
3. ネイティブ バージョン制約: バンドルに必要な最小のネイティブ バージョンを指定
4. 自動ダウンレート防止: 新しいネイティブ バージョンに古いバンドルを配信しない
5. デバイス オーバーライド: テストとターゲット設定用の手動制御

これらの戦略を組み合わせることで、より多くの柔軟性と制御を備えたAppFlowスタイルの自動更新配信が実現します。アプリのバージョニングとデプロイワークフローに最も適したアプローチを選択してください。

詳細な特定の機能については:

• Breaking Changes Guide - 詳細なチャネル バージョニング戦略
• チャネル管理 - チャネル構成の完全なリファレンス
• 動作の更新 - ネイティブ版の遅延と条件

バージョン目標から続ける

Capacitorを使用している場合 バージョン目標 バージョン目標を使用してチャンネルルーティングとステージドロールアウトを計画する場合、 チャンネル チャンネル チャンネル チャンネル チャンネル チャンネルにおける実装詳細について ベータテスト ソリューション ベータテスト ソリューションにおける製品ワークフローについて バージョン ターゲット ソリューション バージョン ターゲット ソリューションにおける製品ワークフローについて