チャンネル

Live Updateチャンネルは、そのチャンネルに対してアップデートを待ち受けるように設定された全てのデバイスと共有される、特定のJSバンドルビルドを指します。アプリにCapgo Live Updates SDKをインストールすると、そのチャンネルに設定された全てのネイティブバイナリは、アプリ起動時に利用可能なアップデートを確認します。チャンネルが指すビルドはいつでも変更でき、必要に応じて以前のビルドにロールバックすることもできます。

チャンネルの設定

全てのアプリには削除できないデフォルトの「Production」チャンネルが付属しています。新しいチャンネルを追加するには：

Capgoダッシュボードの「Channels」セクションに移動します
「New Channel」ボタンをクリックします
チャンネル名を入力して「Create」をクリックします

チャンネル名は任意のものを設定できます。一般的な戦略として、開発段階に合わせてチャンネルを設定することがあります：

Development - ローカルデバイスやエミュレータでライブアップデートをテストするため
QA - QAチームが広範なリリース前にアップデートを検証するため
Staging - 本番環境に近い環境で最終テストを行うため
Production - エンドユーザーがアプリストアから受け取るアプリのバージョン用

アプリでのチャンネルの設定

チャンネルを作成したら、適切なチャンネルを監視するようにアプリを設定する必要があります。この例では、Developmentチャンネルを使用します。

capacitor.config.ts（またはcapacitor.config.json）ファイルを開きます。pluginsセクションで、CapacitorUpdaterプラグインのchannelプロパティを希望のチャンネル名に設定します：

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      defaultChannel: 'Development',
    },
  },
};

次に、Webアプリをビルドし、npx cap syncを実行して更新された設定ファイルをiOSとAndroidプロジェクトにコピーします。このSync手順をスキップすると、ネイティブプロジェクトは以前に設定されていたチャンネルを使い続けます。

チャンネルへのバンドルの割り当て

ライブアップデートをデプロイするには、新しいJSバンドルビルドをアップロードし、それをチャンネルに割り当てる必要があります。Capgo CLIを使用して1つのステップでこれを行うことができます：

npx @capgo/cli@latest bundle upload --channel=Development

これにより、ビルドされたWebアセットがアップロードされ、新しいバンドルがDevelopmentチャンネルのアクティブビルドとして設定されます。そのチャンネルを監視するように設定されているアプリは、次回のアップデートチェック時に更新を受け取ります。

Capgoダッシュボードの「Bundles」セクションからもチャンネルにビルドを割り当てることができます。ビルド横のメニューアイコンをクリックし、「Assign to Channel」を選択してそのビルドのチャンネルを選択します。

バンドルのバージョン管理とチャンネル

Capgoでは、バンドルは個々のチャンネルに特有ではなく、アプリ全体でグローバルであることに注意することが重要です。同じバンドルを複数のチャンネルに割り当てることができます。

バンドルのバージョン管理では、チャンネル固有のビルドにはプレリリース識別子を使用したsemverセマンティックバージョニングを推奨します。例えば、ベータリリースは1.2.3-beta.1のようにバージョン管理されます。

このアプローチには以下の利点があります：

ビルド間の関係を明確に伝えます。1.2.3-beta.1は明らかに1.2.3のプレリリースです
チャンネル間でバージョン番号を再利用でき、混乱を減らせます
明確なロールバックパスを可能にします。1.2.3からロールバックする必要がある場合、1.2.2が前の安定リリースであることがわかります

典型的なチャンネル設定でのバンドルバージョンの例：

Developmentチャンネル：1.2.3-dev.1、1.2.3-dev.2など
QAチャンネル：1.2.3-qa.1、1.2.3-qa.2など
Stagingチャンネル：1.2.3-rc.1、1.2.3-rc.2など
Productionチャンネル：1.2.3、1.2.4など

プレリリース識別子を使用したsemverは推奨されるアプローチですが、厳密に必要というわけではありません。重要なのは、ビルド間の関係を明確に伝え、チームの開発プロセスに合ったバージョニング方式を見つけることです。

ライブアップデートのロールバック

バグを導入するライブアップデートをデプロイした場合や、その他の理由で元に戻す必要がある場合、簡単に以前のビルドにロールバックできます。ダッシュボードの「Channels」セクションから：

ロールバックしたいチャンネル名をクリックします
戻したいビルドを見つけ、クラウンアイコンをクリックします
アクションを確認します

選択したビルドは即座にそのチャンネルのアクティブビルドになります。アプリは次回のアップデートチェック時にロールバックされたバージョンを受け取ります。

デプロイメントの自動化

より高度なワークフロー向けに、CI/CDパイプラインの一部としてライブアップデートのデプロイメントを自動化できます。Capgoをビルドプロセスに統合することで、特定のブランチへのプッシュや新しいリリースの作成時に、自動的に新しいバンドルをアップロードしチャンネルに割り当てることができます。

Capgoライブアップデートの自動化についての詳細は、CI/CD Integrationドキュメントを参照してください。

デバイスへのデプロイ

チャンネルについて理解したところで、実際のデバイスへのライブアップデートのデプロイを開始する準備が整いました。基本的なプロセスは：

アプリにCapgo SDKをインストールする
希望のチャンネルを監視するようにアプリを設定する
ビルドをアップロードしそのチャンネルに割り当てる
アプリを起動してアップデートを待つ！

より詳細な手順については、Deploying Live Updatesガイドを参照してください。ハッピーアップデート！