メインコンテンツへスキップ
チュートリアル

Capgo のバージョニングの仕組み

Capgo が Capacitor アプリのバージョンをどのように管理しているかを理解し、最大限に活用しましょう。major、minor、patch の意味も学べます。

Capgo Capgo のバージョン管理の仕組み | ブログ イラスト

Capgo は、Capacitor アプリのバージョン管理に 2 つの主要な変数を使用します:

  • ネイティブバージョン
  • JavaScriptバージョン
Capacitor アップデートシステム

すべてのバージョン選択は、Capgo によってサーバー側で決定されます。

バージョン管理システム

バージョン管理には Capgo が SemVer システムを使用しています。詳細は SemVer 仕様 または、Capgo の更新互換性を確認するには Semver テスター.

バージョン

比較対象のバージョンを Capgo が取得する場所

version キーを設定することで、この動作を上書きできます capacitor.config.json ファイル ドキュメントはこちら ネイティブバージョンはすべてのプラットフォームで無視されます。

iOS

iOS では、変数はプロジェクトのここで設定されます ios/App/App/Info.plist キーの下にCFBundleShortVersionString または ios/App/App.xcodeproj/project.pbxproj キーの下に MARKETING_VERSION もし MARKETING_VERSION が設定されていた Info.plist ファイル。

Androidでは

Androidでは、変数はプロジェクトのここで設定します android/app/build.gradle キーの下に defaultConfig.versionName

JavaScript ( Capgo bundle バージョン )

JavaScriptでは、var を以下に設定できます package.json キーの下に version それ以外の場合は、upload コマンドで指定する必要があります。

デフォルトの動作

設定を変更しない場合、Capgo チャネルはこのように動作します。

この動作は、デフォルトに設定したユニークなチャネルに基づきます。

Capacitor アプリを新規インストールした際

ユーザーが Ionic アプリを初めてダウンロードして開くと、Capgo サーバーに接続します。

現在、4つの出力が考えられます:

  • ネイティブ bundle バージョン (1.2.3) が Capgo bundle バージョン (1.2.4) より低い場合、Capgo はユーザーに bundle を送信します。
  • ネイティブ bundle バージョン (1.2.3) が Capgo bundle バージョン (1.2.3) と等しい場合、Capgo は「更新不要」を送信します。
  • ネイティブ bundle バージョン (1.2.4) が Capgo bundle バージョン (1.2.3) より高い場合、Capgo は「更新不要」を送信します。
  • ネイティブ bundle バージョン (1.2.3) が Capgo bundle バージョン (2.2.3) より MAJOR 低い場合、Capgo は「更新不要」を送信します。

その他の設定

ネイティブ環境での自動ダウングレードを無効化

この設定を false に変更すると、Capgo は常にバージョンの信頼できるソースとみなされます。 その場合、動作は以下のようになります:

  • ネイティブバージョン (1.2.4) が Capgo バージョン (1.2.3) より高い場合

Capgo はユーザーにバージョンを送信します。

自動アップグレード戦略を無効化

いくつか選べる戦略があります。詳しくはこちら。 こちら

JavaScript bundle のバージョン

JavaScript bundle のバージョンは、操作時に送信するものです npx @capgo/cli@latest bundle upload --channel production

オプションを使用しなかった場合 --bundle 1.2.3、Capgo はあなたの package.json ファイル(version キー)から bundle バージョンを取得します。

Ionic アプリが Capgo からあるバージョンをインストールすると、そのバージョンが以下の比較対象になります:

  • JavaScript bundle のバージョン (1.2.3) が Capgo の bundle バージョン (1.2.4) より低い場合、Capgo はユーザーに bundle を送信します。

ガード条件は次のとおりです:

  • Native bundle のバージョンが Capgo のバージョンより高い場合、 Disable auto downgrade under native その条件が適用されます。
  • Native bundle のバージョンが Capgo のバージョンより MAJOR バージョン分低い場合、 Disable auto upgrade above major その条件が適用されます。

App Store のアップデート

Capacitor の JS アプリを App Store で公開すると、何が起こるかはシンプルです。

ユーザーはストアから新しいバージョンを取得し、デフォルトではアプリ内のローカルアップデートはすべて削除されます。

この挙動を変更するには、設定を行う必要があります resetWhenUpdate 詳細はこちら こちら

他の設定とは異なり、これはクラウド側ではなくアプリ側でのみ変更可能です。

その他の設定

これらの挙動に加えて、deviceIDに紐づいた特定の挙動を設定することもできます。

Capgo では、deviceIDごとに挙動を上書きするように設定できます。

1つのdeviceIDを以下に紐づけられます:

  • 特定のbundleバージョン
  • 特定のchannel

これにより、上記の設定はすべてバイパスされます。

詳細は以下の記事をご覧ください。

Capgo でのバージョンの仕組みに進む

使用している場合 Capgo のバージョニングの仕組み ネイティブプラグインの作業を計画するには、次と連携してください: Capgo プラグインディレクトリ Capgo プラグインディレクトリのプロダクトワークフローについては、 Capgo による Capacitor プラグイン Capgo による Capacitor プラグインの実装詳細については、 プラグインの追加または更新 プラグインの追加または更新に関する実装詳細については、 Ionic Enterprise プラグインの代替案 Ionic Enterprise Plugin Alternatives のプロダクトワークフロー、および Capgo Native Build Capgo Native Builds のプロダクトワークフローについては、

Capacitor アプリ向けの Live Updates

Web レイヤーのバグが本番で発生したら、App Store の審査を何日も待たずに Capgo で修正を配信しましょう。ネイティブの変更は通常の審査フローに残したまま、ユーザーはバックグラウンドでアップデートを受け取れます。

最新のブログ記事

Capgoは、真にプロフェッショナルなモバイルアプリを作るために必要な最高のインサイトを提供します。