Compartir a través de

Publicación de actualizaciones de CodePush mediante la CLI de App Center

  • Artículo

Importante

Visual Studio App Center está programado para la retirada el 31 de marzo de 2025. Aunque puede seguir usando Visual Studio App Center hasta que se retire por completo, hay varias alternativas recomendadas a las que puede considerar la posibilidad de migrar.

Obtenga más información sobre las escalas de tiempo de soporte técnico y las alternativas.

Instalación

  • Instalar Node.js
  • Instale la CLI de App Center: npm install -g appcenter-cli

Introducción

  1. Cree una cuenta de App Center o inicie sesión a través de la CLI mediante el appcenter login comando .
  2. Registre la aplicación con CodePush y, opcionalmente, comparta la aplicación con otros desarrolladores del equipo.
  3. CodePush-ify la aplicación y apunte a la implementación que desea usar (Apache Cordova y React Native).
  4. Publique y actualice la aplicación.

Administración de cuentas

Antes de empezar a publicar actualizaciones de aplicaciones, inicie sesión con su cuenta de CodePush existente o cree una nueva cuenta de App Center. Para ello, ejecute el siguiente comando una vez que haya instalado la CLI:

appcenter login

Este comando iniciará un explorador y le pedirá que se autentique con su cuenta de GitHub o Microsoft. Una vez autenticado, creará una cuenta de CodePush "vinculada" a la identidad de GitHub/MSA y generará una clave de acceso que puede copiar o pegar en la CLI para iniciar sesión.

Nota

Después de registrarse, inicia sesión automáticamente con la CLI, por lo que hasta que cierre sesión explícitamente, no tendrá que volver a iniciar sesión desde la misma máquina.

Autenticación

La mayoría de los comandos de la CLI de App Center requieren autenticación, por lo que antes de poder empezar a administrar su cuenta, inicie sesión con la cuenta de GitHub o Microsoft que usó al registrarse. Para ello, ejecute el siguiente comando:

appcenter login

Este comando iniciará una ventana del explorador que le pedirá que se autentique con su cuenta de GitHub o Microsoft. Generará una clave de acceso para copiar y pegar en la CLI (le pedirá que lo haga). Ahora se ha autenticado correctamente y puede cerrar de forma segura la ventana del explorador.

Cada vez que quiera comprobar si ya ha iniciado sesión, puede ejecutar el siguiente comando para mostrar la dirección de correo electrónico de la sesión de autenticación actual, el nombre de usuario y el nombre para mostrar:

appcenter profile list

Al iniciar sesión desde la CLI, la clave de acceso persiste en el disco durante la sesión para que no tenga que iniciar sesión cada vez que intente acceder a su cuenta. Para finalizar la sesión y eliminar esta clave de acceso, ejecute el siguiente comando:

appcenter logout

Si olvida cerrar sesión desde una máquina en la que no desea dejar una sesión en ejecución (por ejemplo, el portátil de su amigo), puede usar los siguientes comandos para enumerar y quitar las sesiones de inicio de sesión actuales.

appcenter tokens list
appcenter tokens delete <machineName>

Tokens de acceso

Para autenticarse en el servicio CodePush sin iniciar un explorador o sin necesidad de usar las credenciales de GitHub o Microsoft (por ejemplo, en un entorno de CI), puede ejecutar el siguiente comando para crear un "token de acceso" (junto con un nombre que describa lo que es):

appcenter tokens create -d "Azure DevOps Integration"

La tecla solo se mostrará una vez, así que recuerde guardarla en algún lugar si es necesario. Después de crear la nueva clave, puede especificar su valor con la --token marca del login comando , que le permite usar la autenticación "sin encabezado", en lugar de iniciar un explorador.

appcenter login --token <accessToken>

Al iniciar sesión con este método, el token de acceso no invalidará automáticamente el cierre de sesión y se puede usar en futuras sesiones hasta que se quite explícitamente del servidor de App Center. Sin embargo, debe cerrar la sesión una vez completada la sesión para quitar las credenciales del disco.

Administración de la aplicación

Antes de implementar actualizaciones, cree una aplicación con App Center con el siguiente comando:

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

Si la aplicación tiene como destino Android e iOS, se recomienda crear aplicaciones independientes con CodePush. Uno para cada plataforma. De este modo, puede administrar y publicar actualizaciones en ellas por separado, lo que, a largo plazo, tiende a simplificar las cosas. La mayoría de las personas sufijo el nombre de la aplicación con -Android y -iOS. Por ejemplo:

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

Nota

El uso de la misma aplicación para Android e iOS puede provocar excepciones de instalación porque el paquete de actualización codePush generado para iOS tendrá contenido diferente de la actualización generada para Android.

Sugerencia

Una nueva funcionalidad importante en la CLI de App Center es la capacidad de establecer una aplicación como la aplicación actual mediante appcenter apps set-current <ownerName>/<appName>. Al establecer una aplicación como la aplicación actual, no es necesario usar la marca en otros comandos de la -a CLI. Por ejemplo, el comando appcenter codepush deployment list -a <ownerName>/<appName> se puede acortar cuando appcenter codepush deployment list se establece la aplicación actual. Puede comprobar qué aplicación está establecida como la aplicación actual de la cuenta mediante appcenter apps get-current. Establecer la aplicación actual hace que la mayoría de los comandos de la CLI sea más corto.

Con codePush original, las aplicaciones tenían automáticamente dos implementaciones (Staging y Production). En App Center, debe crearlos usted mismo con los siguientes comandos:

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

Después de crear las implementaciones, puede acceder a las claves de implementación de ambas implementaciones mediante appcenter codepush deployment list --displayKeys, que puede empezar a usar para configurar los clientes móviles a través de sus respectivos SDK (detalles de Cordova y React Native).

Si decide que no le gusta el nombre que asignó a una aplicación, puede cambiar su nombre en cualquier momento con el siguiente comando:

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

Advertencia

Cambiar el nombre de la aplicación puede generar algunos problemas inesperados en la configuración de la rama y compilaciones durante aproximadamente 48 horas.

Si en algún momento ya no necesita una aplicación, puede quitarla del servidor mediante el siguiente comando:

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

Tenga cuidado al ejecutar este comando, ya que cualquier aplicación que se haya configurado para usarla dejará de recibir actualizaciones.

Por último, si desea enumerar todas las aplicaciones registradas con el servidor de App Center, ejecute el siguiente comando:

appcenter apps list

Colaboración de aplicaciones

Si va a trabajar con otros desarrolladores en la misma aplicación CodePush, puede agregarlos como colaboradores mediante el portal de App Center siguiendo el conjunto de instrucciones siguientes:

  1. En el portal de App Center, seleccione la aplicación para la que desea agregar colaboradores.
  2. En el área de navegación del lado izquierdo de la página, haga clic en Configuración.
  3. Haga clic en el vínculo Colaboradores .
  4. En el menú colaboradores, escriba las direcciones de correo electrónico de los colaboradores para invitarlas.

Importante

La característica Colaboradores de App Center espera que cada colaborador ya se haya registrado en App Center mediante la dirección de correo electrónico especificada.

Una vez agregado, todos los colaboradores tendrán inmediatamente los siguientes permisos en la aplicación compartida:

  1. Visualización de la aplicación, sus colaboradores, implementaciones y historial de versiones
  2. Actualizaciones de la versión de cualquiera de las implementaciones de la aplicación
  3. Promover una actualización entre cualquiera de las implementaciones de la aplicación
  4. Revertir cualquiera de las implementaciones de la aplicación
  5. Aplicación de revisiones a las versiones de cualquiera de las implementaciones de la aplicación

Los colaboradores no pueden realizar ninguna de las siguientes acciones:

  1. Cambiar el nombre o eliminar la aplicación
  2. Crear, cambiar el nombre o eliminar nuevas implementaciones dentro de la aplicación
  3. Borrar el historial de versiones de una implementación
  4. Agregar o quitar colaboradores de la aplicación (*)

Nota

Un desarrollador puede quitarse como colaborador de una aplicación que se compartió con ellos.

Con el tiempo, si alguien ya no está trabajando en una aplicación con usted, también puede quitarlos como colaborador mediante este menú colaborador en el portal.

Cada vez que quiera enumerar todos los colaboradores que se han agregado a una aplicación, puede visitar el menú colaborador en el portal.

Administración de implementación

Desde la perspectiva de CodePush, una aplicación es una agrupación con nombre para una o varias "implementaciones". Aunque la aplicación representa un "espacio de nombres" conceptual o "ámbito" para una versión específica de la plataforma de una aplicación (por ejemplo, el puerto de iOS de la aplicación Foo), sus implementaciones representan el destino real para publicar actualizaciones (para desarrolladores) y sincronizar las actualizaciones (para los usuarios finales). Las implementaciones le permiten tener varios "entornos" para cada aplicación en curso en un momento dado y ayudar a modelar la realidad de que las aplicaciones normalmente se mueven del entorno personal de un desarrollador a un entorno de prueba, control de calidad y ensayo, antes de llegar finalmente a producción.

Nota

Como verá a continuación, los releasecomandos , promote y rollback requieren un nombre de aplicación y un nombre de implementación para funcionar, ya que es la combinación de los dos que identifica de forma única un punto de distribución (por ejemplo, quiero liberar una actualización de mi aplicación de iOS a mis evaluadores beta).

Cada vez que se registra una aplicación con el servicio CodePush, se recomienda crear las siguientes implementaciones: Staging y Production. Esto le permite empezar a publicar actualizaciones en un entorno interno, donde puede probar exhaustivamente cada actualización antes de insertarlas en los usuarios finales. Este flujo de trabajo es fundamental para asegurarse de que las versiones están listas para el consumo masivo y es una práctica que se ha establecido en la web durante mucho tiempo.

Si tener una versión de ensayo y producción de la aplicación es suficiente para satisfacer sus necesidades, no tiene que hacer nada más. Sin embargo, si desea una implementación alfa, desarrollo, etc., puede crearlas fácilmente mediante el siguiente comando:

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

Al igual que con las aplicaciones, también puede quitar y cambiar el nombre de las implementaciones mediante los siguientes comandos:

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

Cada vez que quiera ver la lista de implementaciones que incluye una aplicación específica, puede ejecutar el siguiente comando:

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

Las métricas de instalación tienen el siguiente significado:

  • Activo : número de instalaciones correctas que se ejecutan actualmente en esta versión (si el usuario abrió la aplicación, vería o ejecutaría esta versión). Este número cambiará a medida que los usuarios finales actualicen a y lejos de esta versión. Esta métrica muestra el total de usuarios activos, así como el porcentaje de la audiencia general que representa. Esto facilita la determinación de la distribución de actualizaciones que los usuarios están ejecutando actualmente, así como responder a preguntas como "¿Cuántos de mis usuarios han recibido mi última actualización?".

  • Total : el número total de instalaciones correctas que esta actualización ha recibido en general. Este número solo aumenta a medida que los nuevos usuarios o dispositivos lo instalan, por lo que siempre es un superconjunto del recuento total activo. Una actualización se considera correcta una vez notifyApplicationReady (o sync) se llama después de instalarla. Entre el momento en que se descarga una actualización y se marca como correcta, se notificará como una actualización "pendiente" (consulte a continuación para obtener más información).

  • Pendiente: el número de veces que se ha descargado esta versión, pero aún no está instalada (la aplicación se ha reiniciado para aplicar los cambios). Por lo tanto, esta métrica aumenta a medida que se descargan las actualizaciones y disminuye a medida que se instalan las actualizaciones descargadas correspondientes. Esta métrica se aplica principalmente a las actualizaciones que no están configuradas para instalarse inmediatamente y ayuda a proporcionar la imagen más amplia de la adopción de versiones para las aplicaciones que dependen del reinicio o reanudación de la aplicación para aplicar una actualización (por ejemplo, quiero revertir una actualización y tengo curiosidad si alguien lo ha descargado todavía). Si ha configurado actualizaciones para instalarse inmediatamente y sigue viendo actualizaciones pendientes que se notifican, es probable que no notifyApplicationReady llame a (o sync) en el inicio de la aplicación, que es el método que comienza a enviar informes de instalación y marca las actualizaciones instaladas como consideradas correctas.

  • Reversión: número de veces que esta versión se ha revertido automáticamente en el cliente. Lo ideal es que este número sea cero y, en ese caso, esta métrica ni siquiera se muestra. Sin embargo, si ha publicado una actualización que incluye un bloqueo como parte del proceso de instalación, el complemento CodePush revertirá al usuario final a la versión anterior y notificará ese problema al servidor. Esto permite a los usuarios finales permanecer desbloqueados si se interrumpen las versiones y, al ver esta telemetría en la CLI, puede identificar versiones erróneas y responderlas revierte en el servidor.

  • Lanzamiento : indica el porcentaje de usuarios que son aptos para recibir esta actualización. Esta propiedad solo se mostrará para las versiones que representan un lanzamiento "activo" y, por tanto, tener un porcentaje de lanzamiento inferior al 100 %. Además, dado que una implementación solo puede tener un lanzamiento activo en un momento dado, esta etiqueta solo estaría presente en la versión más reciente dentro de una implementación.

  • Deshabilitado : indica si la versión se ha marcado como deshabilitada o no, por lo que los usuarios finales pueden descargarla. Esta propiedad solo se mostrará para las versiones que están deshabilitadas.

Cuando la celda de métricas notifica No installs recorded, que indica que el servidor no ha visto ninguna actividad para esta versión. Esto podría deberse a que impedía que las versiones del complemento que incluyeran compatibilidad con telemetría o que ningún usuario final se haya sincronizado con el servidor CodePush todavía. En cuanto se produzca una instalación, comenzará a ver las métricas rellenas en la CLI para la versión.

Liberar Novedades

Una vez configurada la aplicación para consultar las actualizaciones en el servidor de App Center, puede empezar a publicar actualizaciones en ella. Para proporcionar simplicidad y flexibilidad, la CLI de App Center incluye tres comandos diferentes para publicar actualizaciones:

  1. General : libera una actualización en el servidor de App Center generado por una herramienta externa o un script de compilación (por ejemplo, una tarea de Gulp, el react-native bundle comando). Esto proporciona la mayor flexibilidad en términos de ajuste a los flujos de trabajo existentes, ya que se ocupa estrictamente del paso específico de CodePush y deja el proceso de compilación específico de la aplicación.

  2. React Native: usa la misma funcionalidad que el comando de versión general, pero también controla la tarea de generar el contenido actualizado de la aplicación (agrupación de JS y recursos), en lugar de requerir que ejecute yreact-native bundle, a continuaciónappcenter codepush release, .

  3. Cordova : usa la misma funcionalidad que el comando de versión general, pero también controla la tarea de preparar la actualización de la aplicación automáticamente, en lugar de requerir que ejecute cordova prepare (o phonegap prepare) y, a continuación appcenter codepush release, .

Cuál de estos comandos debe usar es principalmente una cuestión de requisitos o preferencias. Sin embargo, se recomienda usar el comando específico de la plataforma pertinente para iniciar (ya que simplifica considerablemente la experiencia) y, a continuación, usar el comando de uso release general si se necesita un mayor control.

Nota

Solo los clientes pueden detectar y descargar las 50 versiones más recientes de una implementación.

Publicación de Novedades (General)

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]

Parámetro de nombre de aplicación

Este parámetro especifica el nombre de la aplicación de App Center para la que se está liberando esta actualización. Si desea buscarlo, puede ejecutar el comando para ver la appcenter apps list lista de aplicaciones.

Actualizar parámetro de contenido

Este parámetro especifica la ubicación del código de aplicación actualizado y los recursos que desea liberar. Puede proporcionar un único archivo (por ejemplo, un paquete JS para una aplicación de React Native) o una ruta de acceso a un directorio (por ejemplo, la /platforms/ios/www carpeta de una aplicación cordova). No tiene que comprimir varios archivos o directorios para implementar esos cambios, ya que la CLI los comprimirá automáticamente.

Es importante que la ruta de acceso que especifique haga referencia a la versión preparada o agrupada específica de la plataforma de la aplicación. En la tabla siguiente se describe el comando que debe ejecutar antes de liberar, así como la ubicación a la que puede hacer referencia más adelante mediante el updateContentsPath parámetro :

Plataforma Comando Prepare Ruta de acceso del paquete (relativa a la raíz del proyecto)
Cordova (Android) cordova prepare android ./platforms/android/assets/www Directorio
Cordova (iOS) cordova prepare ios ./platforms/ios/www Directorio
React Native wo/assets (Android) react-native bundle --platform android --entry-file <entryFile> --bundle-output <bundleOutput> --dev false Valor de la --bundle-output opción.
React Native w/assets (Android) react-native bundle --platform android --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false Valor de la --assets-dest opción , que debe representar un directorio recién creado que incluya los recursos de la aplicación y el lote de JS.
React Native wo/assets (iOS) react-native bundle --platform ios --entry-file <entryFile> --bundle-output <bundleOutput> --dev false Valor de la --bundle-output opción
React Native w/assets (iOS) react-native bundle --platform ios --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false Valor de la --assets-dest opción , que debe representar un directorio recién creado que incluya los recursos de la aplicación y el lote de JS.

Parámetro de versión binaria de destino

Este parámetro especifica la versión binaria o de la tienda de la aplicación para la que va a publicar la actualización, de modo que solo los usuarios que ejecuten esa versión recibirán la actualización, mientras que los usuarios que ejecutan una versión anterior o más reciente del binario de la aplicación no lo harán. Es útil por los siguientes motivos:

  1. Si un usuario ejecuta una versión binaria anterior, es posible que haya cambios importantes en la actualización de CodePush que no sean compatibles con lo que se están ejecutando.

  2. Si un usuario ejecuta una versión binaria más reciente, se supone que lo que está ejecutando es más reciente (y potencialmente incompatible) con la actualización codePush.

Si alguna vez quiere que una actualización tenga como destino varias versiones del binario de la tienda de aplicaciones, también le permitimos especificar el parámetro como una expresión de intervalo de gravedad. De este modo, cualquier dispositivo cliente que ejecute una versión del binario que satisfaga la expresión de intervalo (semver.satisfies(version, range) devuelve true) obtendrá la actualización. A continuación se muestran ejemplos de expresiones de intervalo de gravedad válidas:

Expresión de rango Quién obtiene la actualización
1.2.3 Solo los dispositivos que ejecutan la versión 1.2.3 binaria específica de la aplicación
* Cualquier dispositivo configurado para consumir actualizaciones de la aplicación CodePush
1.2.x Dispositivos que ejecutan la versión principal 1, la versión secundaria 2 y cualquier versión de revisión de la aplicación
1.2.3 - 1.2.7 Dispositivos que ejecutan cualquier versión binaria entre 1.2.3 (inclusive) y 1.2.7 (inclusive)
>=1.2.3 <1.2.7 Dispositivos que ejecutan cualquier versión binaria entre 1.2.3 (inclusive) y 1.2.7 (exclusiva)
1.2 Equivalente a >=1.2.0 <1.3.0.
~1.2.3 Equivalente a >=1.2.3 <1.3.0.
^1.2.3 Equivalente a >=1.2.3 <2.0.0.

Nota

Si la expresión semver de la aplicación comienza con un carácter o operador de shell especial como >, ^o ** *, es posible que el comando no se ejecute correctamente si no ajusta el valor entre comillas, ya que el shell no proporcionará los valores correctos al proceso de la CLI. Por lo tanto, es mejor ajustar el parámetro de targetBinaryVersion la aplicación entre comillas dobles al llamar al release comando, por ejemplo, appcenter codepush release -a <ownerName>/<appName> updateContents ">1.2.3".

En la tabla siguiente se describe el valor de versión que CodePush espera que el intervalo de gravedad de la actualización satisfaga para cada tipo de aplicación respectivo:

Plataforma Origen de la versión binaria
Cordova Atributo <widget version> del archivo config.xml
React Native (Android) La android.defaultConfig.versionName propiedad del archivo build.gradle del proyecto
React Native (iOS) Clave CFBundleShortVersionString del archivo Info.plist
React Native (Windows) Clave <Identity Version> del archivo Package.appxmanifest

Nota

Si a la versión binaria de los archivos de metadatos les falta una versión de revisión, por ejemplo, 2.0, se tratará como una versión de revisión de 0, es decir, 2.0 -> 2.0.0.

Parámetro de nombre de implementación

Este parámetro especifica la implementación a la que desea liberar la actualización. El valor predeterminado es Staging, pero cuando esté listo para implementarse Productionen , o en una de sus propias implementaciones personalizadas, establezca explícitamente este argumento.

Sugerencia

El parámetro se puede establecer mediante --deployment-name o -d.

Parámetro Description

Este parámetro proporciona un "registro de cambios" opcional para la implementación. El valor se realiza de ida y vuelta al cliente para que cuando se detecte la actualización, la aplicación puede optar por mostrarla al usuario final (por ejemplo, a través de un cuadro de diálogo "Novedades"). Esta cadena acepta caracteres de control como \n y \t para que pueda incluir formato de espacio en blanco dentro de las descripciones para mejorar la legibilidad.

Sugerencia

Este parámetro se puede establecer mediante --description.

Parámetro deshabilitado

Este parámetro especifica si los usuarios finales deben descargar o no una actualización. Si no se especifica, la actualización no se deshabilitará. En su lugar, los usuarios lo descargarán en el momento en que la aplicación llama a sync. Este parámetro puede ser útil si desea publicar una actualización que no está disponible inmediatamente, hasta que lo aplique explícitamente y quiera que los usuarios finales lo descarguen (por ejemplo, una entrada de blog de anuncio ha pasado a estar activa).

Sugerencia

Este parámetro se puede establecer mediante --disabled o -x.

Parámetro obligatorio

Este parámetro especifica si la actualización debe considerarse obligatoria o no (por ejemplo, incluye una corrección de seguridad crítica). Este atributo se realiza de ida y vuelta al cliente, que luego puede decidir si quiere aplicarlo y cómo quiere aplicarlo.

Nota

Este parámetro es una "marca", por lo que su ausencia indica que la versión es opcional y su presencia indica que es obligatorio. Puede proporcionar un valor a él (por ejemplo, --mandatory true), pero especificar --mandatory es suficiente para marcar una versión como obligatoria.

El atributo obligatorio es único porque el servidor lo modificará dinámicamente según sea necesario para asegurarse de que la semántica de las versiones de la aplicación se mantenga para los usuarios finales. Por ejemplo, imagine que ha publicado las tres actualizaciones siguientes en la aplicación:

Release ¿Obligatorio?
v1 No
v2 Sí
v3 No

Si un usuario final está ejecutando v1actualmente y consulta al servidor para obtener una actualización, responderá ( v3 ya que es la versión más reciente), pero convertirá dinámicamente la versión en obligatoria, ya que se publicó una actualización obligatoria entre sí. Este comportamiento es importante, ya que el código contenido en v3 es incremental al que se incluye en v2. Lo que sea obligatorio v2 continúa haciendo v3 obligatorio para cualquier persona que aún no adquirió v2.

Si un usuario final está ejecutando v2actualmente y consulta el servidor para una actualización, responderá con v3, pero dejará la versión como opcional. Esto se debe a que ya han recibido la actualización obligatoria, por lo que no es necesario modificar la directiva de v3. Este comportamiento es el motivo por el que se dice que el servidor "convierte dinámicamente" la marca obligatoria, ya que en lo que va la versión, su atributo obligatorio siempre se almacenará con el valor especificado al liberarlo. Solo se cambia sobre la marcha según sea necesario al responder a una comprobación de actualización de un usuario final.

El comportamiento descrito solo se aplica a usted si libera una actualización marcada como mandatory. El servidor solo cambiará una optional versión a mandatory si hay actualizaciones entrelazados mandatory , como se muestra anteriormente.

Una versión marcada como mandatory nunca se convertirá en optional.

Sugerencia

Este parámetro se puede establecer mediante --mandatory o -m*

No hay ningún parámetro de error de versión duplicada

Este parámetro especifica que si la actualización es idéntica a la versión más reciente de la implementación, la CLI debe generar una advertencia en lugar de un error. Resulta útil para escenarios de integración continua en los que se espera que pequeñas modificaciones puedan desencadenar versiones en las que no haya cambiado ningún código de producción.

Parámetro rollout

Importante

Para que este parámetro surta efecto, los usuarios finales deben ejecutar la versión 1.6.0-beta+ (para Cordova) o 1.9.0-beta+ (para React Native) del complemento CodePush. Si publica una actualización que especifica una propiedad de lanzamiento, ningún usuario final que ejecute una versión anterior de Cordova o los complementos de React Native serán aptos para la actualización. Hasta que haya adoptado la versión necesaria del complemento CodePush específico de la plataforma (como se mencionó anteriormente), no se recomienda establecer un valor de lanzamiento en las versiones de la aplicación, ya que nadie acabaría recibiendolo.

Este parámetro especifica el porcentaje de usuarios (como un entero entre 1 y 100) que debe ser apto para recibir esta actualización. Puede ser útil si quieres "piloto" nuevas versiones con una parte del público de la aplicación (por ejemplo, 25 %), y obtener comentarios, o watch para excepciones o bloqueos, antes de que esté disponible ampliamente para todos. Si no se establece este parámetro, el valor predeterminado es 100%. Solo tiene que establecerlo para limitar el número de usuarios que lo recibirán.

Al usar la funcionalidad de lanzamiento, hay algunas consideraciones adicionales que debe tener en cuenta:

  1. No se puede publicar una nueva actualización en una implementación cuya versión más reciente es una implementación "activa" (su propiedad rollout no es NULL). El lanzamiento debe "completarse" (estableciendo la rollout propiedad 100en ) para poder publicar más actualizaciones en la implementación.

  2. Si revierte una implementación cuya versión más reciente es una implementación "activa", el valor de lanzamiento se borrará, de forma eficaz "desactivando" el comportamiento del lanzamiento.

  3. A diferencia de los mandatory campos y description , al promover una versión de una implementación a otra, no propagará la rollout propiedad y, por tanto, si desea que la nueva versión (en la implementación de destino) tenga un valor de lanzamiento, debe establecerlo explícitamente cuando llame al promote comando.

Sugerencia

Este parámetro se puede establecer mediante --rollout o -r*

Liberar Novedades (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]

El release-react comando es una versión React Native específica del comando "vanilla", release que admite todos los mismos parámetros (por ejemplo, --mandatory, --description), pero simplifica el proceso de publicación de actualizaciones realizando las siguientes tareas adicionales:

  1. Ejecutar el react-native bundle comando para generar el contenido de la actualización (agrupación de JS y recursos) que se publicará en el servidor CodePush. Usa valores predeterminados razonables tanto como sea posible (por ejemplo, la creación de una compilación que no sea de desarrollo, suponiendo que un archivo de entrada de iOS se denomina index.ios.js), pero también expone los parámetros pertinentes react-native bundle para habilitar la flexibilidad (por ejemplo, --sourcemap-output).

  2. Inferir el targetBinaryVersion de esta versión mediante el nombre de versión especificado en los archivos Info.plist (para iOS) y build.gradle (para Android) del proyecto.

Para ilustrar la diferencia que puede hacer el comando, en el release-react ejemplo siguiente se muestra cómo puede generar y liberar una actualización para una aplicación de React Native mediante el comando "vainillarelease":

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

Lograr el comportamiento equivalente con el release-react comando requeriría el siguiente comando, que es menos propenso a errores:

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

Parámetro de nombre de aplicación

Es el mismo parámetro que el descrito en la sección anterior.

Parámetro de nombre de implementación

Es el mismo parámetro que el descrito en la sección anterior.

Parámetro Description

Es el mismo parámetro que el descrito en la sección anterior.

Parámetro obligatorio

Es el mismo parámetro que el descrito en la sección anterior.

No hay ningún parámetro de error de versión duplicada

Es el mismo parámetro que el descrito en la sección anterior.

Parámetro rollout

Es el mismo parámetro que el descrito en la sección anterior. Si no se especifica, la versión estará disponible para todos los usuarios.

Parámetro de versión binaria de destino

Es el mismo parámetro que el descrito en la sección anterior. Si no se especifica, el valor predeterminado es establecer como destino la versión exacta especificada en los archivos Info.plist (para iOS) y build.gradle (para Android).

Parámetro de nombre de agrupación

Este parámetro especifica el nombre de archivo que se debe usar para el paquete JS generado. Si se deja sin especificar, el nombre del lote estándar se usará para la plataforma especificada: main.jsbundle (iOS), index.android.bundle (Android) e index.windows.bundle (Windows).

Sugerencia

Este parámetro se puede establecer mediante --bundle-name o -b*

Parámetro de desarrollo

Este parámetro especifica si se va a generar una agrupación de JS de desarrollo no minimizada. Si no se especifica, el valor predeterminado es false donde se deshabilitan las advertencias y se minimiza la agrupación.

Sugerencia

Este parámetro se puede establecer mediante --development*

Parámetro deshabilitado

Es el mismo parámetro que el descrito en la sección anterior.

Parámetro de archivo de entrada

Este parámetro especifica la ruta de acceso relativa al archivo JavaScript raíz o entrada de la aplicación. Si no se especifica, el valor predeterminado es index.ios.js (para iOS), index.android.js (para Android) o index.windows.bundle (para Windows) si ese archivo existe o index.js de lo contrario.

Sugerencia

Este parámetro se puede establecer mediante --entry-file o -e*

Parámetro de archivo gradle (solo Android)

Este parámetro especifica la ruta de acceso relativa al archivo build.gradle que la CLI debe usar al intentar detectar automáticamente la versión binaria de destino para la versión. Este parámetro solo está pensado para escenarios avanzados, ya que la CLI puede encontrar automáticamente el archivo build.gradle del proyecto en proyectos de React Native "estándar". Sin embargo, si el archivo gradle del proyecto se encuentra en una ubicación arbitraria, que la CLI no puede detectar, el uso de este parámetro le permite seguir liberando actualizaciones de CodePush, sin necesidad de establecer explícitamente el --target-binary-version parámetro . Dado que build.gradle es un nombre de archivo necesario, especificar la ruta de acceso a la carpeta contenedora o la ruta de acceso completa al propio archivo logrará el mismo efecto.

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

Sugerencia

Este parámetro se puede establecer mediante --gradle-file o -g*

Parámetro de archivo Plist (solo iOS)

Este parámetro especifica la ruta de acceso relativa al archivo Info.plist que la CLI debe usar al intentar detectar automáticamente la versión binaria de destino para la versión. Este parámetro solo está pensado para escenarios avanzados, ya que la CLI puede encontrar automáticamente el archivo Info.plist del proyecto en proyectos de React Native "estándar", y puede usar el --plistFilePrefix parámetro para admitir archivos plist por entorno (por ejemplo, STAGING-Info.plist). Sin embargo, si el archivo plist del proyecto se encuentra en una ubicación arbitraria, que la CLI no puede detectar, el uso de este parámetro le permite seguir liberando las actualizaciones de CodePush, sin necesidad de establecer explícitamente el --target-binary-version parámetro .

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

Sugerencia

Este parámetro se puede establecer mediante --plist-file o -p*

Parámetro de prefijo de archivo Plist (solo iOS)

Este parámetro especifica el prefijo de nombre de archivo del archivo Info.plist que la CLI debe usar al intentar detectar automáticamente la versión binaria de destino para la versión. Esto puede ser útil si ha creado archivos plist por entorno (por ejemplo, DEV-Info.plist, STAGING-Info.plist) y desea liberar las actualizaciones de CodePush sin necesidad de establecer explícitamente el --target-binary-version parámetro . Al especificar , --plist-file-prefixla CLI buscará un archivo denominado <prefix>-Info.plist, en lugar de Info.plist (que es el comportamiento predeterminado), en las siguientes ubicaciones: ./ios y ./ios/<appName>. Si el archivo plist del proyecto no se encuentra en ninguno de esos directorios (por ejemplo, la aplicación es una aplicación nativa de iOS con vistas de RN incrustadas) o usa una convención de nomenclatura de archivos completamente diferente, considere la posibilidad de usar el --plist-file parámetro .

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

Parámetro de salida del mapa de origen

Este parámetro especifica la ruta de acceso relativa a donde se debe escribir el archivo de mapa de origen del paquete JS generado. Si no se especifica, no se generarán asignaciones de origen.

Sugerencia

Este parámetro se puede establecer mediante --sourcemap-output o -s*

Nombre de configuración de compilación

Nombre de la configuración de compilación en la que se especifica la versión binaria en la que desea tener como destino esta versión. Por ejemplo, "Depurar" o "Release" (solo iOS).

Nota

Este parámetro se debe usar al compilar con Xcode 11 y versiones posteriores para invalidar la configuración predeterminada usada por Xcode.

Liberar Novedades (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]

El release-cordova comando es una versión específica de Cordova del comando "vanilla", release que admite todos los mismos parámetros (por ejemplo, --mandatory, --description), pero simplifica el proceso de liberación de actualizaciones mediante las siguientes tareas adicionales:

  1. Ejecute el cordova prepare comando (o phonegap prepare) para generar el contenido de la actualización (carpeta www ) que se publicará en el servidor CodePush.

  2. Inferencia de la targetBinaryVersion propiedad de esta versión mediante el nombre de versión especificado en el archivo config.xml del proyecto.

Para ilustrar la diferencia que puede hacer el comando, en el release-cordova ejemplo siguiente se muestra cómo puede generar y liberar una actualización para una aplicación cordova mediante el comando "vanilla release ":

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

Lograr el comportamiento equivalente con el release-cordova comando requeriría el siguiente comando, lo que es menos propenso a errores:

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

Parámetro de nombre de aplicación

Es el mismo parámetro que el descrito en la sección anterior.

Parámetro de nombre de implementación

Es el mismo parámetro que el descrito en la sección anterior.

Parámetro description

Es el mismo parámetro que el descrito en la sección anterior.

Parámetro obligatorio

Es el mismo parámetro que el descrito en la sección anterior.

No hay ningún parámetro de error de versión duplicada

Es el mismo parámetro que el descrito en la sección anterior.

Parámetro rollout

Es el mismo parámetro que el descrito en la sección anterior. Si no se especifica, la versión estará disponible para todos los usuarios.

Parámetro de versión binaria de destino

Es el mismo parámetro que el descrito en la sección anterior. Si se deja sin especificar, el comando tiene como destino solo la versión especificada en los metadatos del proyecto (Info.plist si esta actualización es para clientes iOS y build.gradle para clientes Android).

Parámetro deshabilitado

Es el mismo parámetro que el descrito en la sección anterior.

Parámetro de compilación

Este parámetro especifica si desea ejecutar cordova build en lugar de cordova prepare (que es el comportamiento predeterminado), al generar los recursos web actualizados. Es útil si el proyecto incluye enlaces antes o después de la compilación (por ejemplo, para transpile TypeScript), por lo que hacer que la ejecución cordova prepare de CodePush no sea suficiente para crear y liberar una actualización. Si se deja sin especificar, el valor predeterminado es false.

Sugerencia

Este parámetro se puede establecer mediante --build o -b*

Aplicación de revisiones a los metadatos de actualización

Después de publicar una actualización, puede haber escenarios en los que quiera modificar uno o varios de los atributos de metadatos para ella (por ejemplo, olvidó marcar una corrección de errores crítica como obligatoria, quiere aumentar el porcentaje de lanzamiento de una actualización). Para ello, ejecute el siguiente comando para hacerlo fácilmente:

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]

Nota

Este comando no permite modificar el contenido de actualización real de una versión (por ejemplo, www carpeta de una aplicación cordova). Si desea responder a una versión que se ha identificado como interrumpida, debe usar el comando rollback para revertirlo inmediatamente y, si es necesario, publicar una nueva actualización con la corrección adecuada cuando esté disponible.

Además de <ownerName>/<appName> y deploymentName, todos los parámetros son opcionales, por lo que puede usar este comando para actualizar un único atributo o todos ellos a la vez. Llamar al patch comando sin especificar ninguna marca de atributo dará lugar a una operación sin operación.

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

Parámetro de etiqueta

Indica qué versión (por ejemplo, v23) desea actualizar dentro de la implementación especificada. Si se omite, los cambios solicitados se aplicarán a la versión más reciente de la implementación especificada. Para buscar la etiqueta de la versión que desea actualizar, puede ejecutar el appcenter codepush deployment history comando y hacer referencia a la Label columna.

Parámetro obligatorio

Es el mismo parámetro que el descrito en la sección anterior y permite actualizar si la versión debe considerarse obligatoria o no. Preste atención a que --mandatory y --mandatory true son equivalentes, pero la ausencia de esta marca no es equivalente a --mandatory false. Si se omite el parámetro, no se realizará ningún cambio en el valor de la propiedad obligatoria de la versión de destino. Establezca este parámetro --mandatory false en para que una versión sea opcional explícitamente.

Parámetro description

Es el mismo parámetro que el descrito en la sección anterior y le permite actualizar la descripción de la versión (por ejemplo, hizo un error tipográfico al liberar o olvidó agregar una descripción en absoluto). Si se omite este parámetro, no se realizará ningún cambio en el valor de la propiedad description de la versión de destino.

Parámetro deshabilitado

Es el mismo parámetro que el descrito en la sección anterior y permite actualizar si la versión debe deshabilitarse o no. Preste atención --disabled y --disabled true sean equivalentes, pero la ausencia de esta marca no es equivalente a --disabled false. Si se omite el parámetro, no se realizará ningún cambio en el valor de la propiedad deshabilitada de la versión de destino. Establezca este parámetro --disabled false en para que una versión sea acquirable explícitamente, si se deshabilitó anteriormente.

Parámetro rollout

Es el mismo parámetro que el descrito en la sección anterior y permite aumentar el porcentaje de lanzamiento de la versión de destino. Este parámetro solo se puede establecer en un entero cuyo valor sea mayor que el valor de lanzamiento actual. Además, si desea "completar" el lanzamiento y hacer que la versión esté disponible para todos los usuarios, puede establecer este parámetro en --rollout 100. Si se omite este parámetro, no se realizará ningún cambio en el valor del parámetro de lanzamiento de la versión de destino.

Además, como se mencionó anteriormente, al publicar una actualización sin un valor de lanzamiento, se trata de forma equivalente para establecer el lanzamiento 100en . Si ha publicado una actualización sin una implementación, no puede cambiar la propiedad rollout de ella a través del patch comando , ya que se consideraría reducir el porcentaje de lanzamiento.

Parámetro de versión binaria de destino

Es el mismo parámetro que el descrito en la sección anterior y permite actualizar el intervalo de servidores que indica con qué versiones binarias es compatible una versión. Esto puede ser útil si ha cometido un error al publicar originalmente una actualización (por ejemplo, especificó 1.0.0 pero significaba 1.1.0) o si desea aumentar o disminuir el intervalo de versiones que admite una versión (por ejemplo, descubrió que una versión no funciona 1.1.2 después de todo). Si se omite este parámetro, no se realizará ningún cambio en el valor de la propiedad version de la versión de destino.

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

Promoción de Novedades

Una vez que haya probado una actualización en una implementación específica (por ejemplo, Staging) y quiera promoverla "descendente" (por ejemplo, dev-staging>, staging-production>), puede usar el siguiente comando para copiar la versión de una implementación a otra:

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]

El promote comando crea una nueva versión para la implementación de destino, que incluye el código y los metadatos exactos (descripción, obligatoria y versión binaria de destino) de la versión más reciente de la implementación de origen. Aunque puede usar el release comando para migrar manualmente una actualización de un entorno a otro, el promote comando tiene las siguientes ventajas:

  1. Es más rápido, ya que no es necesario volver a ensamblar los recursos de versión que desea publicar o recordar la descripción o la versión binaria que se usa para la versión de la implementación de origen.

  2. Es menos propenso a errores, ya que la operación de promoción garantiza que lo exacto que ya haya probado en la implementación de origen (por ejemplo, Staging) se activará en la implementación de destino (por ejemplo, Production).

Se recomienda que todos los usuarios aprovechen las ventajas de los entornos y creados Staging automáticamente, y realicen todas las versiones directamente en Stagingy, a continuaciónpromote, de Staging a Production después de las pruebas adecuadas.Production

Parámetro description

Es el mismo parámetro que el descrito en la sección anterior y permite invalidar la descripción que se usará para la versión promocionada. Si no se especifica, la nueva versión heredará la descripción de la versión que se va a promover.

Parámetro deshabilitado

Es el mismo parámetro que el descrito en la sección anterior y permite invalidar el valor de la marca deshabilitada que se usará para la versión promocionada. Si no se especifica, la nueva versión heredará la propiedad deshabilitada de la versión que se va a promover.

Parámetro obligatorio

Es el mismo parámetro que el descrito en la sección anterior y permite invalidar la marca obligatoria que se usará para la versión promocionada. Si no se especifica, la nueva versión heredará la propiedad obligatoria de la versión que se va a promover.

No hay ningún parámetro de error de versión duplicada

Es el mismo parámetro que el descrito en la sección anterior.

Parámetro rollout

Es el mismo parámetro que el descrito en la sección anterior y permite especificar si la versión recién creada solo debe estar disponible para una parte de los usuarios. A diferencia de los demás parámetros de metadatos de versión (por ejemplo, description), el rollout de una versión no se transfiere o hereda como parte de una promoción, por lo que debe establecerlo explícitamente si no desea que la versión recién creada esté disponible para todos los usuarios.

Parámetro de versión binaria de destino

Es el mismo parámetro que el descrito en la sección anterior y permite invalidar la versión binaria de destino que se usará para la versión promocionada. Si no se especifica, la nueva versión heredará la propiedad de versión binaria de destino de la versión que se va a promover.

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

Revertir Novedades

El historial de versiones de una implementación es inmutable, por lo que no puede eliminar ni quitar una actualización una vez que se haya publicado. Sin embargo, si publica una actualización interrumpida o contiene características no deseadas, es fácil revertirla mediante el rollback comando :

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

Al ejecutar este comando se crea una nueva versión para la implementación que incluye exactamente el mismo código y metadatos que la versión anterior a la más reciente. Por ejemplo, imagine que ha publicado las siguientes actualizaciones en la aplicación:

Release Descripción Mandatory
v1 Versión inicial. Sí
v2 Se ha agregado una nueva característica No
v3 Corrección de errores Sí

Si ejecutó el rollback comando en esa implementación, se crearía una nueva versión (v4) que incluyera el contenido de la v2 versión.

Release Descripción Mandatory
v1 Versión inicial. Sí
v2 Se ha agregado una nueva característica No
v3 Corrección de errores Sí
v4 (reversión de v3 a v2) Se ha agregado una nueva característica No

Los usuarios finales que ya adquirieron v3 ahora se "moverán de vuelta" a v2 cuando la aplicación realice una comprobación de actualización. Además, los usuarios que todavía estaban ejecutando v2y, por lo tanto, nunca habían adquirido v3, no recibirían una actualización, ya que ya están ejecutando la versión más reciente (por eso nuestra comprobación de actualización usa el hash del paquete además de la etiqueta de versión).

Si desea revertir una implementación a una versión distinta de la anterior (por ejemplo, v3 ->v2), puede especificar el parámetro opcional --target-release :

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

Nota

La versión generada por una reversión se anotará en la salida del deployment history comando para ayudar a identificarlas más fácilmente.

Visualización del historial de versiones

Puede ver un historial de las 50 versiones más recientes de una implementación de aplicación específica mediante el siguiente comando:

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

El historial mostrará todos los atributos de cada versión (por ejemplo, etiqueta, obligatorio), así como indica si se realizaron versiones debido a una promoción o una operación de reversión.

Historial de implementación

Además, el historial muestra las métricas de instalación de cada versión. Puede ver los detalles sobre cómo interpretar los datos de métricas en la documentación del deployment list comando anterior.

Borrar el historial de versiones

Puede borrar el historial de versiones de una implementación mediante el siguiente comando:

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

Después de ejecutar este comando, los dispositivos cliente configurados para recibir actualizaciones mediante su clave de implementación asociada ya no recibirán las actualizaciones que se han borrado. Este comando es irreversible, por lo que no se debe usar en una implementación de producción.

Firma de códigos

¿Qué es?

La firma de código es una manera de crear firmas digitales para agrupaciones que se pueden validar posteriormente en el lado cliente antes de la instalación.

¿Por qué es necesario?

Los desarrolladores quieren saber que el código que envían es el código que escribieron. La firma de código es el mecanismo principal para proporcionar dicha garantía y puede ayudar a mitigar o eliminar toda una clase de ataques de tipo "man in the middle".

¿Cómo funciona?

En primer lugar, el desarrollador genera un par de claves asimétricas: la clave privada se usará para firmar agrupaciones; la clave pública para la comprobación de firma de agrupación. A continuación, la CLI de CodePush usa la clave privada para firmar agrupaciones durante releaselos comandos y release-reactrelease-cordova . La clave pública se incluye con la aplicación móvil. El control sobre la generación y administración de claves está en manos del desarrollador.

Al final del comando release, la CLI calcula el hash de contenido del paquete y coloca este valor en un JWT firmado con la clave privada. Cuando el complemento CodePush descarga una agrupación en un dispositivo, comprueba el .codepushrelease archivo que contiene el JWT y valida la firma JWT mediante la clave pública. Si se produce un error en la validación, la actualización no está instalada.

Requisitos para usar esta característica

Si planea usar esta característica, siga estos pasos:

  1. Generar una nueva actualización binaria, incluida

    • Se ha actualizado el complemento CodePush compatible con la firma de código
    • Configure el SDK de inserción de código para usar la clave pública (consulte las secciones correspondientes del SDK de React Native (iOS, Android) o sdk de Cordova para obtener más información).

  2. Genera una nueva actualización de CodePush que tiene como destino la nueva versión binaria y especifica un --private-key-path valor de parámetro (o -k)

Consulte nuestras tablas de compatibilidad para identificar si se admite la característica de firma de código en el SDK o la CLI:

CodePush SDK Versión desde la que se admite la firma de código Plataformas compatibles Se requiere una versión mínima de la CLI de CodePush
react-native-code-push 5.1.0 Android, iOS 2.1.0
cordova-plugin-code-push 1.10.0 Android, iOS 2.1.2

Generación de la clave

La firma de código admite claves RSA codificadas peM (no certificados) para la firma. Puede generarlos a través de openssl, como se muestra a continuación:

# 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

Ejemplo de claves generadas:

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

Publicación de la actualización firmada

Para liberar la actualización firmada, debe usar --private-key-path (o -k) para release o release-react comando.