次の方法で共有

App Center CLI を使用した CodePush 更新プログラムのリリース

  • [アーティクル]

重要

Visual Studio App Center は、2025 年 3 月 31 日に廃止される予定です。 完全に廃止されるまで Visual Studio App Center を引き続き使用できますが、移行を検討できる推奨される代替手段がいくつかあります。

詳細については、サポートタイムラインと代替手段に関するページを参照してください。

インストール

  • Node.js
  • App Center CLI をインストールします。 npm install -g appcenter-cli

作業の開始

  1. コマンドを使用して 、App Center アカウント を作成するか、CLI を使用して appcenter login サインインします。
  2. CodePush にアプリを登録 し、必要に応じてチームの 他の開発者とアプリを共有します 。
  3. CodePush-ify アプリを使用して、使用するデプロイをポイントします (Apache Cordova と React Native)。
  4. アプリのリリースと更新。

アカウント管理

アプリの更新プログラムのリリースを開始する前に、既存の CodePush アカウントでサインインするか、新しい App Center アカウントを作成します。 これを行うには、CLI をインストールしたら、次のコマンドを実行します。

appcenter login

このコマンドを実行すると、ブラウザーが起動し、GitHub または Microsoft アカウントで認証するように求められます。 認証されると、GitHub/MSA ID に "リンクされた" CodePush アカウントが作成され、CLI にコピー/貼り付けてサインインできるアクセス キーが生成されます。

注意

登録後、CLI を使用して自動的にログインするため、明示的にログアウトするまでは、同じコンピューターから再度サインインする必要はありません。

認証

App Center CLI 内のほとんどのコマンドでは認証が必要であるため、アカウントの管理を開始する前に、登録時に使用した GitHub または Microsoft アカウントを使用してサインインします。 これを行うには、次のコマンドを実行します。

appcenter login

このコマンドを実行すると、GitHub または Microsoft アカウントで認証するように求めるブラウザー ウィンドウが起動します。 CLI にコピーして貼り付けるアクセス キーが生成されます (プロンプトが表示されます)。 これで正常に認証され、ブラウザー ウィンドウを安全に閉じることができます。

既にログインしている場合は、いつでもチェックする必要がある場合は、次のコマンドを実行して、現在の認証セッションの電子メール アドレス、ユーザー名、表示名を表示できます。

appcenter profile list

CLI からサインインすると、アクセス キーはセッションの間ディスクに保持されるため、アカウントにアクセスしようとするたびにサインインする必要はありません。 セッションを終了し、このアクセス キーを削除するには、次のコマンドを実行します。

appcenter logout

実行中のセッション (友人のノート PC など) からサインアウトすることを忘れた場合は、次のコマンドを使用して、現在のログイン セッションを一覧表示および削除できます。

appcenter tokens list
appcenter tokens delete <machineName>

アクセス トークン

ブラウザーを起動せずに、または GitHub または Microsoft の資格情報 (CI 環境など) を使用せずに CodePush サービスに対して認証を行うには、次のコマンドを実行して "アクセス トークン" を作成できます (その目的を説明する名前と共に)。

appcenter tokens create -d "Azure DevOps Integration"

キーは 1 回だけ表示されるため、必要に応じてどこかに保存してください。 新しいキーを作成した後は、 コマンドの login フラグを--token使用してその値を指定できます。これにより、ブラウザーを起動するのではなく、"ヘッドレス" 認証を使用できます。

appcenter login --token <accessToken>

この方法を使用してサインインすると、アクセス トークンはサインアウト時に自動的に無効になりません。また、App Center サーバーから明示的に削除されるまで、今後のセッションで使用できます。 ただし、セッションが完了したら、ディスクから資格情報を削除するためにサインアウトする必要があります。

アプリの管理

更新プログラムをデプロイする前に、次のコマンドを使用して App Center でアプリを作成します。

appcenter apps create -d <appDisplayName> -o <operatingSystem>  -p <platform>

アプリが Android と iOS の両方を対象とする場合は、CodePush を使用して個別のアプリを作成することを強くお勧めします。 プラットフォームごとに 1 つ。 これにより、更新プログラムを個別に管理およびリリースできます。これは、長期的には、物事をより簡単にする傾向があります。 ほとんどのユーザーは、 と -iOSを使用してアプリ名のサフィックスを付-Androidけます。 次に例を示します。

appcenter apps create -d MyApp-Android -o Android -p React-Native
appcenter apps create -d MyApp-iOS -o iOS -p Cordova

注意

Android と iOS 用に同じアプリを使用すると、iOS 用に生成された CodePush 更新プログラム パッケージのコンテンツが Android 用に生成された更新プログラムとは異なるため、インストール例外が発生する可能性があります。

ヒント

App Center CLI の重要な新機能の 1 つは、 を使用してappcenter apps set-current <ownerName>/<appName>アプリを現在のアプリとして設定できることです。 アプリを現在のアプリとして設定することで、他の CLI コマンドで フラグを -a 使用する必要はありません。 たとえば、コマンド appcenter codepush deployment list -a <ownerName>/<appName> は、現在のアプリが設定されている場合に に appcenter codepush deployment list 短縮できます。 を使用してappcenter apps get-current、アカウントの現在のアプリとして設定されているアプリをチェックできます。 現在のアプリを設定すると、ほとんどの CLI コマンドの入力が短くなります。

元の CodePush では、アプリには自動的に 2 つのデプロイ (Staging と Production) がありました。 App Center では、次のコマンドを使用して自分で作成する必要があります。

appcenter codepush deployment add -a <ownerName>/<appName> Staging
appcenter codepush deployment add -a <ownerName>/<appName> Production

デプロイを作成したら、 を使用して両方のデプロイのデプロイ キーにアクセスできます。このキーを使用appcenter codepush deployment list --displayKeysして、それぞれの SDK (Cordova と React Native の詳細) を使用してモバイル クライアントを構成できます。

アプリに指定した名前が気に入らない場合は、次のコマンドを使用していつでも名前を変更できます。

appcenter apps update -n <newName> -a <ownerName>/<appName>

警告

アプリ名を変更すると、ブランチの構成とビルドで約 48 時間にわたって予期しない問題が発生する可能性があります。

ある時点でアプリが不要になった場合は、次のコマンドを使用してサーバーからアプリを削除できます。

appcenter apps delete -a <ownerName>/<appName>

このコマンドを使用するように構成されているアプリは更新プログラムの受信を停止するため、このコマンドを実行する場合は注意が必要です。

最後に、App Center サーバーに登録したすべてのアプリを一覧表示する場合は、次のコマンドを実行します。

appcenter apps list

アプリのコラボレーション

同じ CodePush アプリで他の開発者と作業する場合は、次の一連の手順に従って、App Center ポータルを使用してコラボレーターとして追加できます。

  1. App Center ポータルで、コラボレーターを追加するアプリを選択します
  2. ページの左側のナビゲーション領域で、[設定] をクリックします。
  3. [ コラボレーター ] リンクをクリックします
  4. コラボレーター メニューで、招待するコラボレーターのメール アドレスを入力します。

重要

App Center のコラボレーター機能では、指定した電子メール アドレスを使用して、各コラボレーターが 既に App Center に登録 されていることを想定しています。

追加すると、すべてのコラボレーターは、共有アプリで次のアクセス許可をすぐに持ちます。

  1. アプリ、そのコラボレーター、デプロイ、リリース履歴を表示する
  2. アプリのデプロイのいずれかに対する更新プログラムをリリースする
  3. アプリのデプロイ間で更新プログラムを昇格させる
  4. アプリのデプロイをロールバックする
  5. アプリのデプロイ内のリリースにパッチを適用する

コラボレーターは、次のアクションを実行できません。

  1. アプリの名前を変更または削除する
  2. アプリ内で新しいデプロイを作成、名前変更、または削除する
  3. デプロイのリリース履歴をクリアする
  4. アプリ (*) からコラボレーターを追加または削除する

注意

開発者は、共有されたアプリからコラボレーターとして自分を削除できます。

時間の経過と共に、他のユーザーがアプリで作業しなくなった場合は、ポータルでこのコラボレーター メニューを使用してコラボレーターとして削除することもできます。

アプリに追加されたすべてのコラボレーターを一覧表示する場合は、ポータルのコラボレーター メニューにアクセスできます。

［展開管理］

CodePush の観点からは、アプリは 1 つ以上の "デプロイ" の名前付きグループです。 アプリは、プラットフォーム固有のバージョンのアプリ (たとえば、Foo アプリの iOS ポート) の概念的な "名前空間" または "スコープ" を表しますが、そのデプロイは、更新プログラムのリリース (開発者向け) と更新プログラムの同期 (エンド ユーザー向け) の実際のターゲットを表します。 デプロイを使用すると、実行中のアプリごとに複数の "環境" をいつでも使用でき、最終的に運用環境に移行する前に、アプリが通常開発者の個人用環境からテスト/QA/ステージング環境に移行する現実をモデル化するのに役立ちます。

注意

以下に示すように、 コマンドと コマンドでは、releasepromoteアプリ名とrollbackデプロイ名の両方が機能する必要があります。これは、配布ポイントを一意に識別する 2 つの組み合わせであるためです (たとえば、iOS アプリの更新プログラムをベータ テスト担当者にリリースする必要があります)。

アプリが CodePush サービスに登録されるたびに、 と ProductionのデプロイStagingを作成することをお勧めします。 これにより、内部環境への更新プログラムのリリースを開始できます。この環境では、各更新プログラムをエンド ユーザーにプッシュする前に十分にテストできます。 このワークフローは、リリースが大量消費の準備ができていることを確認するために重要であり、Web で長い間確立されているプラクティスです。

アプリのステージングバージョンと運用バージョンでニーズを満たすのに十分な場合は、他に何もする必要はありません。 ただし、アルファ、開発などのデプロイが必要な場合は、次のコマンドを使用して簡単に作成できます。

appcenter codepush deployment add -a <ownerName>/<appName> <deploymentName>

アプリの場合と同様に、次のコマンドを使用して、デプロイの削除と名前の変更を行うことができます。

appcenter codepush deployment remove -a <ownerName>/<appName> <deploymentName>
appcenter codepush deployment rename -a <ownerName>/<appName> <deploymentName> <newDeploymentName>

特定のアプリに含まれるデプロイの一覧を表示する場合は、いつでも次のコマンドを実行できます。

appcenter codepush deployment list -a <ownerName>/<appName>

インストール メトリックには、次の意味があります。

  • [アクティブ] - このリリースを現在実行している正常なインストールの数 (ユーザーがアプリを開いた場合、このバージョンが表示または実行されます)。 この数は、エンド ユーザーがこのリリースとの間でアップグレードすると変更されます。 このメトリックは、アクティブなユーザーの合計と、全体の対象ユーザーの割合の両方を示します。 これにより、ユーザーが現在実行している更新プログラムの配布を簡単に判断できるほか、"最新の更新プログラムを受け取ったユーザーの数" などの質問に答えることもできます。

  • Total - この更新プログラムが全体的に受け取った正常なインストールの合計数。 この数は、新しいユーザー/デバイスがインストールするにつれて増加するだけなので、常にアクティブな合計数のスーパーセットです。 更新プログラムは、インストール後に 1 回 notifyApplicationReady (または sync) 呼び出されると成功したと見なされます。 更新プログラムがダウンロードされ、正常に完了したとマークされるまでは、"保留中" の更新として報告されます (詳細については、以下を参照してください)。

  • 保留中 - このリリースがダウンロードされたが、まだインストールされていない回数 (変更を適用するためにアプリが再起動されました)。 そのため、このメトリックは更新プログラムがダウンロードされると増加し、対応するダウンロードされた更新プログラムがインストールされると減少します。 このメトリックは主に、すぐにインストールするように構成されていない更新プログラムに適用され、アプリの再開または再起動に依存して更新プログラムを適用するアプリのリリース導入の全体像を提供するのに役立ちます (たとえば、更新プログラムをロールバックしたい場合や、更新プログラムをまだダウンロードしている場合は興味があります)。 更新プログラムをすぐにインストールするように構成していて、まだ保留中の更新プログラムが報告されている場合は、アプリの起動時に (または sync) を呼び出notifyApplicationReadyしていない可能性があります。これは、インストール レポートの送信を開始し、インストールされた更新プログラムを成功と見なすマークを付ける方法です。

  • ロールバック - このリリースがクライアントで自動的にロールバックされた回数。 理想的には、この数値は 0 にする必要があります。その場合、このメトリックは表示されません。 ただし、インストール プロセスの一部としてクラッシュを含む更新プログラムをリリースした場合、CodePush プラグインはエンド ユーザーを以前のリリースにロールバックし、その問題をサーバーに報告します。 これにより、リリースが壊れた場合でもエンド ユーザーのブロックを解除し続けることができ、CLI でこのテレメトリを確認することで、誤ったリリースを特定し、サーバーに ロールバック して応答できます。

  • ロールアウト - この更新プログラムを受け取る資格のあるユーザーの割合を示します。 このプロパティは、"アクティブ" ロールアウトを表すリリースの場合にのみ表示されるため、ロールアウトの割合は 100% 未満です。 さらに、デプロイには一度にアクティブなロールアウトを 1 つだけ含めることができるため、このラベルはデプロイ内の最新リリースにのみ存在します。

  • [無効] - リリースが無効としてマークされているかどうかを示し、エンド ユーザーがダウンロードできるようにします。 このプロパティは、無効になっているリリースに対してのみ表示されます。

メトリック セルが を報告 No installs recordedすると、サーバーにこのリリースのアクティビティが表示されなかったことを示します。 これは、テレメトリサポートを含むプラグインのバージョンを除外したか、エンド ユーザーがまだ CodePush サーバーと同期していないためです。 インストールが行われるとすぐに、リリースの CLI にメトリックが設定されます。

更新のリリース

App Center サーバーに対して更新プログラムのクエリを実行するようにアプリが構成されたら、更新プログラムのリリースを開始できます。 シンプルさと柔軟性の両方を提供するために、App Center CLI には、更新プログラムをリリースするための 3 つの異なるコマンドが含まれています。

  1. [全般 ] - 外部ツールまたはビルド スクリプト (Gulp タスク、コマンドなど) によって生成された App Center サーバーに対する更新プログラムを react-native bundle リリースします。 これは、CodePush 固有の手順を厳密に処理し、アプリ固有のコンパイル プロセスを任せられるため、既存のワークフローに適合するという点で最も柔軟性が高くなります。

  2. React Native - 一般的なリリース コマンドと同じ機能を使用しますが、 と の両方react-native bundleを実行する必要はなく、更新されたアプリコンテンツ (JS バンドルとアセット) を生成するタスクも処理しますappcenter codepush release。

  3. Cordova - 一般的なリリース コマンドと同じ機能を使用しますが、(または phonegap prepare) と の両方cordova prepareを実行する代わりに、アプリの更新プログラムを準備するタスクも処理しますappcenter codepush release。

これらのコマンドのうち、主に要件または優先順位の問題を使用する必要があります。 ただし、関連するプラットフォーム固有のコマンドを使用して開始することをお勧めします (エクスペリエンスが大幅に簡素化されるため)。より大きな制御が必要な場合は汎用 release コマンドを使用します。

注意

クライアントが検出してダウンロードできるのは、展開内の最新のリリース 50 個のみです。

更新の解放 (全般)

appcenter codepush release -a <ownerName>/<appName> -c <updateContentsPath> -t <targetBinaryVersion> -d <deploymentName>

[-t|--target-binary-version <version>]
[-с|--update-contents-path <updateContentsPath>]
[-r|--rollout <rolloutPercentage>]
[--disable-duplicate-release-error]
[-k|--private-key-path <privateKeyPath>]
[-m|--mandatory]
[-x|--disabled]
[--description <description>]
[-d|--deployment-name <deploymentName>]
[-a|--app <ownerName>/<appName>]
[--disable-telemetry]
[-v|--version]

アプリ名パラメーター

このパラメーターは、この更新プログラムがリリースされる App Center アプリの名前を指定します。 検索する場合は、 コマンドを appcenter apps list 実行してアプリの一覧を表示できます。

コンテンツ パラメーターを更新する

このパラメーターは、リリースする更新されたアプリ コードと資産の場所を指定します。 1 つのファイル (React Native アプリの JS バンドルなど) またはディレクトリへのパス (Cordova アプリのフォルダーなど/platforms/ios/www) を指定できます。 これらの変更をデプロイするために複数のファイルまたはディレクトリを ZIP 化する必要はありません。CLI によって自動的に ZIP が適用されるためです。

指定するパスは、プラットフォーム固有の準備済み/バンドルバージョンのアプリを参照することが重要です。 次の表は、解放する前に実行するコマンドと、 パラメーターを使用して後で参照できる場所の概要を updateContentsPath 示しています。

プラットフォーム Prepare コマンド パッケージ パス (プロジェクト ルートに対する相対パス)
Cordova (Android) cordova prepare android ./platforms/android/assets/www ディレクトリ
Cordova (iOS) cordova prepare ios ./platforms/ios/www ディレクトリ
React Native wo/assets (Android) react-native bundle --platform android --entry-file <entryFile> --bundle-output <bundleOutput> --dev false オプションの --bundle-output 値。
アセット付きReact Native (Android) react-native bundle --platform android --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false オプションの --assets-dest 値。アプリの資産と JS バンドルを含む新しく作成されたディレクトリを表す必要があります
React Native wo/assets (iOS) react-native bundle --platform ios --entry-file <entryFile> --bundle-output <bundleOutput> --dev false オプションの --bundle-output 値
アセット付きReact Native (iOS) react-native bundle --platform ios --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false オプションの --assets-dest 値。アプリの資産と JS バンドルを含む新しく作成されたディレクトリを表す必要があります

ターゲット バイナリ バージョン パラメーター

このパラメーターは、更新プログラムをリリースするアプリケーションのストア/バイナリ バージョンを指定します。そのため、そのバージョンを実行しているユーザーのみが更新プログラムを受け取りますが、古いバージョンまたは新しいバージョンのアプリ バイナリを実行しているユーザーは更新プログラムを受け取りません。 これは、次の理由で役立ちます。

  1. ユーザーが古いバイナリ バージョンを実行している場合、CodePush 更新プログラムに、実行されているものと互換性のない破壊的変更が発生している可能性があります。

  2. ユーザーが新しいバイナリ バージョンを実行している場合は、実行しているものが CodePush 更新プログラムとより新しい (および互換性がない可能性がある) と推定されます。

アプリ ストア バイナリの複数のバージョンを対象とする更新プログラムが必要な場合は、 パラメーターを semver 範囲式として指定することもできます。 このようにして、範囲式 (semver.satisfies(version, range) を返します true) を満たすバイナリのバージョンを実行しているクライアント デバイスは、更新プログラムを取得します。 有効な semver 範囲式の例を次に示します。

範囲式 更新プログラムを取得するユーザー
1.2.3 アプリの特定のバイナリ バージョン 1.2.3 を実行しているデバイスのみ
* CodePush アプリからの更新プログラムを使用するように構成されているデバイス
1.2.x メジャー バージョン 1、マイナー バージョン 2、およびアプリのパッチ バージョンを実行しているデバイス
1.2.3 - 1.2.7 (包括的) と (包括的) の間 1.2.3 で任意のバイナリ バージョンを 1.2.7 実行しているデバイス
>=1.2.3 <1.2.7 (包括的) と (排他的) の間 1.2.3 で任意のバイナリ バージョンを 1.2.7 実行しているデバイス
1.2 >=1.2.0 <1.3.0 と同じ意味です。
~1.2.3 >=1.2.3 <1.3.0 と同じ意味です。
^1.2.3 >=1.2.3 <2.0.0 と同じ意味です。

注意

アプリの semver 式が 、、または ** * などの>^特殊なシェル文字または演算子で始まる場合、シェルが CLI プロセスに適切な値を提供しないため、値を引用符で囲まないと、コマンドが正しく実行されないことがあります。 そのため、 コマンドを呼び出すときは、アプリの targetBinaryVersion パラメーターを二重引用符で囲むのが release 最善です。たとえば、 appcenter codepush release -a <ownerName>/<appName> updateContents ">1.2.3"です。

次の表は、CodePush がそれぞれのアプリの種類ごとに更新プログラムの semver 範囲を満たすことが想定されるバージョン値の概要を示しています。

プラットフォーム バイナリ バージョンのソース
Cordova <widget version>config.xml ファイル内の 属性
React Native (Android) android.defaultConfig.versionNameプロジェクトの build.gradle ファイルの プロパティ
React Native (iOS) CFBundleShortVersionStringInfo.plist ファイル内のキー
React Native (Windows) <Identity Version>Package.appxmanifest ファイル内のキー

注意

メタデータ ファイル内のバイナリ バージョンにパッチ バージョンがない場合 (たとえば、 など) は、 2.0パッチ バージョン 0(つまり 2.0 -> 2.0.0) を持つものとして扱われます。

デプロイ名パラメーター

このパラメーターは、更新プログラムをリリースする展開を指定します。 既定値は Stagingですが、 または独自のカスタム デプロイのいずれかにデプロイする Production準備ができたら、この引数を明示的に設定するだけです。

ヒント

パラメーターは、 または -dを--deployment-name使用して設定できます。

Description パラメーター

このパラメーターは、デプロイのオプションの "変更ログ" を提供します。 値はクライアントに丸め込まれるので、更新プログラムが検出されると、アプリはエンド ユーザーに表示することを選択できます (たとえば、[新機能] ダイアログを使用)。 この文字列は、 や などの\n\t制御文字を受け入れるため、説明内に空白の書式設定を含めて読みやすくすることができます。

ヒント

このパラメーターは、 を使用して --description設定できます。

Disabled パラメーター

このパラメーターは、エンド ユーザーが更新プログラムをダウンロードできるかどうかを指定します。 指定しない場合、更新プログラムは無効になりません。 代わりに、アプリが を呼び出 syncした瞬間にユーザーがダウンロードします。 このパラメーターは、明示的に 修正 プログラムを適用し、エンド ユーザーにダウンロードさせるまで、すぐに使用できない更新プログラムをリリースする場合に便利です (たとえば、お知らせブログの投稿が公開されました)。

ヒント

このパラメーターは、 または -xを--disabled使用して設定できます。

必須パラメーター

このパラメーターは、更新プログラムを必須と見なす必要があるかどうかを指定します (たとえば、重要なセキュリティ修正プログラムが含まれます)。 この属性は、クライアントに丸め込まれており、その属性を適用するかどうかとその方法を決定できます。

注意

このパラメーターは "フラグ" であるため、その存在はリリースが省略可能であることを示し、その存在は必須であることを示します。 値 (例: ) を指定できますが、 --mandatory trueリリースを必須としてマークするには、 を --mandatory 指定するだけで十分です。

必須属性は一意です。これは、エンド ユーザーに対してアプリのリリースのセマンティクスが維持されるように、サーバーが必要に応じて動的に変更するためです。 たとえば、次の 3 つの更新プログラムをアプリにリリースしたとします。

リリース 必須
v1 いいえ
v2 はい
v3 いいえ

エンド ユーザーが現在 を実行 v1していて、サーバーに更新プログラムのクエリを実行している場合は、 で v3 応答しますが (最新であるため)、その間に必須の更新プログラムがリリースされたため、リリースは動的に必須に変換されます。 に含まれるコードは に含まれるv2ものv3に増分されるため、この動作は重要です。 必須にしたものv2は、まだ を取得v2していないすべてのユーザーに対して引き続き必須を行v3います。

エンド ユーザーが現在 を実行 v2していて、サーバーに更新プログラムのクエリを実行している場合は、 で v3応答しますが、リリースは省略可能のままにします。 これは、必須の更新プログラムを既に受信しているためです。そのため、 の v3ポリシーを変更する必要はありません。 この動作は、サーバーが必須フラグを "動的に変換" する理由です。これは、リリースに関する限り、その必須属性は、リリース時に指定した値を使用して常に格納されるためです。 エンド ユーザーから更新プログラムのチェックに応答する場合にのみ、必要に応じてオンザフライで変更されます。

説明されている動作は、 として mandatoryマークされた更新プログラムをリリースする場合にのみ適用されます。 サーバーは、上記のように、混在する更新がある場合にのみ、リリースmandatoryを mandatory に変更optionalします。

として mandatory マークされたリリースは、 に optional変換されません。

ヒント

このパラメーターは、 または を --mandatory 使用して設定できます。 -m*

重複するリリース エラー パラメーターがない

このパラメーターは、更新プログラムがデプロイの最新リリースと同じ場合、CLI でエラーではなく警告を生成するように指定します。 これは、運用環境のコードが変更されていないリリースを小さな変更によってトリガーすることが予想される継続的インテグレーション シナリオに役立ちます。

ロールアウト パラメーター

重要

このパラメーターを有効にするには、エンド ユーザーが CodePush プラグインのバージョン 1.6.0-beta+ (Cordova の場合) または 1.9.0-beta+ (React Native用) を実行している必要があります。 ロールアウト プロパティを指定する更新プログラムをリリースした場合、古いバージョンの Cordova または React Native プラグインを実行しているエンド ユーザーは更新プログラムの対象になりません。 プラットフォーム固有の CodePush プラグインの必要なバージョン (前述のとおり) を採用するまでは、アプリのリリースでロールアウト値を設定することはお勧めしません。これは、誰も受け取らなくなるためです。

このパラメーターは、この更新プログラムを受け取る資格があるユーザーの割合 (と 100の間1の整数) を指定します。 アプリの対象ユーザーの一部 (25%) を使用して新しいリリースを "フライト" し、例外やクラッシュに関するフィードバックやwatchを受け取ってから、全員が幅広く利用できるようにする場合に役立ちます。 このパラメーターが設定されていない場合、既定値は になります 100%。 これを設定して、受信するユーザーの数を制限するだけで済みます。

ロールアウト機能を使用する場合は、いくつかの考慮事項に留意する必要があります。

  1. 最新リリースが "アクティブ" ロールアウトであるデプロイに新しい更新プログラムをリリースすることはできません (そのロールアウト プロパティは null 以外です)。 展開をさらに更新する前に、ロールアウトを "完了" (プロパティを rollout に 100設定) する必要があります。

  2. 最新のリリースが "アクティブ" なロールアウトであるデプロイをロールバックすると、ロールアウトの値がクリアされ、ロールアウトの動作が実質的に "非アクティブ化" されます

  3. mandatoryフィールドと description フィールドとは異なり、あるデプロイから別のデプロイにリリースを昇格してもプロパティは反映rolloutされません。そのため、新しいリリース (ターゲット デプロイ内) にロールアウト値を設定する場合は、コマンドを呼び出promoteすときに明示的に設定する必要があります。

ヒント

このパラメーターは、 または を --rollout 使用して設定できます。 -r*

更新の解放 (React Native)

appcenter codepush release-react -a <ownerName>/<appName> -d <deploymentName> -t <targetBinaryVersion>
[-t|--target-binary-version <targetBinaryVersion>]
[-o|--output-dir]
[-s|--sourcemap-output]
[-c|--build-configuration-name <arg>]
[--plist-file-prefix]
[-p|--plist-file]
[-g|--gradle-file]
[-e|--entry-file]
[--development]
[-b|--bundle-name <bundleName>]
[-r|--rollout <rolloutPercentage>]
[--disable-duplicate-release-error]
[-k|--private-key-path <privateKeyPath>]
[-m|--mandatory]
[-x|--disabled]
[--description <description>]
[-d|--deployment-name <deploymentName>]
[-a|--app <ownerName>/<appName>]
[--disable-telemetry]
[-v|--version]

コマンドはrelease-reactReact Native固有のバージョンの "vanilla" release コマンドであり、同じパラメーター (たとえば、 など) をすべてサポートしますが、--mandatory--description次の追加タスクを実行して更新プログラムをリリースするプロセスを簡略化します。

  1. コマンドを react-native bundle 実行して、CodePush サーバーにリリースされる 更新内容 (JS バンドルとアセット) を生成します。 可能な限り適切な既定値が使用されますが (たとえば、開発以外のビルドを作成する場合、iOS エントリ ファイルの名前が index.ios.jsであると仮定します)、--sourcemap-output柔軟性を実現するために関連react-native bundleするパラメーターも公開します (例: )。

  2. プロジェクトの Info.plist (iOS の場合) ファイルと build.gradle (Android の場合) ファイルで指定されているバージョン名を使用して、このリリースの を推論targetBinaryVersionします。

コマンドの違いをrelease-react示すために、次の例は、"vanilla" release コマンドを使用してReact Native アプリの更新プログラムを生成してリリースする方法を示しています。

mkdir ./CodePush

react-native bundle --platform ios \
--entry-file index.ios.js \
--bundle-output ./CodePush/main.jsbundle \
--assets-dest ./CodePush \
--dev false

appcenter codepush release -a <ownerName>/MyApp-iOS -c ./CodePush -t 1.0.0

コマンドで同等の動作を release-react 実現するには、次のコマンドが必要になります。これは、エラーが発生しにくいです。

appcenter codepush release-react -a <ownerName>/MyApp-iOS

アプリ名パラメーター

これは、上記のセクションで説明したパラメーターと同じパラメーターです。

デプロイ名パラメーター

これは、上記のセクションで説明したパラメーターと同じパラメーターです。

Description パラメーター

これは、上記のセクションで説明したパラメーターと同じパラメーターです。

必須パラメーター

これは、上記のセクションで説明したパラメーターと同じパラメーターです。

重複するリリース エラー パラメーターがない

これは、上記のセクションで説明したパラメーターと同じパラメーターです。

ロールアウト パラメーター

これは、上記のセクションで説明したパラメーターと同じパラメーターです。 指定しない場合、リリースはすべてのユーザーが利用できるようになります。

ターゲット バイナリ バージョン パラメーター

これは、上記のセクションで説明したパラメーターと同じパラメーターです。 指定しない場合、既定では、アプリの Info.plist (iOS の場合) ファイルと build.gradle (Android 用) ファイルで指定された正確なバージョンが対象になります。

バンドル名パラメーター

このパラメーターは、生成された JS バンドルに使用する必要があるファイル名を指定します。 指定しない場合、標準バンドル名は、指定したプラットフォーム (メイン.jsbundle (iOS)、index.android.bundle (Android)、index.windows.bundle (Windows) に使用されます。

ヒント

このパラメーターは、 または を --bundle-name 使用して設定できます。 -b*

開発パラメーター

このパラメーターは、未確定の開発 JS バンドルを生成するかどうかを指定します。 指定しない場合は、既定で false 警告が無効になり、バンドルが縮小されます。

ヒント

このパラメーターは、 を使用して設定できます。 --development*

Disabled パラメーター

これは、上記のセクションで説明したパラメーターと同じパラメーターです。

エントリ ファイル パラメーター

このパラメーターは、アプリのルート/エントリ JavaScript ファイルへの相対パスを指定します。 指定しない場合は、既定で index.ios.js (iOS の場合)、 index.android.js (Android の場合)、 index.windows.bundle (Windows の場合) に設定されます (そのファイルが存在する場合は )。それ以外 の場合はindex.js 。

ヒント

このパラメーターは、 または を --entry-file 使用して設定できます。 -e*

Gradle ファイル パラメーター (Android のみ)

このパラメーターは、リリースのターゲット バイナリ バージョンを自動検出しようとしたときに CLI が使用する build.gradle ファイルへの相対パスを指定します。 CLI はプロジェクトの build.gradle ファイルを "standard" React Native プロジェクトで自動的に検索できるため、このパラメーターは高度なシナリオのみを対象としています。 ただし、プロジェクトの gradle ファイルが任意の場所にあり、CLI で検出できない場合、このパラメーターを使用すると、パラメーターを明示的に設定しなくても CodePush 更新プログラムのリリースを --target-binary-version 続行できます。 build.gradle は必須のファイル名であるため、含まれているフォルダーへのパスまたはファイル自体への完全なパスを指定すると、両方とも同じ効果が得られます。

appcenter codepush release-react -a <ownerName>/MyApp-Android  -g "./foo/bar/"
appcenter codepush release-react -a <ownerName>/MyApp-Android  -g "./foo/bar/build.gradle"

ヒント

このパラメーターは、 または を --gradle-file 使用して設定できます。 -g*

Plist ファイル パラメーター (iOS のみ)

このパラメーターは、リリースのターゲット バイナリ バージョンを自動検出しようとしたときに CLI が使用する Info.plist ファイルへの相対パスを指定します。 CLI はプロジェクトの Info.plist ファイルを "standard" React Native プロジェクトで自動的に検索でき、 パラメーターを使用--plistFilePrefixして環境ごとの plist ファイル (STAGING-Info.plist など) をサポートできるため、このパラメーターは高度なシナリオのみを対象としています。 ただし、プロジェクトの plist が任意の場所にあり、CLI で検出できない場合は、このパラメーターを使用すると、パラメーターを明示的に設定 --target-binary-version しなくても CodePush 更新プログラムを引き続きリリースできます。

appcenter codepush release-react -a <ownerName>/MyApp-iOS -p "./foo/bar/MyFile.plist"

ヒント

このパラメーターは、 または を --plist-file 使用して設定できます。 -p*

Plist ファイル プレフィックス パラメーター (iOS のみ)

このパラメーターは、リリースのターゲット バイナリ バージョンを自動検出しようとしたときに CLI で使用する Info.plist ファイルのファイル名プレフィックスを指定します。 これは、環境ごとの plist ファイル ( DEV-Info.plist、 STAGING-Info.plist など) を作成し、パラメーターを明示的に設定 --target-binary-version せずに CodePush 更新プログラムをリリースする場合に便利です。 を--plist-file-prefix指定すると、CLI は Info.plist (既定の動作) ではなく、 という名前<prefix>-Info.plistのファイルを、 と ./ios/<appName>の場所./iosで検索します。 プロジェクトの plist ファイルがどちらのディレクトリにも存在しない場合 (たとえば、アプリは RN ビューが埋め込まれたネイティブ iOS アプリです)、またはまったく異なるファイルの名前付け規則を使用している場合は、 パラメーターの使用を --plist-file 検討してください。

# Autodetect the target binary version of this release by looking up the
# app version within the STAGING-Info.plist file in either the ./ios or ./ios/<APP> directories.
appcenter codepush release-react -a <ownerName>/MyApp-iOS  --plist-file-prefix "STAGING"

# Tell the CLI to use your dev plist (`DEV-Info.plist`).
# The hyphen separator can be explicitly stated.
appcenter codepush release-react -a <ownerName>/MyApp-iOS --plist-file-prefix "DEV-"

ソース マップ出力パラメーター

このパラメーターは、生成された JS バンドルのソース マップ ファイルを書き込む相対パスを指定します。 指定しない場合、ソース マップは生成されません。

ヒント

このパラメーターは、 または を --sourcemap-output 使用して設定できます。 -s*

ビルド構成名

このリリースを対象とするバイナリ バージョンを指定するビルド構成の名前。 たとえば、"Debug" や "Release" (iOS のみ) などです。

注意

このパラメーターは、Xcode 11 以降でビルドするときに使用して、Xcode で使用される既定の構成をオーバーライドする必要があります。

更新のリリース (Cordova)

appcenter codepush release-cordova -a <ownerName>/<appName> -d <deploymentName> -t <targetBinaryVersion>
[-t|--target-binary-version <targetBinaryVersion>]
[--is-release-build-type]
[-b|--build]
[-r|--rollout <rolloutPercentage>]
[--disable-duplicate-release-error]
[-k|--private-key-path <privateKeyPath>]
[-m|--mandatory]
[-x|--disabled]
[--description <description>]
[-d|--deployment-name <deploymentName>]
[-a|--app <ownerName>/<appName>]
[--disable-telemetry]
[-v|--version]

コマンドは release-cordova Cordova 固有のバージョンの "vanilla" release コマンドであり、同じパラメーター (例: ) をすべてサポートしますが、--mandatory--description次の追加タスクを実行して更新プログラムをリリースするプロセスを簡略化します。

  1. (または phonegap prepare) コマンドをcordova prepare実行して、CodePush サーバーにリリースされる更新内容 (www フォルダー) を生成します。

  2. プロジェクトの config.xml ファイルで指定されているバージョン名を使用して、このリリースの を推論targetBinaryVersionします。

コマンドが実行できる違いを release-cordova 示すために、次の例では、"vanilla" release コマンドを使用して Cordova アプリの更新プログラムを生成およびリリースする方法を示しています。

cordova prepare ios
appcenter codepush release -a <ownerName>/MyApp-iOS -c ./platforms/ios/www -t 1.0.0

コマンドで同等の動作を release-cordova 実現するには、次のコマンドが必要になります。これはエラーが発生しにくいです。

appcenter codepush release-cordova -a <ownerName>/MyApp-iOS

アプリ名パラメーター

これは、上記のセクションで説明したものと同じパラメーターです。

デプロイ名パラメーター

これは、上記のセクションで説明したものと同じパラメーターです。

Description パラメーター

これは、上記のセクションで説明したものと同じパラメーターです。

必須パラメーター

これは、上記のセクションで説明したものと同じパラメーターです。

重複するリリース エラー パラメーターなし

これは、上記のセクションで説明したものと同じパラメーターです。

ロールアウト パラメーター

これは、上記のセクションで説明したものと同じパラメーターです。 指定しない場合、リリースはすべてのユーザーが使用できるようになります。

ターゲット バイナリ バージョン パラメーター

これは、上記のセクションで説明したものと同じパラメーターです。 指定しない場合、コマンドは既定でプロジェクトのメタデータ内の指定されたバージョンのみを対象とします (この更新プログラムが iOS クライアント用の場合は Info.plist 、Android クライアントの場合は build.gradle )。

無効なパラメーター

これは、上記のセクションで説明したものと同じパラメーターです。

ビルド パラメーター

このパラメーターは、更新された Web 資産を生成するときに、 cordova prepare ではなく (既定の動作) を実行cordova buildするかどうかを指定します。 プロジェクトにビルド フックの前後 (TypeScript のトランスパイルなど) が含まれている場合に役立ちます。そのため、CodePush を実行 cordova prepare するだけでは更新プログラムを作成してリリースできません。 未指定のままにした場合、既定値は になります false。

ヒント

このパラメーターは、 または を --build 使用して設定できます。 -b*

更新プログラムメタデータの修正プログラムの適用

更新プログラムをリリースした後、1 つ以上のメタデータ属性を変更するシナリオが存在する場合があります (たとえば、重要なバグ修正を必須としてマークするのを忘れた場合、更新プログラムのロールアウトの割合を増やす必要があります)。 これを簡単に行うには、次のコマンドを実行します。

appcenter codepush patch -a <ownerName>/<appName> <deploymentName> <existing-release-label>
[-r|--rollout <rolloutPercentage>]
[-d|--description <description>]
[-t|--target-binary-version <targetBinaryVersion>]
[-a|--app <ownerName>/<appName>]
[--disable-telemetry]
[-v|--version]

注意

このコマンドでは、リリースの実際の更新内容 (Cordova アプリのフォルダーなど www ) を変更することはできません。 壊れていると特定されたリリースに応答する場合は、 rollback コマンドを使用してすぐにロールバックし、必要に応じて、使用可能な場合は適切な修正プログラムを使用して新しい更新プログラムをリリースする必要があります。

<ownerName>/<appName>と deploymentName以外では、すべてのパラメーターは省略可能であるため、このコマンドを使用して、1 つの属性またはそのすべてを一度に更新できます。 属性フラグを patch 指定せずに コマンドを呼び出すと、no-op になります。

# Mark the latest production release as mandatory
appcenter codepush patch -a <ownerName>/MyApp-iOS Production -m

# Increase the rollout for v23 to 50%
appcenter codepush patch -a <ownerName>/MyApp-iOS Production v23 -rollout 50%

Label パラメーター

指定した展開内で更新するリリース (例: v23) を示します。 省略した場合、要求された変更は、指定したデプロイの最新リリースに適用されます。 更新するリリースのラベルを検索するには、 コマンドを appcenter codepush deployment history 実行して列を Label 参照します。

必須パラメーター

これは、上記のセクションで説明したものと同じパラメーターであり、リリースを必須と見なすかどうかを更新できます。 と --mandatory true は同等ですが--mandatory、このフラグがない場合は と同じ--mandatory falseではありません。 パラメーターを省略した場合、ターゲット リリースの必須プロパティの値は変更されません。 リリースを --mandatory false 省略可能にするには、このパラメーターを に設定します。

Description パラメーター

これは、上記のセクションで説明したものと同じパラメーターであり、リリースの説明を更新できます (たとえば、リリース時に入力ミスを行った場合や、説明を追加するのを忘れた場合など)。 このパラメーターを省略した場合、ターゲット リリースの description プロパティの値は変更されません。

無効なパラメーター

これは、上記のセクションで説明したものと同じパラメーターであり、リリースを無効にするかどうかを更新できます。 と --disabled--disabled true は同等ですが、このフラグがない場合は と同じ --disabled falseではありません。 パラメーターを省略した場合、ターゲット リリースの disabled プロパティの値は変更されません。 このパラメーターを に --disabled false 設定すると、リリースが以前に無効になっていた場合に明示的に有効になります。

ロールアウト パラメーター

これは、上記のセクションで説明したものと同じパラメーターであり、ターゲット リリースのロールアウトの割合を増やすことができます。 このパラメーターは、現在のロールアウト値より大きい値を持つ整数にのみ設定できます。 さらに、ロールアウトを "完了" し、リリースをすべてのユーザーが使用できるようにする場合は、このパラメーターを に --rollout 100設定できます。 このパラメーターを省略した場合、ターゲット リリースのロールアウト パラメーターの値は変更されません。

さらに、前述のように、ロールアウト値なしで更新プログラムをリリースすると、ロールアウトを に 100設定するのと同じように扱われます。 ロールアウトなしで更新プログラムをリリースした場合、ロールアウトの割合を下げると見なされるため、コマンドを patch 使用してその更新プログラムのロールアウト プロパティを変更することはできません。

ターゲット バイナリ バージョン パラメーター

これは上記のセクションで説明したものと同じパラメーターであり、リリースと互換性のあるバイナリ バージョンを示す semver 範囲を更新できます。 これは、最初に更新プログラムをリリースするときに間違えた場合 (たとえば、指定した 1.0.0 が意図 1.1.0した場合など)、リリースでサポートされているバージョン範囲を増減する場合 (たとえば、リリースが結局は 1.1.2 機能しない場合など) に役立ちます。 このパラメーターを省略した場合、ターゲット リリースの version プロパティの値は変更されません。

# Add a "max binary version" to an existing release
# by scoping its eligibility to users running >= 1.0.5
appcenter codepush patch -a <ownerName>/MyApp-iOS Staging -t "1.0.0 - 1.0.5"

更新の推進

特定のデプロイ (例: ) に対して更新プログラムをテストし、 Stagingそれを "ダウンストリーム" (開発>ステージング、ステージング運用>など) に昇格させる場合は、次のコマンドを使用して、あるデプロイから別のデプロイにリリースをコピーできます。

appcenter codepush promote -a <ownerName>/<appName> -s <sourceDeploymentName> -d <destDeploymentName>
[-s|--source-deployment-name <sourceDeploymentName>]
[-d|--destination-deployment-name <destDeploymentName>]
[-t|--target-binary-version <targetBinaryVersion>] 
[-r|--rollout <rolloutPercentage>]
[--disable-duplicate-release-error]
[--description <description>]
[-a|--app <ownerName>/<appName>] 
[--disable-telemetry]

コマンドは promote 、移行先デプロイの新しいリリースを作成します。これには、ソースデプロイの最新リリースからの 正確なコードとメタデータ (説明、必須、ターゲット バイナリ バージョン) が含まれます。 コマンドを release 使用して、ある環境から別の環境に更新プログラムを "手動で" 移行することもできますが promote 、コマンドには次の利点があります。

  1. 発行するリリースアセットを再アセンブルしたり、ソースデプロイのリリース用の説明/バイナリバージョンを覚えたりする必要がないため、より迅速です。

  2. 昇格操作を使用すると、ソースデプロイで既にテストした正確なもの (たとえば、 など) が移行先のデプロイでアクティブになるため、StagingProductionエラーが発生しやすくなります。

すべてのユーザーが自動的に作成された Staging 環境とProduction環境を利用し、すべてのリリースを に直接実行しpromote、適切なテストの後に Stagingから Staging にProduction実行することをお勧めします。

Description パラメーター

これは、上記のセクションで説明したパラメーターと同じパラメーターであり、昇格されたリリースに使用される説明をオーバーライドできます。 指定しない場合、新しいリリースは昇格されるリリースから説明を継承します。

Disabled パラメーター

これは上記のセクションで説明したパラメーターと同じパラメーターであり、昇格されたリリースに使用される無効なフラグの値をオーバーライドできます。 指定しない場合、新しいリリースは昇格中のリリースから無効なプロパティを継承します。

必須パラメーター

これは上記のセクションで説明したパラメーターと同じパラメーターであり、昇格されたリリースに使用される必須フラグをオーバーライドできます。 指定しない場合、新しいリリースは昇格するリリースから必須プロパティを継承します。

重複するリリース エラー パラメーターがない

これは、上記のセクションで説明したパラメーターと同じパラメーターです。

ロールアウト パラメーター

これは上記のセクションで説明したパラメーターと同じであり、新しく作成されたリリースをユーザーの一部のみが使用できるようにするかどうかを指定できます。 他のリリース メタデータ パラメーター (たとえば) とは異なり、descriptionrolloutリリースの は昇格の一部として引き継がれ/継承されないため、新しく作成されたリリースをすべてのユーザーが使用できないようにするには、これを明示的に設定する必要があります。

ターゲット バイナリ バージョン パラメーター

これは、上記のセクションで説明したパラメーターと同じパラメーターであり、昇格されたリリースに使用されるターゲット バイナリ バージョンをオーバーライドできます。 指定しない場合、新しいリリースは、昇格するリリースからターゲット バイナリ バージョン プロパティを継承します。

# Promote the release to production and make it
# available to all versions using that deployment
appcenter codepush promote -a <ownerName>/MyApp-iOS -s Staging -d Production -t "*"

ロールバック 更新

デプロイのリリース履歴は不変であるため、リリース後に更新プログラムを削除または削除することはできません。 ただし、壊れている更新プログラムや意図しない機能が含まれている更新プログラムをリリースする場合は、 コマンドを使用して rollback 簡単にロールバックできます。

appcenter codepush rollback <ownerName>/<appName> <deploymentName>
appcenter codepush rollback -a <ownerName>/MyApp-iOS Production

このコマンドを実行すると、最新バージョンより前のバージョン とまったく同じコードとメタデータ を含む、デプロイ用の新しいリリースが作成されます。 たとえば、アプリに次の更新プログラムをリリースしたとします。

リリース 説明 Mandatory
v1 初回リリース! Yes
v2 新機能を追加しました いいえ
v3 バグの修正 Yes

そのデプロイで コマンドをrollback実行した場合は、リリースのv2内容を含む新しいリリース (v4) が作成されます。

リリース 説明 Mandatory
v1 初回リリース! Yes
v2 新機能を追加しました いいえ
v3 バグの修正 Yes
v4 (v3 から v2 へのロールバック) 新機能を追加しました いいえ

既に取得したv3エンド ユーザーは、アプリが更新プログラムのチェックを実行するときに、 に v2 "戻る" ようになります。 さらに、まだ を実行v2していて、 を取得v3したことがないユーザーは、既に最新のリリースを実行しているため、更新プログラムを受け取りません (このため、更新チェックではリリース ラベルに加えてパッケージ ハッシュが使用されます)。

デプロイを前のリリース以外のリリースにロールバックする場合 (例: ->v2)、 v3 省略可能な--target-releaseパラメーターを指定できます。

appcenter codepush rollback -a <ownerName>/MyApp-iOS Production --target-release v34

注意

ロールバックによって生成されたリリースには、コマンドの deployment history 出力に注釈が付き、それらをより簡単に識別できます。

リリース履歴の表示

次のコマンドを使用して、特定のアプリデプロイの最新リリース 50 件の履歴を表示できます。

appcenter codepush deployment history -a <ownerName>/<appName> <deploymentName>

履歴には、各リリースに関するすべての属性 (ラベル、必須など) が表示され、昇格またはロールバック操作のためにリリースが行われたかどうかを示します。

デプロイ履歴

さらに、履歴には各リリースのインストール メトリックが表示されます。 メトリック データの解釈方法の詳細については、上記のコマンドのドキュメントを deployment list 参照してください。

リリース履歴のクリア

次のコマンドを使用して、デプロイのリリース履歴をクリアできます。

appcenter codepush deployment clear -a <ownerName>/<appName> <deploymentName>

このコマンドを実行すると、関連付けられている展開キーを使用して更新プログラムを受信するように構成されたクライアント デバイスは、クリアされた更新プログラムを受信しなくなります。 このコマンドは元に戻すことができないため、運用環境のデプロイでは使用しないでください。

コード署名

紹介

コード署名は、インストール前にクライアント側で後で検証できるバンドルのデジタル署名を作成する方法です。

なぜそれが必要なのですか?

開発者は、出荷するコードが自分が記述したコードであることを知りたいと考えています。 コード署名は、このような保証を提供するための主要なメカニズムであり、中間者攻撃のクラス全体を軽減または排除するのに役立ちます。

それはどのように機能するのでしょうか。

最初に、開発者は非対称キー ペアを生成します。秘密キーは、バンドルの署名に使用されます。バンドル署名検証用の公開キー。 その後、CodePush CLI は、秘密キーを使用して、 コマンド中release-cordovaにバンドルにreleaserelease-react署名します。 公開キーはモバイル アプリケーションに付属しています。 キーの生成と管理を制御することは、開発者の手に渡っています。

リリース コマンドの終了時に、CLI はバンドルのコンテンツ ハッシュを計算し、この値を秘密キーで署名された JWT に配置します。 CodePush プラグインは、バンドルをデバイスにダウンロードすると、JWT を .codepushrelease 含むファイルを確認し、公開キーを使用して JWT 署名を検証します。 検証に失敗した場合、更新プログラムはインストールされません。

この機能を使用するための要件

この機能を使用する予定の場合は、次の手順を実行します。

  1. を含む新しいバイナリ更新プログラムを生成する

    • コード署名をサポートする CodePush プラグインが更新されました
    • 公開キーを使用するようにコード プッシュ SDK を構成する (詳細については、関連する React Native SDK (iOS、Android) または Cordova SDK のセクションを参照してください)

  2. 新しいバイナリ バージョンを対象とし、(または -k) パラメーター値を指定する新しい CodePush 更新プログラムを--private-key-path生成する

SDK/CLI 内でコード署名機能がサポートされているかどうかを確認するには、互換性テーブルを参照してください。

CodePush SDK コード署名がサポートされているバージョン サポートされているプラットフォーム 最小限の CodePush CLI バージョンが必要
react-native-code-push 5.1.0 Android、iOS 2.1.0
cordova-plugin-code-push 1.10.0 Android、iOS 2.1.2

キーの生成

コード署名では、署名のために PEM でエンコードされた RSA キー (証明書以外) がサポートされます。 次に示すように、openssl を使用して生成できます。

# generate private RSA key and write it to private.pem file
openssl genrsa -out private.pem

# export public key from private.pem into public.pem
openssl rsa -pubout -in private.pem -out public.pem

生成されたキーの例:

# public key
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4moC3GsqF7YISFMQ0fnU
0rUF2xhxNqSGx9/GTxCynsQhR3hceroDXj3rAOTxnNkePB27uZfRDHrH3/LLoj9V
k2ghKRtfjDwXa85uDK8slSQDB9ZlD1TLQEJDZpKr1OTXY9VwbgtFaotSXoFmG3MO
RQeALCbrAgDxQ5Q2kJn6rfBuBoszfUz1qZqrlrY74Axerv1/UtTjL8uyF5r00Bxj
kvTveC2Pm5A3kq6QANktgfKWy9Ugs/4ykZF7fxfH+ukJW+iXwLACrdfzhegg/41H
5w06m30h0jqhIBZ3nbj5MN+qVbANHJMjz+fXqXx1Ovr1DfGtdKOku/BTWDxojCl1
iwIDAQAB
-----END PUBLIC KEY-----

# private key
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA4moC3GsqF7YISFMQ0fnU0rUF2xhxNqSGx9/GTxCynsQhR3hc
eroDXj3rAOTxnNkePB27uZfRDHrH3/LLoj9Vk2ghKRtfjDwXa85uDK8slSQDB9Zl
D1TLQEJDZpKr1OTXY9VwbgtFaotSXoFmG3MORQeALCbrAgDxQ5Q2kJn6rfBuBosz
fUz1qZqrlrY74Axerv1/UtTjL8uyF5r00BxjkvTveC2Pm5A3kq6QANktgfKWy9Ug
s/4ykZF7fxfH+ukJW+iXwLACrdfzhegg/41H5w06m30h0jqhIBZ3nbj5MN+qVbAN
HJMjz+fXqXx1Ovr1DfGtdKOku/BTWDxojCl1iwIDAQABAoIBAQCdwf/8VS8fFlbv
DfHKXKlNp5RM9Nrtl/XRjro+nQPYXBBUHClT2gg+wiXcmalAAIhwmscSqhWe/G4I
PMRmaHrYGtYALnKE49nt5AgKDoSh5lW2QExqQkrcm08bSVcxH8J0bWPJSVE0y564
+rCKr8BhmLhWC0f0PXPeAoeCeceRKYX2oDgO8A0yZRSQUdRWiXOiQ4mUQ3IPCmBc
gD1JJNZ5kR4O904PZz5pbgyvN2t5BKOgLKq+x+8Pa8Rb21rFZKMHO8W04oKaRiGs
f4xwOBAWDOfzDKJzT5xepcPyycgjxcuvyKB2g8biWnDGGOTxDgqMX+R4XeP1aISC
h9bzfRoBAoGBAPREuPhIXRJOsIgSWAAiC5vhLZ9wWELWG95eibQm2SfpY4F0sPpE
lNQJ4yzC7J4BiApFzs1yxwwRmgpVd+wF9iMb4NSzaiTM7fju/Xv4aGhBqRXEokGF
v3QxIlbAwBqeL0rJAAadjbUTTO/u6sC80LI3bfPrn/z1hupZQGR559gjAoGBAO1J
xQ2ODVS4dSH2P+Ocd9LiUBPGyV97+MFixh6z1c2Fd3bNuiIhCxkrng45Dq0CkX84
nPUvtYxEQZoFvyB7gAm0SVlLHnJwBiq+Mp9g0UXSy6rZbjhiFkQs1W/W+Z2OIDsC
y+uXZT7No/J9VyjdrWzZJaBImO8/E4NONXWn8M95AoGACH97j+e0lTZ3ncRFm3uT
u9CRrcJSz8BzJ8FSORpA48qS06YjohFQvC+734rIgJa9DN5w22Tq19ik60cd7PAo
KACISd4UC0O147ssxmtV9oqSP1ef7XehuYEcGLiL9mEadBeaEKDalToeqxo8wIfR
GuIiySGhZ0ODdhO00coL7tECgYBargddD70udDNnICj4PbJY5928QQpxr/m3RZz6
3LTHDstBnosUQdZw7wc+3jUqjsG1gZgR5wKVMPx09N8+dZPPoZMqSZfAGelxajAE
UkaHTXBBwUfqyilCMnP6gofv2wGcK4xsYvXxEzslDxtA5b5By5Yic7vmKg+17Sxm
4yAW2QKBgDyEUzXq3Rrm7ZT720pPhuQDDSO0eHe1L1MUjTRsJ96GkIl0iqQCVgK8
A/6rFFTEeVf8L6GNMTwdtnDFz/CqIU+K1X4HLXmUY2suffWVxZ4KYqiEszCbyrdO
puayMcrx2unhKQyDYjUvD8GxHyquA+p52KDke2TkKfDxfzv0WOE1
-----END RSA PRIVATE KEY-----

署名済み更新プログラムのリリース

署名付き更新プログラムをリリースするには、 または コマンドに (または-k) オプションを使用--private-key-pathするreleaserelease-react必要があります。