Выпуск обновлений CodePush с помощью интерфейса командной строки Центра приложений

Статья
07/19/2023

Важно!

Прекращение поддержки Центра приложений Visual Studio запланировано на 31 марта 2025 г. Хотя вы можете продолжать использовать Центр приложений Visual Studio до полного прекращения его использования, существует несколько рекомендуемых вариантов, на которые можно перейти.

Узнайте больше о сроках поддержки и альтернативных вариантах.

Установка

Установите Node.js
Установите интерфейс командной строки Центра приложений: npm install -g appcenter-cli

Приступая к работе

Создайте учетную запись Центра приложений или выполните вход с помощью cli с помощью appcenter login команды .
Зарегистрируйте приложение в CodePush и при необходимости поделитесь своим приложением с другими разработчиками в вашей команде.
CodePush-ify ваше приложение и укажите ему развертывание, которое вы хотите использовать (Apache Cordova и React Native).
Выпуск и обновление приложения.

Управление учетными записями

Прежде чем начать выпуск обновлений приложений, войдите с помощью существующей учетной записи CodePush или создайте новую учетную запись Центра приложений. Это можно сделать, выполнив следующую команду после установки интерфейса командной строки:

appcenter login

Эта команда запустит браузер с запросом на проверку подлинности с помощью учетной записи GitHub или Майкрософт. После проверки подлинности будет создана учетная запись CodePush, связанная с вашим удостоверением GitHub/MSA, и ключ доступа, который можно скопировать или вставить в интерфейс командной строки для входа.

Примечание

После регистрации вы автоматически войдете в систему с помощью интерфейса командной строки, поэтому пока вы не выйдете из системы явным образом, вам не придется снова выполнять вход с того же компьютера.

Аутентификация

Для большинства команд в интерфейсе командной строки Центра приложений требуется проверка подлинности, поэтому, прежде чем вы сможете приступить к управлению учетной записью, выполните вход с помощью учетной записи GitHub или Майкрософт, используемой при регистрации. Это можно сделать, выполнив следующую команду:

appcenter login

Эта команда запустит окно браузера с запросом на проверку подлинности с помощью учетной записи GitHub или Майкрософт. Он создаст ключ доступа для копирования и вставки в интерфейс командной строки (запросит его). Теперь вы успешно прошли проверку подлинности и можете безопасно закрыть окно браузера.

В любое время, когда вы хотите проверка, если вы уже вошли в систему, можно выполнить следующую команду, чтобы отобразить адрес электронной почты для текущего сеанса проверки подлинности, имя пользователя и отображаемое имя:

appcenter profile list

При входе из интерфейса командной строки ключ доступа сохраняется на диске в течение всего сеанса, поэтому вам не придется выполнять вход при каждой попытке доступа к учетной записи. Чтобы завершить сеанс и удалить этот ключ доступа, выполните следующую команду:

appcenter logout

Если вы забыли выйти из компьютера, на котором вы не хотите покидать сеанс (например, ноутбук вашего друга), вы можете использовать следующие команды для вывода списка и удаления всех текущих сеансов входа.

appcenter tokens list
appcenter tokens delete <machineName>

Маркеры доступа

Чтобы пройти проверку подлинности в службе CodePush без запуска браузера или без использования учетных данных GitHub или Майкрософт (например, в среде CI), можно выполнить следующую команду, чтобы создать "маркер доступа" (вместе с именем, описывающим его предназначение):

appcenter tokens create -d "Azure DevOps Integration"

Ключ будет отображаться только один раз, поэтому не забудьте сохранить его где-нибудь при необходимости! После создания нового ключа его значение можно указать с помощью --token флага команды , который позволяет использовать проверку подлинности без головного login компьютера, а не запускать браузер.

appcenter login --token <accessToken>

При входе с помощью этого метода маркер доступа не будет автоматически считаться недействительным при выходе и может использоваться в будущих сеансах, пока он не будет явно удален с сервера Центра приложений. Однако после завершения сеанса необходимо выполнить выход, чтобы удалить учетные данные с диска.

"App Management" (Управление приложениями).

Перед развертыванием обновлений создайте приложение в Центре приложений с помощью следующей команды:

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

Если ваше приложение предназначено как для Android, так и для iOS, настоятельно рекомендуется создавать отдельные приложения с помощью CodePush. По одному для каждой платформы. Таким образом, вы можете управлять обновлениями и выпускать их отдельно, что в долгосрочной перспективе, как правило, упрощает работу. Большинство пользователей суффикс имя приложения суффиксом -Android и -iOS. Например:

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

Примечание

Использование одного и того же приложения для Android и iOS может привести к исключениям установки, так как пакет обновления CodePush, созданный для iOS, будет иметь содержимое, отличное от содержимого обновления, созданного для Android.

Совет

Одной из важных новых функций в интерфейсе командной строки Центра приложений является возможность задать приложение в качестве текущего приложения с помощью appcenter apps set-current <ownerName>/<appName>. Установив приложение в качестве текущего, вы не должны использовать -a флаг в других командах CLI. Например, команду appcenter codepush deployment list -a <ownerName>/<appName> можно сократить до appcenter codepush deployment list текущего приложения. Вы можете проверка, какое приложение задано в качестве текущего приложения вашей учетной записи, используя appcenter apps get-current. Настройка текущего приложения делает ввод большинства команд CLI короче.

В исходной версии CodePush приложения автоматически имели два развертывания (Staging и Production). В Центре приложений их необходимо создать самостоятельно с помощью следующих команд:

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>

Будьте внимательны при выполнении этой команды, так как все приложения, настроенные для ее использования, перестанут получать обновления.

Наконец, если вы хотите получить список всех приложений, зарегистрированных на сервере Центра приложений, выполните следующую команду:

appcenter apps list

Совместная работа приложений

Если вы будете работать с другими разработчиками в том же приложении CodePush, вы можете добавить их в качестве участников совместной работы на портале Центра приложений, следуя приведенным ниже инструкциям:

На портале Центра приложений выберите приложение, для которого требуется добавить участников совместной работы.
В области навигации в левой части страницы щелкните Параметры.
Щелкните ссылку Участники совместной работы.
В меню участников совместной работы введите адреса электронной почты участников совместной работы, чтобы пригласить их.

Важно!

Функция "Участники совместной работы" в Центре приложений ожидает, что каждый из участников совместной работы уже зарегистрирован в Центре приложений , используя указанный адрес электронной почты.

После добавления все участники совместной работы сразу же получат следующие разрешения в общем приложении:

Просмотр приложения, его участников совместной работы, развертываний и журнала выпусков
Выпуск обновлений для любого развертывания приложения
Повышение уровня обновления между развертываниями приложения
Откат любого развертывания приложения
Исправление всех выпусков в любом из развертываний приложения

Участники совместной работы не могут выполнять следующие действия:

Переименование или удаление приложения
Создание, переименование или удаление новых развертываний в приложении
Очистка журнала выпусков развертывания
Добавление и удаление участников совместной работы из приложения (*)

Примечание

Разработчик может удалить себя в качестве участника совместной работы из приложения, к которому ему был предоставлен общий доступ.

Со временем, если кто-то больше не работает с вами над приложением, вы также можете удалить его как участника совместной работы с помощью этого меню на портале.

Каждый раз, когда вы хотите получить список всех участников совместной работы, добавленных в приложение, вы можете открыть меню участника совместной работы на портале.

Управление развертыванием

С точки зрения CodePush приложение представляет собой именованное группирование для одного или нескольких "развертываний". Хотя приложение представляет собой концептуальное "пространство имен" или "область" для конкретной платформы версии приложения (например, порт iOS приложения Foo), его развертывания представляют собой фактический целевой объект для выпуска обновлений (для разработчиков) и синхронизации обновлений (для конечных пользователей). Развертывания позволяют иметь несколько "сред" для каждого приложения в режиме реального времени в любой момент времени и помогают моделировать реальность, в которой приложения обычно переходят из личной среды разработчика в среду тестирования, контроля качества и промежуточной среды, прежде чем, наконец, перейти в рабочую среду.

Примечание

Как вы увидите ниже, releaseдля работы команд и rollbackpromote требуется как имя приложения, так и имя развертывания, так как именно сочетание этих двух компонентов однозначно определяет точку распространения (например, я хочу выпустить обновление приложения iOS для тестировщиков бета-версии).

Каждый раз, когда приложение регистрируется в службе CodePush, рекомендуется создавать следующие развертывания: Staging и Production. Это позволяет начать выпуск обновлений во внутренней среде, где можно тщательно протестировать каждое обновление, прежде чем отправлять их конечным пользователям. Этот рабочий процесс имеет решающее значение для обеспечения готовности выпусков к массовому использованию и является практикой, которая уже давно используется в Интернете.

Если для удовлетворения ваших потребностей достаточно наличия промежуточной и рабочей версии приложения, вам не нужно ничего делать. Однако если требуется альфа-развертывание, развертывание разработки и т. д., их можно легко создать с помощью следующей команды:

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 — общее количество успешных установок, которые получили это обновление. Это число только увеличивается по мере установки новых пользователей или устройств, поэтому оно всегда является надмножеством общего числа активных пользователей. Обновление считается успешным после того, как notifyApplicationReady (или sync) вызывается после установки. Между моментом загрузки обновления и его пометкой как успешное, оно будет отображаться как "ожидающее" обновление (дополнительные сведения см. ниже).
Ожидание — количество скачанных, но еще не установленных (приложение было перезапущено для применения изменений). Таким образом, эта метрика увеличивается по мере загрузки обновлений и уменьшается по мере установки соответствующих скачанных обновлений. Эта метрика в первую очередь применяется к обновлениям, которые не настроены для немедленной установки, и помогает предоставить более широкую картину внедрения выпуска для приложений, которые используют возобновление или перезапуск приложения для применения обновления (например, я хочу откатить обновление и мне интересно, если кто-то еще загрузил его). Если вы настроили немедленную установку обновлений и по-прежнему видите сообщения об ожидающих обновлениях, скорее всего, вы не вызываете notifyApplicationReady (или sync) при запуске приложения. Это метод, который начинает отправлять отчеты об установке и помечает установленные обновления как успешные.
Откаты — количество автоматически откатов этого выпуска на клиенте. В идеале это число должно быть нулевым, и в этом случае эта метрика даже не отображается. Однако если вы выпустили обновление, которое включает в себя сбой в процессе установки, подключаемый модуль CodePush откатит пользователя к предыдущему выпуску и сообщит об этой проблеме на сервер. Это позволяет конечным пользователям оставаться заблокированными, если выпуски не работают, и, просмотрев эти данные телеметрии в CLI, можно выявить ошибочные выпуски и отреагировать на них, откатив их на сервере.
Развертывание — указывает процент пользователей, имеющих право на получение этого обновления. Это свойство будет отображаться только для выпусков, которые представляют собой "активный" выпуск и, таким образом, имеют процент выпуска, который меньше 100 %. Кроме того, так как развертывание может иметь только один активный выпуск в любой момент времени, эта метка будет присутствовать только в последнем выпуске в развертывании.
Disabled — указывает, был ли выпуск помечен как отключенный или нет, и поэтому доступен для скачивания конечными пользователями. Это свойство будет отображаться только для отключенных выпусков.

Если ячейка метрик сообщает , No installs recordedэто означает, что сервер не видел никаких действий для этого выпуска. Это может быть связано с тем, что это исключает версии подключаемых модулей, которые включали поддержку телеметрии, или конечные пользователи еще не синхронизировались с сервером CodePush. Как только произойдет установка, вы начнете видеть метрики, заполненные в CLI для выпуска.

Выпуск Обновления

После настройки приложения для запроса обновлений на сервере Центра приложений можно начать выпуск обновлений для него. Чтобы обеспечить простоту и гибкость, интерфейс командной строки Центра приложений включает три различные команды для выпуска обновлений:

Общие — выпускает обновление для сервера Центра приложений, созданное внешним средством или скриптом сборки (например, задачей Gulp, командой react-native bundle ). Это обеспечивает максимальную гибкость с точки зрения адаптации к существующим рабочим процессам, так как он строго относится к конкретному шагу CodePush и оставляет процесс компиляции для конкретного приложения.
React Native . Использует те же функции, что и команда общего выпуска, но также обрабатывает задачу создания обновленного содержимого приложения (пакет JS и ресурсы) вместо того, чтобы выполнять и то, и другое react-native bundleappcenter codepush release.
Cordova — использует те же функциональные возможности, что и команда общего выпуска, но также обрабатывает задачу подготовки обновления приложения вместо того, чтобы выполнять оба cordova prepare (или phonegap 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]

Параметр имени приложения

Этот параметр указывает имя приложения Центра приложений, для которых выпускается это обновление. Если вы хотите найти его, выполните appcenter apps list команду , чтобы просмотреть список приложений.

Обновление параметра содержимого

Этот параметр указывает расположение обновленного кода приложения и ресурсов, которые вы хотите выпустить. Можно указать один файл (например, пакет JS для приложения React Native) или путь к каталогу (например, /platforms/ios/www папка для приложения Cordova). Для развертывания этих изменений не нужно архивировать несколько файлов или каталогов, так как CLI автоматически запакует их.

Важно, чтобы указанный путь относится к конкретной платформе, подготовленной или упаковаемой версии приложения. В следующей таблице показано, какую команду следует выполнить перед выпуском, а также расположение, на которое можно будет ссылаться с помощью updateContentsPath параметра .

Платформа	Команда Подготовки	Путь к пакету (относительно корневого каталога проекта)
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.

Параметр целевой двоичной версии

Этот параметр указывает хранилище или двоичную версию приложения, для которых вы выпускаете обновление, чтобы только пользователи, использующие эту версию, получали обновление, а пользователи, использующие более старую или более новую версию двоичного файла приложения, — нет. Это полезно по следующим причинам:

Если пользователь использует более старую двоичную версию, возможно, в обновлении CodePush есть критические изменения, которые будут несовместимы с выполняемыми.
Если пользователь использует более новую двоичную версию, предполагается, что он работает новее (и потенциально несовместимо) с обновлением 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. Поэтому при вызове release команды рекомендуется заключать параметр приложения targetBinaryVersion в двойные кавычки, например 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)	Ключ `CFBundleShortVersionString` в файле Info.plist
React Native (Windows)	Ключ `<Identity Version>` в файле Package.appxmanifest

Примечание

Если в двоичной версии в файлах метаданных отсутствует версия исправления, например , 2.0она будет рассматриваться как версия исправления 0, то есть 2.0 -> 2.0.0.

Параметр имени развертывания

Этот параметр указывает, в каком развертывании вы хотите выпустить обновление. По умолчанию используется Stagingзначение , но когда вы будете готовы к развертыванию в Productionили в одном из собственных пользовательских развертываний, просто явно задайте этот аргумент.

Совет

Параметр можно задать с помощью или --deployment-name-d.

Параметр Description

Этот параметр предоставляет необязательный "журнал изменений" для развертывания. Это значение округляется к клиенту, чтобы при обнаружении обновления приложение ранее ранее отображало его для конечного пользователя (например, с помощью диалогового окна "Новые возможности"). Эта строка принимает управляющие символы, такие как \n и \t , чтобы можно было включить форматирование пробелов в описания для улучшения удобочитаемости.

Совет

Этот параметр можно задать с помощью --description.

Отключенный параметр

Этот параметр указывает, должно ли обновление загружаться конечными пользователями. Если этот параметр не указан, обновление не будет отключено. Вместо этого пользователи будут загружать его в тот момент, когда приложение вызывает sync. Этот параметр может быть полезным, если вы хотите выпустить обновление, которое не будет доступно сразу, пока вы не исправите его явным образом и не хотите, чтобы пользователи скачали его (например, объявление в блоге было опубликовано).

Совет

Этот параметр можно задать с помощью или --disabled-x.

Обязательный параметр

Этот параметр указывает, следует ли считать обновление обязательным или нет (например, оно включает критическое исправление безопасности). Этот атрибут является цикличен для клиента, который затем может решить, нужно ли и как его применить.

Примечание

Этот параметр является "флагом", поэтому его отсутствие указывает на то, что выпуск является необязательным, а его наличие указывает на то, что он является обязательным. Для него можно указать значение (например, --mandatory true), однако этого --mandatory достаточно, чтобы пометить выпуск как обязательный.

Обязательный атрибут уникален, так как сервер будет динамически изменять его при необходимости, чтобы обеспечить семантику выпусков приложения для конечных пользователей. Например, представьте, что вы выпустили следующие три обновления для приложения:

Выпуск	Обязательное?
Версия 1	Нет
Версия 2	Да
Версия 3	Нет

Если пользователь в настоящее время использует v1, и он запрашивает у сервера обновление, он ответит v3 (так как это последний), но он динамически преобразует выпуск в обязательный, так как обязательное обновление было выпущено в период между ними. Это важно, так как код, содержащийся в v3 , является добавочным по сравнению с кодом, включенным в v2. Независимо от того, что делается v2 обязательным, продолжает делать v3 обязательным для всех, кто еще не приобрел v2.

Если пользователь в настоящее время использует v2и запрашивает обновление на сервере, он ответит v3, но оставьте выпуск необязательным. Это связано с тем, что они уже получили обязательное обновление и поэтому нет необходимости изменять политику v3. Поэтому мы говорим, что сервер будет "динамически преобразовывать" обязательный флаг, так как в выпуске его обязательный атрибут всегда будет храниться с использованием значения, указанного при его освобождении. Он изменяется только на лету, когда пользователь отвечает на обновление проверка.

Описанное поведение применяется только к вам, если вы выпускаете обновление, помеченное как mandatory. Сервер изменит выпуск mandatory на optional только при наличии взаимосвязанных mandatory обновлений, как показано выше.

Выпуск, помеченный как mandatory , никогда не будет преобразован в optional.

Совет

Этот параметр можно задать с помощью или --mandatory-m*

Нет повторяющегося параметра ошибки выпуска

Этот параметр указывает, что если обновление идентично последнему выпуску развертывания, интерфейс командной строки должен создать предупреждение вместо ошибки. Это полезно для сценариев непрерывной интеграции, в которых ожидается, что небольшие изменения могут активировать выпуски, в которых не был изменен рабочий код.

Параметр развертывания

Важно!

Чтобы этот параметр влил в силу, пользователи должны использовать версию 1.6.0-beta+ (для Cordova) или 1.9.0-beta+ (для React Native) подключаемого модуля CodePush. Если вы выпускаете обновление, указывающее свойство выпуска, пользователь, использующий более старую версию подключаемых модулей Cordova или React Native, не будет иметь права на обновление. Пока вы не примете необходимую версию подключаемого модуля CodePush для конкретной платформы (как упоминалось ранее), мы не рекомендуем устанавливать значение выпуска в выпусках приложения, так как никто не получит его.

Этот параметр указывает процент пользователей (в виде целого числа между 1 и 100), которые должны иметь право на получение этого обновления. Это может быть полезно, если вы хотите "тестировать" новые выпуски с частью аудитории приложения (например, 25 %) и получать отзывы или watch для исключений или сбоев, прежде чем сделать их общедоступной для всех. Если этот параметр не задан, по умолчанию используется значение 100%. Вам нужно только задать его, чтобы ограничить количество пользователей, которые будут получать его.

При использовании возможности развертывания следует учитывать несколько дополнительных аспектов.

Вы не можете выпустить новое обновление для развертывания, последний выпуск которого является "активным" выпуском (его свойство развертывания не равно NULL). Развертывание должно быть "завершено" (присвоить свойству rollout значение 100), прежде чем можно будет выпускать дополнительные обновления для развертывания.
При откате развертывания, последний выпуск которого является "активным", значение развертывания будет очищено, что фактически "деактивирует" поведение развертывания.
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-react представляет собой React Native версию команды vanillarelease, которая поддерживает все те же параметры (например, --mandatory, --description), но упрощает процесс выпуска обновлений, выполняя следующие дополнительные задачи:

react-native bundle Выполните команду , чтобы создать содержимое обновления (пакет JS и ресурсы), которое будет выпущено на сервере CodePush. В нем используются как можно более разумные значения по умолчанию (например, при создании сборки, не являющейся частью разработки, при условии, что начальный файл iOS называется index.ios.js), но также предоставляются соответствующие react-native bundle параметры для обеспечения гибкости (например, --sourcemap-output).
Вывод targetBinaryVersion этого выпуска с помощью имени версии, указанного в файлах Info.plist проекта (для iOS) и build.gradle (для Android).

Чтобы проиллюстрировать разницуrelease-react, которую может сделать команда, в следующем примере показано, как можно создать и выпустить обновление для React Native приложения с помощью команды vanillarelease:

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. Если это не указано, стандартное имя пакета будет использоваться для указанной платформы: main.jsbundle (iOS), index.android.bundle (Android) и index.windows.bundle (Windows).

Совет

Этот параметр можно задать с помощью или --bundle-name-b*

Параметр разработки

Этот параметр указывает, следует ли создавать неуказаемый пакет JS разработки. Если этот параметр не указан, по умолчанию используется false значение , в котором предупреждения отключены, а пакет миниифицируется.

Совет

Этот параметр можно задать с помощью --development*

Отключенный параметр

Это тот же параметр, что и описанный в предыдущем разделе.

Параметр файла записи

Этот параметр указывает относительный путь к корневому или входной файлу JavaScript приложения. Если этот параметр не указан, по умолчанию index.ios.js (для iOS), index.android.js (для Android) или index.windows.bundle (для Windows), если этот файл существует, либо index.jsиное .

Совет

Этот параметр можно задать с помощью или --entry-file-e*

Параметр файла Gradle (только для Android)

Этот параметр задает относительный путь к файлу build.gradle , который cli должен использовать при попытке автоопределения целевой двоичной версии для выпуска. Этот параметр предназначен только для расширенных сценариев, так как CLI может автоматически найти файл build.gradle проекта в "стандартных" 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)

Этот параметр задает относительный путь к файлу Info.plist , который cli должен использовать при попытке автоопределения целевой двоичной версии для выпуска. Этот параметр предназначен только для расширенных сценариев, так как CLI может автоматически находить файл Info.plist проекта в "стандартных" React Native проектах, и вы можете использовать --plistFilePrefix параметр для поддержки plist-файлов для каждой среды (например, STAGING-Info.plist). Однако если plist проекта находится в произвольном расположении, которое cli не может обнаружить, то использование этого параметра позволяет продолжить выпуск обновлений CodePush без необходимости явно задавать --target-binary-version параметр .

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

Совет

Этот параметр можно задать с помощью или --plist-file-p*

Параметр префикса файла Plist (только для iOS)

Этот параметр задает префикс имени файла Info.plist , который интерфейс командной строки должен использовать при попытке автоопределения целевой двоичной версии для выпуска. Это может быть полезно, если вы создали plist-файлы для каждой среды (например, DEV-Info.plist, STAGING-Info.plist) и хотите выпускать обновления CodePush без явного --target-binary-version задания параметра. --plist-file-prefixУказав , CLI будет искать файл с именем <prefix>-Info.plist, а не Info.plist (что является поведением по умолчанию) в следующих расположениях: ./ios и ./ios/<appName>. Если plist-файл проекта не находится ни в один из этих каталогов (например, ваше приложение является собственным приложением iOS с внедренными представлениями RN) или использует совершенно другое соглашение об именовании файлов, рассмотрите --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*

Имя конфигурации сборки

Имя конфигурации сборки, указывающее двоичную версию, в которой вы хотите использовать этот выпуск. Например, "Отладка" или "Выпуск" (только для 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 является версией команды "vanilla" release для Cordova, которая поддерживает все те же параметры (например, , --mandatory--description), но упрощает процесс выпуска обновлений, выполняя следующие дополнительные задачи:

cordova prepare Выполните команду (или phonegap prepare), чтобы создать содержимое обновления (папку www), которое будет выпущено на сервере CodePush.
Вывод targetBinaryVersion этого выпуска с помощью имени версии, указанной в файлеconfig.xml проекта.

Чтобы проиллюстрировать разницу, которую release-cordova может сделать команда, в следующем примере показано, как создать и выпустить обновление для приложения Cordova с помощью команды vanilla release :

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

Это тот же параметр, что и описанный в приведенном выше разделе.

Обязательный параметр

Это тот же параметр, что и описанный в приведенном выше разделе.

Параметр ошибки выпуска не дублируется

Это тот же параметр, что и описанный в приведенном выше разделе.

Параметр развертывания

Это тот же параметр, что и описанный в приведенном выше разделе. Если оставить неуказанным, выпуск будет доступен всем пользователям.

Параметр целевой двоичной версии

Это тот же параметр, что и описанный в приведенном выше разделе. Если этот параметр не указан, команда по умолчанию будет нацелена только на указанную версию в метаданных проекта (Info.plist , если это обновление предназначено для клиентов iOS, и build.gradle для клиентов Android).

Отключенный параметр

Это тот же параметр, что и описанный в приведенном выше разделе.

Параметр сборки

Этот параметр указывает, нужно ли выполнять cordova buildcordova prepare вместо (что является поведением по умолчанию) при создании обновленных веб-ресурсов. Это полезно, если ваш проект включает в себя обработчики до или после сборки (например, для транспилии TypeScript), и поэтому выполнение cordova prepare CodePush недостаточно для создания и выпуска обновления. Если оставить неуказанным, по умолчанию используется значение false.

Совет

Этот параметр можно задать с помощью или --build-b*

Метаданные обновления исправлений

После выпуска обновления могут возникнуть сценарии, в которых требуется изменить один или несколько атрибутов метаданных для него (например, вы забыли пометить исправление критической ошибки как обязательное и увеличить процент выпуска обновления). Это можно легко сделать, выполнив следующую команду:

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]

Примечание

Эта команда не позволяет изменять фактическое содержимое обновления выпуска (например, www папку приложения Cordova). Если вы хотите отреагировать на выпуск, который был определен как неисправный, следует использовать команду отката , чтобы немедленно выполнить откат, а затем при необходимости выпустить новое обновление с соответствующим исправлением, когда оно будет доступно.

<ownerName>/<appName> Помимо и deploymentName, все параметры являются необязательными, поэтому эту команду можно использовать для обновления одного или всех атрибутов одновременно. patch Вызов команды без указания флага атрибута приведет к тому, что операция не будет выполнена.

# 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 и --mandatory true эквивалентны, но отсутствие этого флага не эквивалентно --mandatory false. Если параметр опущен, значение обязательного свойства целевого выпуска не будет изменено. Присвойте этому параметру значение , --mandatory false чтобы явно сделать выпуск необязательным.

Параметр Description

Это тот же параметр, что и в приведенном выше разделе, и позволяет обновить описание выпуска (например, вы сделали опечатку при выпуске или забыли добавить описание). Если этот параметр опущен, значение свойства описания целевого выпуска вноситься не будет.

Отключенный параметр

Это тот же параметр, что и описанный в предыдущем разделе, и позволяет изменить, следует ли отключить выпуск. Обратите внимание --disabled и --disabled true эквивалентны, но отсутствие этого флага не эквивалентно --disabled false. Если параметр опущен, значение отключенного свойства целевого выпуска не будет изменено. Присвойте этому параметру значение --disabled false , чтобы явно сделать выпуск доступным для получения, если он был ранее отключен.

Параметр развертывания

Это тот же параметр, что и описанный в предыдущем разделе, и позволяет увеличить процент выпуска целевого выпуска. Для этого параметра можно задать только целое число, значение которого больше текущего значения выпуска. Кроме того, если вы хотите "завершить" развертывание и сделать выпуск доступным для всех пользователей, можно задать для этого параметра значение --rollout 100. Если этот параметр опущен, значение параметра выпуска целевого выпуска не будет изменено.

Кроме того, как упоминалось выше, при выпуске обновления без значения выпуска оно обрабатывается эквивалентно присвоению выпуску значения 100. Если вы выпустили обновление без выпуска, вы не сможете изменить его свойство выпуска с помощью patch команды , так как это будет считаться снижением процента развертывания.

Параметр целевой двоичной версии

Это тот же параметр, что и в приведенном выше разделе, и позволяет обновить диапазон semver , указывающий, с какими двоичными версиями совместим выпуск. Это может быть полезно, если вы допустили ошибку при первоначальном выпуске обновления (например, вы указали 1.0.0 , но имели в виду 1.1.0) или хотите увеличить или уменьшить диапазон версий, поддерживаемый выпуском (например, вы обнаружили, что выпуск не работает в 1.1.2 конце концов). Если этот параметр опущен, значение свойства версии целевого выпуска не будет изменено.

# 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) и его повышения уровня "нижестоящее" (например, dev-staging>, staging-production>) можно использовать следующую команду, чтобы скопировать выпуск из одного развертывания в другое:

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 команда имеет следующие преимущества:

Это быстрее, так как вам не нужно повторно компилировать ресурсы выпуска, которые вы хотите опубликовать, или запоминать описание или двоичную версию для выпуска исходного развертывания.
Это менее подвержено ошибкам, так как операция повышения гарантирует, что то, что вы уже протестировали в исходном развертывании (например, Staging) станет активным в целевом развертывании (например, Production).

Рекомендуется, чтобы все пользователи пользовались преимуществами автоматически созданных Staging сред и Production и выполняли все выпуски непосредственно в Staging, а затем promote с Staging до Production после соответствующего тестирования.

Параметр Description

Это тот же параметр, что и описанный в предыдущем разделе, и позволяет переопределить описание, которое будет использоваться для повышенного выпуска. Если этот параметр не указан, новый выпуск наследует описание от выпуска, который повышается.

Отключенный параметр

Это тот же параметр, что и описанный в предыдущем разделе, и позволяет переопределить значение отключенного флага, который будет использоваться для повышенного выпуска. Если этот параметр не указан, новый выпуск наследует отключенное свойство от выпуска, который повышается.

Обязательный параметр

Это тот же параметр, который описан в приведенном выше разделе, и позволяет переопределить обязательный флаг, который будет использоваться для повышенного выпуска. Если этот параметр не указан, новый выпуск наследует обязательное свойство от выпуска, который повышается.

Параметр ошибки выпуска не дублируется

Это тот же параметр, что и описанный в приведенном выше разделе.

Параметр развертывания

Это тот же параметр, что и в приведенном выше разделе, и позволяет указать, должен ли созданный выпуск быть доступен только для части пользователей. В отличие от других параметров метаданных выпуска (например, description), rollout выпуск не переносится или не наследуется в рамках повышения, поэтому необходимо явно задать этот параметр, если вы не хотите, чтобы новый выпуск был доступен всем пользователям.

Параметр целевой двоичной версии

Это тот же параметр, что и описанный в предыдущем разделе, и позволяет переопределить целевую двоичную версию, которая будет использоваться для повышенного выпуска. Если это не указано, новый выпуск наследует свойство целевой двоичной версии от выпуска, который повышается.

# 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

При выполнении этой команды создается новый выпуск для развертывания, который содержит тот же код и метаданные , что и версия до последней версии. Например, представьте, что вы выпустили следующие обновления для приложения:

Выпуск	Описание	Обязательный
Версия 1	Первоначальный выпуск!	Да
Версия 2	Добавлена новая функция	Нет
Версия 3	Исправления ошибок	Да

Если вы выполнили rollback команду в этом развертывании, будет создан новый выпуск (v4), который включает содержимое v2 выпуска.

Выпуск	Описание	Обязательный
Версия 1	Первоначальный выпуск!	Да
Версия 2	Добавлена новая функция	Нет
Версия 3	Исправления ошибок	Да
версия 4 (откат с версии 3 до версии 2)	Добавлена новая функция	Нет

Конечные пользователи, которые уже приобрелиv3, теперь будут "перемещены" обратно в v2 , когда приложение выполняет обновление проверка. Кроме того, все пользователи, которые по-прежнему работали под управлением v2и, следовательно, никогда не получали v3обновление, так как они уже работают с последним выпуском (поэтому наш проверка обновления использует хэш пакета в дополнение к метке выпуска).

Если вы хотите выполнить откат развертывания до выпуска, отличного от предыдущего (например, v3 ->v2), можно указать необязательный --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>

После выполнения этой команды клиентские устройства, настроенные для получения обновлений с помощью связанного ключа развертывания, больше не будут получать очищенные обновления. Эта команда необратима, поэтому ее не следует использовать в рабочем развертывании.

Подписывание кода

Что это такое?

Подписывание кода — это способ создания цифровых подписей для пакетов, которые впоследствии можно проверить на стороне клиента перед установкой.

Зачем нам это нужно?

Разработчики хотят знать, что поставляемый ими код — это код, который они написали. Подписывание кода является основным механизмом для обеспечения такой гарантии и может помочь устранить или устранить целый класс атак типа "злоумышленник в середине".

Как это работает?

Сначала разработчик создает асимметричную пару ключей: закрытый ключ будет использоваться для подписывания пакетов; открытый ключ для проверки подписи пакета. Затем cli CodePush использует закрытый ключ для подписывания пакетов во время releaseвыполнения команд и release-reactrelease-cordova . Открытый ключ поставляется вместе с мобильным приложением. Контроль над созданием ключей и управление ими находится в руках разработчика.

В конце команды выпуска CLI вычисляет хэш содержимого пакета и помещает это значение в JWT, подписанный закрытым ключом. Когда подключаемый модуль CodePush загружает пакет на устройство, он проверяет .codepushrelease файл, содержащий JWT, и проверяет подпись JWT с помощью открытого ключа. Если проверка завершается ошибкой, обновление не устанавливается.

Требования к использованию этой функции

Если вы планируете использовать эту функцию, сделайте следующее:

Создание нового двоичного обновления, включая
- Обновлен подключаемый модуль CodePush, поддерживающий подписывание кода
- настройка пакета SDK для отправки кода для использования открытого ключа (дополнительные сведения см. в разделах, посвященных пакету SDK для React Native (iOS, Android) или Cordova SDK).
Создание нового обновления CodePush, предназначенного для новой двоичной версии и указывающего --private-key-path значение параметра (или -k).

Ознакомьтесь с нашими таблицами совместимости, чтобы определить, поддерживается ли функция подписывания кода в пакете 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

Создание ключа

Подписывание кода поддерживает ключи RSA в кодировке PEM (не сертификаты) для подписывания. Их можно создать с помощью 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-----

Выпуск подписанного обновления

Чтобы освободить подписанное обновление, следует использовать --private-key-path параметр (или -k) для release команды или release-react .

Выпуск обновлений CodePush с помощью интерфейса командной строки Центра приложений

Установка

Приступая к работе

Управление учетными записями

Аутентификация

Маркеры доступа

"App Management" (Управление приложениями).

Совместная работа приложений

Управление развертыванием

Выпуск Обновления

Выпуск Обновления (общие)

Параметр имени приложения

Обновление параметра содержимого

Параметр целевой двоичной версии

Параметр имени развертывания

Параметр Description

Отключенный параметр

Обязательный параметр

Нет повторяющегося параметра ошибки выпуска

Параметр развертывания

Выпуск Обновления (React Native)

Параметр имени приложения

Параметр имени развертывания

Параметр Description

Обязательный параметр

Нет повторяющегося параметра ошибки выпуска

Параметр развертывания

Параметр целевой двоичной версии

Параметр имени пакета

Параметр разработки

Отключенный параметр

Параметр файла записи

Параметр файла Gradle (только для Android)

Параметр Plist-файла (только для iOS)

Параметр префикса файла Plist (только для iOS)

Выходной параметр карты источника

Имя конфигурации сборки

Выпуск Обновления (Cordova)

Параметр имени приложения

Параметр имени развертывания

Параметр Description

Обязательный параметр

Параметр ошибки выпуска не дублируется

Параметр развертывания

Параметр целевой двоичной версии

Отключенный параметр

Параметр сборки

Метаданные обновления исправлений

Параметр Label

Обязательный параметр

Параметр Description

Отключенный параметр

Параметр развертывания

Параметр целевой двоичной версии

Продвижение Обновления

Параметр Description

Отключенный параметр

Обязательный параметр

Параметр ошибки выпуска не дублируется

Параметр развертывания

Параметр целевой двоичной версии

Откат Обновления

Просмотр журнала выпусков

Очистка журнала выпусков

Подписывание кода

Что это такое?

Зачем нам это нужно?

Как это работает?

Требования к использованию этой функции

Создание ключа

Выпуск подписанного обновления

Дополнительные ресурсы