バージョン対象

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

Ionic AppFlow から移行する場合?

Ionic AppFlow から来た場合は、このガイドはあなたにとって特別に重要です。 AppFlow は、ネイティブ版の更新を自動的にマッチングし、Capgo は、より多くの制御と柔軟性とともに同じ機能を提供します。 以下の AppFlow 移行ガイド を参照して、ステップごとに移行の指示を確認してください。

概要

Capgo のバージョン対象システムは、次の機能を提供します。

• 互換性のある更新を自動的にユーザーに提供する ユーザーのネイティブアプリのバージョンに基づいて
• 破壊的な変更 互換性のないアプリのバージョンに到達するのを防ぐ
• 複数のアプリのバージョンを管理する __CAPGO_KEEP_0__
• 同時に複雑なロジックなしで 特定のユーザー セグメントにアップデートをロールアウト

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

あなたが Ionic AppFlow に慣れている場合 あなたは、ユーザーが互換性のあるアップデートを受け取ることを保証することは、どれほど重要かを理解しているはずだ。AppFlow は、ライブ アップデート バンドルをネイティブ アプリのバージョンと自動的にマッチさせ、互換性のない JavaScript が古いネイティブ code に配信されるのを防いでいた。

Capgo は、同じ安全性の保証を提供し、追加の機能も提供している。さらに細かい制御

• 複数の戦略 (チャネル、semver、ネイティブ制約)
• バージョン マッチングのより細かい制御
• バージョン分布の視覚化
• API と CLI はダッシュボード管理とともに制御

このアプローチは、特に以下のシナリオで役立ちます。

• ユーザーがアプリの異なるメジャーバージョン (例: 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. ネイティブ バージョン制約: 不適切なネイティブ バージョンに配布されるバンドルを防止する
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]

コピーする

この 推奨されるアプローチ は、バージョンアップデートとメジャーバージョンアップデートの管理に役立ちます。AppFlowの配信モデルに似ています。

例

• App v1.x (100,000ユーザー) → production チャネル
• App v2.x (50,000ユーザーにバージョンアップデートが含まれる) → v2 チャネル
• App v3.x (10,000 beta users) → v3 チャンネル

実装

ステップ 1: 各主バージョンごとにチャンネルを設定する

// 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: true,
      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: true,
      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: true,
      defaultChannel: 'v3', // Routes v3 users automatically
    }
  }
};

ステップ 2: チャンネルを作成する

# 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

ステップ 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 の変更は必要ありません!

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

シナリオ 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
• は、バージョン は、バージョン は、バージョン 2.0.0 は、バージョン
• Prevents breaking changes from reaching older native code

古いネイティブ __CAPGO_KEEP_0__ への破壊的な変更を防ぐ

# 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

セマンティック バージョニングが必要

アプリのバージョンがセマンティック バージョニング (semver) に従っている場合にのみ、この戦略が機能します。 バージョン番号が次の形式に従っていることを確認してください。 MAJOR.MINOR.PATCH 3. 仕様:ネイティブ バージョン制約

バンドルにネイティブ バージョン制約を指定して、不互換のデバイスへの配信を防止します。

3. 仕様:ネイティブ バージョン制約

バンドルにネイティブ バージョン制約を指定して、不互換のデバイスへの配信を防止します。

バンドルをアップロードする際に、最小のネイティブバージョンを指定できます:

# 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. Go to チャンネル → チャンネルを選択
2. 有効
3. 変更を保存

または CLI:

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

例

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

これは有用です:

• ユーザーがアプリストアから新しいバージョンを手動でインストールした場合
• ユーザーが常に最新のセキュリティパッチを保証する必要がある場合
• ユーザーがリグレッションバグを防止したい場合

戦略 5: デバイス レベル ターゲット

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

特定のバージョンを強制する

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 ダッシュボードで:

1. 以下の手順に従ってください デバイス → デバイスを検索
2. クリック チャネルを設定 または バージョンを設定
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: true,
      defaultChannel: 'production',
    }
  }
};

2. App 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: true,
      defaultChannel: 'v2', // New users get v2 channel
    }
  }
};

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

# 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"

両方のバージョンのバージョン分布を監視する

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

• v1 と v2 のユーザー数
• バージョンごとの Bundle アドプション率
• バージョンごとのエラーまたはクラッシュ数

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. Cloud Override via setChannel() call
3. defaultChannel in capacitor.config.ts
4. Default Channel (Cloud設定) - 最低優先度

Precedence Example

ユーザーのアプリが defaultChannel: 'v2' ですが、ユーザーのデバイスを上書きします 'beta' ダッシュボード内では、 'beta' チャンネルから更新を受け取ることになります。

ベスト プラクティス

メジャーバージョン用にデフォルトチャンネルを常に設定する

// ✅ 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

シームレス バージョニングを使用する

# ✅ 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からチームが移行する場合、ここでは__CAPGO_KEEP_0__のバージョン対象のバージョンをどう比較するか説明します。 機能, here’s how Capgo’s version targeting compares:

__CAPGO_KEEP_0__	バージョンベースのルーティング	Capgo
バージョンに基づく自動	Automatic via	__CAPGO_KEEP_0__ defaultChannel + 多重戦略
意味的バージョニング	基本的なサポート	高度な --disable-auto-update (メジャー/マイナー/パッチ)
ネイティブバージョン制約	AppFlow ダッシュボードで手動で設定	組み込み --native-version CLI のフラグ
チャネル管理	Web UI + CLI	Web UI + CLI + API
デバイスのオーバーライド	デバイスレベルの制御が限られている	ダッシュボード/API経由でフルコントロール
自動ダウンレートの防止	はい	はい --disable-downgrade
バージョン管理	マニュアルブランチ/チャンネル管理	チャンネル優先順位で自動化
自主ホスティング	いいえ	はい (フルコントロール)
バージョン分析	基本	バージョンごとの詳細なメトリクス

AppFlowの平行性と超え

Capgoは AppFlowが提供していたすべてのバージョン対象機能と、追加の制御機構を提供します。 AppFlowの自動バージョンマッチングに依存していた場合、__CAPGO_KEEP_0__はより多くの柔軟性と安全性を提供します。 that AppFlow offered, plus additional control mechanisms. If you relied on AppFlow’s automatic version matching, you’ll find Capgo equally safe with more flexibility.

トラブルシューティング

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

確認する内容を確認してください。

1. チャンネル割り当て: デバイスが正しいチャンネルに接続されていることを確認してください。

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

2. バージョン制約: バンドルのネイティブバージョン要件を確認してください。

   • ダッシュボード → バンドル → 「ネイティブバージョン」列を確認してください。

3. Semver設定: チャンネルの disable-auto-update 設定

   npx @capgo/cli channel list

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

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

間違ったバージョンにバンドルが配信された

1. デフォルトのチャネルを確認する: 正しいチャネルが選択されていることを確認する capacitor.config.ts
2. バンドル アップロードを確認する: 指定されたチャネルにバンドルがアップロードされたことを確認する
3. ネイティブ バージョンを確認する: 正しく使用されたことを確認する --native-version フラグが正しく使用されたかどうかを確認する

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

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

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

Ionic AppFlow からマイグレーションする場合 イオニック アプリフローCapgo のバージョン対象の機能は、より多くの柔軟性を備えた Capgo における、バージョン対象の機能と非常に似ています。

概念マッピング

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

AppFlowユーザーのための主な違い

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

移行手順

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

完全な移行ガイド

Capgo SDK の置き換えと API のマッピングを含む完全な移行指示については、 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はバージョンごとのアップデート配信に複数の戦略を提供します。

1. バージョンベースのルーティング: バージョンを自動的に分離する defaultChannel
2. セマンティック バージョニング: メジャー/マイナー/パッチ境界を跨る更新を防止する
3. ネイティブ バージョン制約: バンドル用の最低ネイティブ バージョンを要求する
4. 自動ダウングレード防止: 新しいネイティブ バージョンに古いバンドルを配信しない
5. デバイス オーバーライド: テストとターゲットのための手動制御

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

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

• Breaking Changes ガイド - 詳細なチャネル バージョニング戦略
• チャネル管理 - チャネル構成の完全な参考資料
• 更新動作 - ネイティブ版の遅延と条件