Rilascio degli aggiornamenti codePush tramite l'interfaccia della riga di comando di App Center

Importante

Visual Studio App Center è previsto per il ritiro il 31 marzo 2025. Anche se è possibile continuare a usare Visual Studio App Center fino a quando non viene completamente ritirato, esistono diverse alternative consigliate che è possibile considerare la migrazione a.

Altre informazioni sulle sequenze temporali di supporto e sulle alternative.

Installazione

• Installare Node.js
• Installare l'interfaccia della riga di comando di App Center: npm install -g appcenter-cli

Introduzione

1. Creare un account di App Center o accedere tramite l'interfaccia della riga di comando usando il appcenter login comando .
2. Registrare l'app con CodePush e, facoltativamente, condividere l'app con altri sviluppatori nel team.
3. CodePush-ify l'app e puntarla alla distribuzione da usare (Apache Cordova e React Native).
4. Rilasciare e aggiornare l'app.

Gestione account

Prima di iniziare a rilasciare gli aggiornamenti dell'app, accedere con l'account CodePush esistente o creare un nuovo account di App Center. Questa operazione può essere eseguita eseguendo il comando seguente dopo aver installato l'interfaccia della riga di comando:

appcenter login

Questo comando avvierà un browser, chiedendo di eseguire l'autenticazione con l'account GitHub o Microsoft. Dopo l'autenticazione, creerà un account CodePush "collegato" all'identità GitHub/MSA e genererà una chiave di accesso che è possibile copiare/incollare nell'interfaccia della riga di comando per accedere.

Nota

Dopo la registrazione, l'accesso automatico viene eseguito con l'interfaccia della riga di comando, quindi fino a quando non si disconnette in modo esplicito, non è necessario eseguire di nuovo l'accesso dallo stesso computer.

Authentication

La maggior parte dei comandi all'interno dell'interfaccia della riga di comando di App Center richiede l'autenticazione, quindi prima di iniziare a gestire l'account, accedere usando GitHub o l'account Microsoft usato durante la registrazione. È possibile eseguire questa operazione eseguendo il comando seguente:

appcenter login

Questo comando avvierà una finestra del browser che richiede di eseguire l'autenticazione con l'account GitHub o Microsoft. Genererà una chiave di accesso da copiare incollare nell'interfaccia della riga di comando (verrà richiesta). È ora possibile autenticare correttamente e chiudere in modo sicuro la finestra del browser.

In qualsiasi momento si vuole verificare se si è già connessi, è possibile eseguire il comando seguente per visualizzare l'indirizzo di posta elettronica per la sessione di autenticazione corrente, il nome utente e il nome visualizzato:

appcenter profile list

Quando si accede dall'interfaccia della riga di comando, la chiave di accesso persiste sul disco per la durata della sessione in modo che non sia necessario accedere ogni volta che si tenta di accedere all'account. Per terminare la sessione ed eliminare questa chiave di accesso, eseguire il comando seguente:

appcenter logout

Se si dimentica di disconnettersi da un computer in cui non si vuole lasciare una sessione in esecuzione (ad esempio, il portatile dell'amico), è possibile usare i comandi seguenti per elencare e rimuovere le sessioni di accesso correnti.

appcenter tokens list
appcenter tokens delete <machineName>

Token di accesso

Per eseguire l'autenticazione con il servizio CodePush senza avviare un browser o senza dover usare gitHub o credenziali Microsoft (ad esempio, in un ambiente CI), è possibile eseguire il comando seguente per creare un "token di accesso" (insieme a un nome che descrive cosa è per):

appcenter tokens create -d "Azure DevOps Integration"

La chiave verrà visualizzata una sola volta, quindi ricordarsi di salvarla da qualche parte se necessario! Dopo aver creato la nuova chiave, è possibile specificare il relativo valore usando il flag del login comando, che consente di usare l'autenticazione --token "headless", anziché avviare un browser.

appcenter login --token <accessToken>

Quando si esegue l'accesso con questo metodo, il token di accesso non invaliderà automaticamente la disconnessione e può essere usato nelle sessioni future fino a quando non viene rimosso in modo esplicito dal server di App Center. Tuttavia, è necessario firmare una volta completata la sessione, per rimuovere le credenziali dal disco.

Gestione app

Prima di distribuire gli aggiornamenti, creare un'app con App Center usando il comando seguente:

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

Se l'app è destinata sia ad Android che a iOS, è consigliabile creare app separate con CodePush. Uno per ogni piattaforma. In questo modo, è possibile gestire e rilasciare gli aggiornamenti separatamente, che a lungo termine, tende a rendere più semplici le cose. La maggior parte delle persone suffisso il nome dell'app con -Android e -iOS. ad esempio:

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

Nota

L'uso della stessa app per Android e iOS può causare eccezioni di installazione perché il pacchetto di aggiornamento CodePush prodotto per iOS avrà contenuto diverso dall'aggiornamento prodotto per Android.

Suggerimento

Una nuova funzionalità importante nell'interfaccia della riga di comando di App Center è la possibilità di impostare un'app come app corrente usando appcenter apps set-current <ownerName>/<appName>. Impostando un'app come app corrente non è necessario usare il -a flag in altri comandi dell'interfaccia della riga di comando. Ad esempio, il comando appcenter codepush deployment list -a <ownerName>/<appName> può essere abbreviato a appcenter codepush deployment list quando l'app corrente è impostata. È possibile controllare quale app è impostata come app corrente dell'account usando appcenter apps get-current. L'impostazione dell'app corrente rende più breve la digitazione dei comandi dell'interfaccia della riga di comando.

Con l'originale CodePush, le app hanno automaticamente due distribuzioni (Staging e Production). In App Center è necessario crearli manualmente usando i comandi seguenti:

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

Dopo aver creato le distribuzioni, è possibile accedere alle chiavi di distribuzione per entrambe le distribuzioni usando appcenter codepush deployment list --displayKeys, che è possibile iniziare a usare per configurare i client per dispositivi mobili tramite i rispettivi SDK (dettagli per Cordova e React Native).

Se si decide che il nome assegnato a un'app non è simile, è possibile rinominarlo in qualsiasi momento usando il comando seguente:

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

Avviso

La modifica del nome dell'app può generare alcuni problemi imprevisti nella configurazione del ramo e le compilazioni per circa 48 ore.

Se a un certo punto non è più necessaria un'app, è possibile rimuoverla dal server usando il comando seguente:

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

Prestare attenzione durante l'esecuzione di questo comando come qualsiasi app configurata per usarla interromperà la ricezione degli aggiornamenti.

Infine, se si desidera elencare tutte le app registrate con il server App Center, eseguire il comando seguente:

appcenter apps list

Collaborazione app

Se si lavora con altri sviluppatori nella stessa app CodePush, è possibile aggiungerli come collaboratori usando il portale di App Center seguendo il set di istruzioni seguenti:

1. Nel portale di App Center selezionare l'app per cui si desidera aggiungere collaboratori
2. Nell'area di spostamento a sinistra della pagina fare clic su Impostazioni
3. Fare clic sul collegamento Collaboratori
4. Nel menu collaboratori immettere gli indirizzi di posta elettronica dei collaboratori per invitarli.

Importante

La funzionalità Collaboratori di App Center prevede che ogni collaboratore sia già registrato con App Center usando l'indirizzo di posta elettronica specificato.

Una volta aggiunto, tutti i collaboratori avranno immediatamente le autorizzazioni seguenti nell'app condivisa:

1. Visualizzare l'app, i relativi collaboratori, distribuzioni e cronologia di rilascio
2. Aggiornamenti delle versioni a una delle distribuzioni dell'app
3. Promuovere un aggiornamento tra le distribuzioni dell'app
4. Eseguire il rollback di una delle distribuzioni dell'app
5. Applicare patch a tutte le versioni all'interno di una delle distribuzioni dell'app

I collaboratori non possono eseguire alcuna delle azioni seguenti:

1. Rinominare o eliminare l'app
2. Creare, rinominare o eliminare nuove distribuzioni all'interno dell'app
3. Cancellare la cronologia delle versioni di una distribuzione
4. Aggiungere o rimuovere collaboratori dall'app (*)

Nota

Uno sviluppatore può rimuoverlo come collaboratore da un'app condivisa con loro.

Nel corso del tempo, se qualcuno non lavora più su un'app con te, puoi anche rimuoverli come collaboratore usando questo menu collaboratore nel portale.

In qualsiasi momento si vuole elencare tutti i collaboratori aggiunti a un'app, è possibile visitare il menu collaboratore nel portale.

Gestione della distribuzione

Dal punto di vista codePush, un'app è un raggruppamento denominato per una o più "distribuzioni". Mentre l'app rappresenta uno "spazio dei nomi" concettuale o "ambito" per una versione specifica della piattaforma di un'app (ad esempio, la porta iOS dell'app Foo), le distribuzioni rappresentano la destinazione effettiva per rilasciare gli aggiornamenti (per gli sviluppatori) e sincronizzare gli aggiornamenti (per gli utenti finali). Le distribuzioni consentono di disporre di più "ambienti" per ogni app in anteprima in qualsiasi momento e di modellare la realtà che le app si spostano in genere dall'ambiente personale di uno sviluppatore a un ambiente di test/QA/staging, prima di entrare in produzione.

Nota

Come si vedrà di seguito, i releasepromote comandi e rollback richiedono sia un nome dell'app che un nome di distribuzione per funzionare, perché è la combinazione dei due che identifica in modo univoco un punto di distribuzione (ad esempio, si vuole rilasciare un aggiornamento dell'app iOS ai tester beta).

Ogni volta che un'app viene registrata con il servizio CodePush, è consigliabile creare le distribuzioni seguenti: Staging e Production. Ciò consente di iniziare a rilasciare gli aggiornamenti in un ambiente interno, in cui è possibile testare accuratamente ogni aggiornamento prima di eseguirne il push agli utenti finali. Questo flusso di lavoro è fondamentale per garantire che le versioni siano pronte per il consumo di massa ed è una pratica stabilita nel Web per molto tempo.

Se si dispone di una versione di gestione temporanea e di produzione dell'app è sufficiente per soddisfare le proprie esigenze, non è necessario eseguire altre operazioni. Tuttavia, se si vuole una distribuzione alfa, sviluppo e così via, è possibile crearli facilmente usando il comando seguente:

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

Come per le app, è possibile rimuovere e rinominare anche le distribuzioni, usando rispettivamente i comandi seguenti:

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

In qualsiasi momento si vuole visualizzare l'elenco delle distribuzioni incluse da un'app specifica, è possibile eseguire il comando seguente:

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

Le metriche di installazione hanno il significato seguente:

• Attivo : numero di installazioni riuscite attualmente in esecuzione questa versione (se l'utente ha aperto l'app, visualizzerà/eseguirà questa versione). Questo numero cambierà quando gli utenti finali vengono aggiornati a e lontano da questa versione. Questa metrica mostra sia il totale degli utenti attivi, sia la percentuale di destinatari complessivi che rappresenta. In questo modo è facile determinare la distribuzione degli aggiornamenti attualmente in esecuzione dagli utenti, nonché rispondere alle domande come "Quanti utenti hanno ricevuto l'aggiornamento più recente?".

• Totale : numero totale di installazioni riuscite ricevute complessivamente da questo aggiornamento. Questo numero aumenta solo quando i nuovi utenti/dispositivi lo installano, quindi è sempre un superset del conteggio totale attivo. Un aggiornamento viene considerato riuscito una volta notifyApplicationReady (o sync) viene chiamato dopo l'installazione. Tra il momento in cui viene scaricato un aggiornamento e viene contrassegnato come riuscito, verrà segnalato come un aggiornamento "in sospeso" (vedere di seguito per informazioni dettagliate).

• In sospeso : numero di volte in cui questa versione è stata scaricata, ma non ancora installata (l'app è stata riavviata per applicare le modifiche). Questa metrica aumenta quindi quando vengono scaricati gli aggiornamenti e diminuisce quando vengono installati gli aggiornamenti scaricati corrispondenti. Questa metrica si applica principalmente agli aggiornamenti che non sono configurati immediatamente per l'installazione e consente di fornire l'immagine più ampia dell'adozione della versione per le app che si basano sulla ripresa o il riavvio dell'app per applicare un aggiornamento (ad esempio, voglio eseguire il rollback di un aggiornamento e sono curioso se qualcuno l'ha ancora scaricato). Se sono stati configurati gli aggiornamenti per l'installazione immediata e vengono comunque visualizzati gli aggiornamenti in sospeso, è probabile che non si stia chiamando notifyApplicationReady (o sync) all'avvio dell'app, ovvero il metodo che avvia l'invio di report di installazione e contrassegna gli aggiornamenti installati come considerati riusciti.

• Rollback: numero di volte in cui questa versione è stata eseguito automaticamente il rollback nel client. Idealmente questo numero deve essere zero e, in questo caso, questa metrica non viene nemmeno visualizzata. Tuttavia, se è stato rilasciato un aggiornamento che include un arresto anomalo durante il processo di installazione, il plug-in CodePush eseguirà il rollback dell'utente finale alla versione precedente e segnala che il problema torna al server. Ciò consente agli utenti finali di rimanere sbloccati se le versioni vengono interrotte e visualizzando i dati di telemetria nell'interfaccia della riga di comando, è possibile identificare le versioni errate e rispondere eseguendo il rollback nel server.

• Implementazione : indica la percentuale di utenti idonei a ricevere questo aggiornamento. Questa proprietà verrà visualizzata solo per le versioni che rappresentano un'implementazione "attiva" e quindi una percentuale di implementazione inferiore al 100%. Inoltre, poiché una distribuzione può avere un solo implementazione attiva in qualsiasi momento, questa etichetta sarà presente solo nella versione più recente all'interno di una distribuzione.

• Disabilitato: indica se la versione è stata contrassegnata come disabilitata o meno e quindi è scaricabile dagli utenti finali. Questa proprietà verrà visualizzata solo per le versioni disabilitate.

Quando la cella delle metriche segnala No installs recorded, che indica che il server non ha visto alcuna attività per questa versione. Ciò potrebbe essere dovuto al fatto che le versioni del plug-in che includevano il supporto dei dati di telemetria o che nessun utente finale abbia ancora sincronizzato con il server CodePush. Non appena si verifica un'installazione, si inizierà a visualizzare le metriche popolate nell'interfaccia della riga di comando per la versione.

Rilascio di Aggiornamenti

Dopo aver configurato l'app per eseguire query per gli aggiornamenti nel server di App Center, è possibile iniziare a rilasciare gli aggiornamenti. Per offrire semplicità e flessibilità, l'interfaccia della riga di comando di App Center include tre comandi diversi per rilasciare gli aggiornamenti:

1. Generale : rilascia un aggiornamento al server di App Center generato da uno strumento esterno o uno script di compilazione(ad esempio, un'attività Gulp, il react-native bundle comando). Ciò offre la maggiore flessibilità in termini di adattamento ai flussi di lavoro esistenti, poiché si occupa strettamente del passaggio specifico di CodePush e lascia il processo di compilazione specifico dell'app all'utente.

2. React Native : usa la stessa funzionalità del comando di versione generale, ma gestisce anche l'attività di generazione del contenuto dell'app aggiornata per l'utente (bundle JS e asset), anziché richiedere di eseguire entrambi react-native bundle e quindi appcenter codepush release.

3. Cordova : usa la stessa funzionalità del comando di versione generale, ma gestisce anche l'attività di preparazione dell'aggiornamento dell'app per l'utente, anziché richiedere l'esecuzione di entrambi cordova prepare (o phonegap prepare) e quindi appcenter codepush release.

Quale di questi comandi è consigliabile usare è principalmente una questione di requisiti o preferenze. È tuttavia consigliabile usare il comando specifico della piattaforma pertinente per avviare (poiché semplifica notevolmente l'esperienza) e quindi usare il comando per utilizzo release generico se/quando è necessario un controllo maggiore.

Nota

Solo le 50 versioni più recenti in una distribuzione possono essere individuate e scaricate dai client.

Rilascio di Aggiornamenti (generale)

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]

Parametro nome app

Questo parametro specifica il nome dell'app App Center per cui questo aggiornamento viene rilasciato. Se si vuole cercarlo, è possibile eseguire il comando per visualizzare l'elenco appcenter apps list di app.

Aggiornare il parametro contenuto

Questo parametro specifica il percorso del codice e degli asset dell'app aggiornati che si desidera rilasciare. È possibile specificare un singolo file (ad esempio un bundle JS per un'app React Native) o un percorso di una directory ,ad esempio la /platforms/ios/www cartella per un'app Cordova. Non è necessario eseguire la zip di più file o directory per distribuire tali modifiche, poiché l'interfaccia della riga di comando li comprimerà automaticamente.

È importante che il percorso specificato faccia riferimento alla versione specifica della piattaforma, preparata/in bundle dell'app. La tabella seguente descrive il comando che è necessario eseguire prima del rilascio, nonché il percorso che è possibile fare riferimento successivamente all'uso del updateContentsPath parametro:

Piattaforma	Preparare il comando	Percorso del pacchetto (relativo alla radice del progetto)
Cordova (Android)	cordova prepare android	./platforms/android/assets/www Directory
Cordova (iOS)	cordova prepare ios	./platforms/ios/www Directory
React Native wo/assets (Android)	react-native bundle --platform android --entry-file <entryFile> --bundle-output <bundleOutput> --dev false	Valore dell'opzione --bundle-output .
React Native w/assets (Android)	react-native bundle --platform android --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false	Valore dell'opzione --assets-dest , che deve rappresentare una directory appena creata che include gli asset dell'app e il bundle JS
React Native wo/assets (iOS)	react-native bundle --platform ios --entry-file <entryFile> --bundle-output <bundleOutput> --dev false	Valore dell'opzione --bundle-output
React Native w/assets (iOS)	react-native bundle --platform ios --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false	Valore dell'opzione --assets-dest , che deve rappresentare una directory appena creata che include gli asset dell'app e il bundle JS

Parametro della versione binaria di destinazione

Questo parametro specifica la versione store/binaria dell'applicazione per cui si sta rilasciando l'aggiornamento, in modo che solo gli utenti che eseguono tale versione ricevano l'aggiornamento, mentre gli utenti che eseguono una versione precedente o successiva del file binario dell'app non riceveranno. È utile per i motivi seguenti:

1. Se un utente esegue una versione binaria precedente, è possibile che siano presenti modifiche di rilievo nell'aggiornamento CodePush che non sarebbero compatibili con ciò che vengono eseguite.

2. Se un utente esegue una versione binaria più recente, si presuppone che l'esecuzione sia più recente (e potenzialmente incompatibile) con l'aggiornamento CodePush.

Se si vuole che un aggiornamento venga chiamato a destinazione di più versioni del file binario dell'app store, è anche possibile specificare il parametro come espressione di intervallo semver. In questo modo, qualsiasi dispositivo client che esegue una versione del file binario che soddisfa l'espressione di intervallo (semver.satisfies(version, range) restituisce true) otterrà l'aggiornamento. Di seguito sono riportati esempi di espressioni di intervallo semver valide:

Espressione intervallo	Chi ottiene l'aggiornamento
1.2.3	Solo i dispositivi che eseguono la versione 1.2.3 binaria specifica dell'app
*	Qualsiasi dispositivo configurato per l'utilizzo degli aggiornamenti dall'app CodePush
1.2.x	Dispositivi che eseguono la versione principale 1, versione secondaria 2 e qualsiasi versione patch dell'app
1.2.3 - 1.2.7	Dispositivi che eseguono qualsiasi versione binaria tra 1.2.3 (inclusivo) e 1.2.7 (inclusivo)
>=1.2.3 <1.2.7	Dispositivi che eseguono qualsiasi versione binaria tra 1.2.3 (inclusivo) e 1.2.7 (esclusivo)
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

Se l'espressione semver dell'app inizia con un carattere o un operatore della shell speciale, >ad esempio , ^o ** *, il comando potrebbe non essere eseguito correttamente se non si esegue il wrapping del valore nelle virgolette come la shell non fornisce i valori corretti al processo dell'interfaccia della riga di comando. È quindi consigliabile eseguire il wrapping del parametro dell'app targetBinaryVersion in virgolette doppie quando si chiama il release comando, appcenter codepush release -a <ownerName>/<appName> updateContents ">1.2.3"ad esempio .

La tabella seguente descrive il valore della versione che CodePush prevede che l'intervallo semver dell'aggiornamento soddisfi ogni rispettivo tipo di app:

Piattaforma	Origine della versione binaria
Cordova	Attributo <widget version> nel file diconfig.xml
React Native (Android)	Proprietà android.defaultConfig.versionName nel file build.gradle del progetto
React Native (iOS)	CFBundleShortVersionString Chiave nel file Info.plist
React Native (Windows)	<Identity Version> Chiave nel file Package.appxmanifest

Nota

Se la versione binaria nei file di metadati manca una versione di patch, ad esempio 2.0, verrà considerata come avere una versione patch di 0, ovvero 2.0 -> 2.0.0.

Parametro nome distribuzione

Questo parametro specifica la distribuzione a cui si vuole rilasciare l'aggiornamento. Il valore predefinito è Staging, ma quando si è pronti per la distribuzione in Productiono una delle distribuzioni personalizzate, è sufficiente impostare in modo esplicito questo argomento.

Suggerimento

Il parametro può essere impostato usando --deployment-name o -d.

Parametro Descrizione

Questo parametro fornisce un "log delle modifiche" facoltativo per la distribuzione. Il valore viene arrotondato al client in modo che, quando viene rilevato l'aggiornamento, l'app può scegliere di visualizzarla all'utente finale, ad esempio tramite una finestra di dialogo "Novità?". Questa stringa accetta caratteri di controllo come \n e \t in modo da poter includere la formattazione degli spazi vuoti all'interno delle descrizioni per migliorare la leggibilità.

Suggerimento

Questo parametro può essere impostato usando --description.

Parametro disabilitato

Questo parametro specifica se un aggiornamento deve essere scaricabile dagli utenti finali o meno. Se non specificato, l'aggiornamento non verrà disabilitato. Gli utenti scaricheranno invece il momento in cui l'app chiama sync. Questo parametro può essere utile se si vuole rilasciare un aggiornamento che non è immediatamente disponibile, fino a quando non si applica la patch esplicita e si vuole che gli utenti finali lo scarichino (ad esempio, un post di blog di annuncio è stato pubblicato).

Suggerimento

Questo parametro può essere impostato usando --disabled o -x.

Parametro obbligatorio

Questo parametro specifica se l'aggiornamento deve essere considerato obbligatorio o meno ,ad esempio include una correzione di sicurezza critica. Questo attributo viene arrotondato al client, che può quindi decidere se e come applicarlo.

Nota

Questo parametro è un "flag", quindi la sua assenza indica che la versione è facoltativa e la sua presenza indica che è obbligatorio. È possibile specificare un valore ( ad esempio , --mandatory true), ma specificare è sufficiente per contrassegnare --mandatory una versione come obbligatoria.

L'attributo obbligatorio è univoco perché il server lo modificherà dinamicamente in base alle esigenze per garantire che la semantica delle versioni dell'app venga mantenuta per gli utenti finali. Si supponga, ad esempio, di aver rilasciato i tre aggiornamenti seguenti all'app:

Versione	Obbligatorio?
v1	No
v2	Sì
v3	No

Se un utente finale esegue attualmente e esegue v1una query sul server per un aggiornamento, risponderà con v3 (poiché è l'ultima versione), ma convertirà dinamicamente la versione in obbligatoria, poiché un aggiornamento obbligatorio è stato rilasciato tra. Questo comportamento è importante perché il codice contenuto in v3 è incrementale a quello incluso in v2. Qualsiasi cosa resa v2 obbligatoria continua a rendere v3 obbligatorio per chiunque non abbia già acquisito v2.

Se un utente finale esegue attualmente e esegue v2una query sul server per un aggiornamento, risponderà con v3, ma lascia la versione come facoltativa. Ciò è dovuto al fatto che hanno già ricevuto l'aggiornamento obbligatorio e quindi non è necessario modificare i criteri di v3. Questo comportamento è il motivo per cui si dice che il server convertirà in modo dinamico il flag obbligatorio, poiché per quanto riguarda la versione, il relativo attributo obbligatorio verrà sempre archiviato usando il valore specificato durante il rilascio. Viene modificato in tempo reale solo quando si risponde a un controllo di aggiornamento da un utente finale.

Il comportamento descritto si applica solo se si rilascia un aggiornamento contrassegnato come mandatory. Il server modificherà una optional versione a mandatory solo se sono presenti aggiornamenti indeterminato mandatory , come illustrato in precedenza.

Una versione contrassegnata come mandatory non verrà mai convertita in optional.

Suggerimento

Questo parametro può essere impostato usando --mandatory o -m*

Nessun parametro di errore di rilascio duplicato

Questo parametro specifica che se l'aggiornamento è identico alla versione più recente nella distribuzione, l'interfaccia della riga di comando deve generare un avviso anziché un errore. È utile per gli scenari di integrazione continua in cui è previsto che piccole modifiche possano attivare versioni in cui non è stato modificato alcun codice di produzione.

Parametro di implementazione

Importante

Per rendere effettivo questo parametro, gli utenti finali devono eseguire la versione 1.6.0-beta+ (per Cordova) o 1.9.0-beta+ (per React Native) del plug-in CodePush. Se si rilascia un aggiornamento che specifica una proprietà di implementazione, nessun utente finale che esegue una versione precedente di Cordova o plug-in React Native sarà idoneo per l'aggiornamento. Finché non hai adottato la versione necessaria del plug-in CodePush specifico della piattaforma (come indicato in precedenza), non ti consigliamo di impostare un valore di implementazione nelle versioni dell'app, perché nessuno lo riceverà.

Questo parametro specifica la percentuale di utenti (come numero intero compreso tra 1 e 100) che deve essere idonea a ricevere questo aggiornamento. Può essere utile se vuoi "distribuire" nuove versioni con una parte del gruppo di destinatari dell'app (ad esempio, 25%), e ottenere feedback o watch per eccezioni o arresti anomali, prima di renderlo disponibile su larga scala per tutti. Se questo parametro non è impostato, per impostazione predefinita è 100%. È sufficiente impostarlo per limitare il numero di utenti che lo riceveranno.

Quando si usa la funzionalità di implementazione, è necessario tenere presenti alcune considerazioni aggiuntive:

1. Non è possibile rilasciare un nuovo aggiornamento a una distribuzione la cui versione più recente è un'implementazione "attiva" (la relativa proprietà di implementazione è non Null). L'implementazione deve essere "completata" (impostando la rollout proprietà su 100) prima di poter rilasciare ulteriori aggiornamenti alla distribuzione.

2. Se si esegue il rollback di una distribuzione la cui versione più recente è un'implementazione "attiva", il valore di implementazione verrà cancellato, disattivando in modo efficace il comportamento di implementazione

3. A differenza dei mandatory campi e description , quando si alza di livello una versione da una distribuzione a un'altra, la proprietà non verrà propagata rollout e quindi, se si vuole che la nuova versione (nella distribuzione di destinazione) abbia un valore di implementazione, è necessario impostarla in modo esplicito quando si chiama il promote comando.

Suggerimento

Questo parametro può essere impostato usando --rollout o -r*

Rilascio di Aggiornamenti (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]

Il release-react comando è una versione specifica React Native del comando "vanilla", release che supporta tutti gli stessi parametri (ad esempio , --mandatory--description), ma semplifica il processo di rilascio degli aggiornamenti eseguendo le attività aggiuntive seguenti:

1. Esecuzione del react-native bundle comando per generare il contenuto dell'aggiornamento (bundle JS e asset) che verrà rilasciato al server CodePush. Usa le impostazioni predefinite sensibili il più possibile (ad esempio, la creazione di una compilazione non di sviluppo, presupponendo che un file di voce iOS sia denominato index.ios.js), ma espone anche i parametri pertinenti react-native bundle per abilitare la flessibilità (ad esempio, --sourcemap-output).

2. Dedurre l'oggetto targetBinaryVersion di questa versione usando il nome della versione specificato nei file Info.plist del progetto (per iOS) e build.gradle (per Android).

Per illustrare la differenza che il release-react comando può fare, l'esempio seguente illustra come generare e rilasciare un aggiornamento per un'app React Native usando il comando "vanilla"release:

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

Per ottenere il comportamento equivalente con il release-react comando è necessario il comando seguente, che è meno soggetto a errori:

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

Parametro del nome dell'app

È lo stesso parametro di quello descritto nella sezione precedente.

Parametro del nome della distribuzione

È lo stesso parametro di quello descritto nella sezione precedente.

Parametro description

È lo stesso parametro di quello descritto nella sezione precedente.

Parametro obbligatorio

È lo stesso parametro di quello descritto nella sezione precedente.

Nessun parametro di errore di rilascio duplicato

È lo stesso parametro di quello descritto nella sezione precedente.

Parametro di implementazione

È lo stesso parametro di quello descritto nella sezione precedente. Se non specificato, la versione verrà resa disponibile a tutti gli utenti.

Parametro di versione binaria di destinazione

È lo stesso parametro di quello descritto nella sezione precedente. Se non viene specificato, per impostazione predefinita la destinazione è la versione esatta specificata nei file Info.plist dell'app (per iOS) e build.gradle (per Android).

Parametro del nome del bundle

Questo parametro specifica il nome file che deve essere usato per il bundle JS generato. Se non specificato, il nome del bundle standard verrà usato per la piattaforma specificata: main.jsbundle (iOS), index.android.bundle (Android) e index.windows.bundle (Windows).

Suggerimento

Questo parametro può essere impostato usando --bundle-name o -b*

Parametro di sviluppo

Questo parametro specifica se generare un bundle JS di sviluppo non codificato. Se non specificato, per impostazione predefinita viene predefinito dove false vengono disabilitati gli avvisi e il bundle viene minimizzato.

Suggerimento

Questo parametro può essere impostato usando --development*

Parametro disabilitato

È lo stesso parametro di quello descritto nella sezione precedente.

Parametro del file di immissione

Questo parametro specifica il percorso relativo del file JavaScript radice/voce dell'app. Se non specificato, per impostazione predefinita viene index.ios.js (per iOS), index.android.js (per Android) o index.windows.bundle (per Windows) se il file esiste o index.js in caso contrario.

Suggerimento

Questo parametro può essere impostato usando --entry-file o -e*

Parametro del file Gradle (solo Android)

Questo parametro specifica il percorso relativo del file build.gradle che l'interfaccia della riga di comando deve usare quando si tenta di impostare automaticamente la versione binaria di destinazione per la versione. Questo parametro è destinato solo agli scenari avanzati, poiché l'interfaccia della riga di comando può trovare automaticamente il file build.gradle del progetto in progetti di React Native "standard". Tuttavia, se il file gradle del progetto si trova in un percorso arbitrario, che l'interfaccia della riga di comando non riesce a individuare, l'uso di questo parametro consente di continuare a rilasciare gli aggiornamenti CodePush, senza dover impostare in modo esplicito il --target-binary-version parametro. Poiché build.gradle è un nome di file obbligatorio, specificando il percorso della cartella contenente o il percorso completo del file stesso otterrà lo stesso effetto.

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

Suggerimento

Questo parametro può essere impostato usando --gradle-file o -g*

Parametro file Plist (solo iOS)

Questo parametro specifica il percorso relativo del file Info.plist che l'interfaccia della riga di comando deve usare quando si tenta di impostare automaticamente la versione binaria di destinazione per la versione. Questo parametro è destinato solo agli scenari avanzati, poiché l'interfaccia della riga di comando può trovare automaticamente il file Info.plist del progetto nei progetti "standard React Native" e è possibile usare il --plistFilePrefix parametro per supportare i file plist per ambiente,ad esempio STAGING-Info.plist. Tuttavia, se il plist del progetto si trova in una posizione arbitraria, che l'interfaccia della riga di comando non riesce a individuare, l'uso di questo parametro consente di continuare a rilasciare gli aggiornamenti CodePush, senza dover impostare in modo esplicito il --target-binary-version parametro.

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

Suggerimento

Questo parametro può essere impostato usando --plist-file o -p*

Parametro prefisso file Plist (solo iOS)

Questo parametro specifica il prefisso del nome file del file Info.plist che l'interfaccia della riga di comando deve usare quando si tenta di impostare automaticamente la versione binaria di destinazione per la versione. Ciò può risultare utile se sono stati creati file plist per ambiente (ad esempio DEV-Info.plist, STAGING-Info.plist) e si desidera rilasciare gli aggiornamenti CodePush senza dover impostare in modo esplicito il --target-binary-version parametro. Specificando un --plist-file-prefixoggetto , l'interfaccia della riga di comando cercherà un file denominato <prefix>-Info.plist, anziché Info.plist (ovvero il comportamento predefinito), nelle posizioni seguenti: ./ios e ./ios/<appName>. Se il file plist del progetto non si trova in una di queste directory (ad esempio, l'app è un'app iOS nativa con viste RN incorporate) o usa una convenzione di denominazione di file completamente diversa, valutare l'uso del --plist-file parametro.

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

Parametro di output della mappa di origine

Questo parametro specifica il percorso relativo a dove deve essere scritto il file di mappa di origine del bundle JS generato. Se non specificato, le mappe di origine non verranno generate.

Suggerimento

Questo parametro può essere impostato usando --sourcemap-output o -s*

Nome di configurazione della compilazione

Nome della configurazione di compilazione che specifica la versione binaria a cui si vuole eseguire questa versione. Ad esempio, "Debug" o "Release" (solo iOS).

Nota

Questo parametro deve essere usato durante la compilazione con Xcode 11 e versioni successive per eseguire l'override della configurazione predefinita usata da Xcode.

Rilascio di Aggiornamenti (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]

Il release-cordova comando è una versione specifica di Cordova del comando "vaniglia", release che supporta tutti gli stessi parametri (ad esempio , --mandatory, --description), ma semplifica il processo di rilascio degli aggiornamenti eseguendo le attività aggiuntive seguenti:

1. Esecuzione del comando (o phonegap prepare) per generare il contenuto dell'aggiornamentocordova prepare (www folder) che verrà rilasciato al server CodePush.

2. Inferendo l'oggetto targetBinaryVersion di questa versione usando il nome della versione specificato nel file diconfig.xml del progetto.

Per illustrare la differenza che il release-cordova comando può fare, nell'esempio seguente viene illustrato come generare e rilasciare un aggiornamento per un'app Cordova usando il comando "vaniglia" release :

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

Ottenere il comportamento equivalente con il release-cordova comando richiederebbe il comando seguente, che è meno soggetto a errori:

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

Parametro nome app

Si tratta dello stesso parametro descritto nella sezione precedente.

Parametro nome distribuzione

Si tratta dello stesso parametro descritto nella sezione precedente.

Parametro Descrizione

Si tratta dello stesso parametro descritto nella sezione precedente.

Parametro obbligatorio

Si tratta dello stesso parametro descritto nella sezione precedente.

Nessun parametro di errore di rilascio duplicato

Si tratta dello stesso parametro descritto nella sezione precedente.

Parametro di implementazione

Si tratta dello stesso parametro descritto nella sezione precedente. Se non specificato, la versione verrà resa disponibile per tutti gli utenti.

Parametro della versione binaria di destinazione

Si tratta dello stesso parametro descritto nella sezione precedente. Se non specificato, il comando viene predefinito per indirizzare solo la versione specificata nei metadati del progetto (Info.plist se questo aggiornamento è per i client iOS e build.gradle per i client Android).

Parametro disabilitato

Si tratta dello stesso parametro descritto nella sezione precedente.

Parametro di compilazione

Questo parametro specifica se si vuole eseguire cordova build invece di cordova prepare (ovvero il comportamento predefinito), quando si generano gli asset Web aggiornati. È utile se il progetto include prima o dopo gli hook di compilazione (ad esempio, per transpile TypeScript) e quindi l'esecuzione cordova prepare di CodePush non è sufficiente per creare e rilasciare un aggiornamento. Se non specificato, il valore predefinito è false.

Suggerimento

Questo parametro può essere impostato usando --build o -b*

Patching Update Metadata

Dopo il rilascio di un aggiornamento, potrebbero verificarsi scenari in cui si vuole modificare uno o più attributi dei metadati, ad esempio si è dimenticato di contrassegnare una correzione di bug critica come obbligatoria, si vuole aumentare la percentuale di implementazione di un aggiornamento. È possibile eseguire facilmente questa operazione eseguendo il comando seguente:

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

Questo comando non consente di modificare il contenuto effettivo dell'aggiornamento di una versione, ad esempio www la cartella di un'app Cordova. Se si vuole rispondere a una versione identificata come interrotta, è consigliabile usare il comando di rollback per eseguirne immediatamente il rollback e quindi, se necessario, rilasciare un nuovo aggiornamento con la correzione appropriata quando è disponibile.

Oltre a <ownerName>/<appName> e deploymentName, tutti i parametri sono facoltativi e quindi è possibile usare questo comando per aggiornare un singolo attributo o tutti contemporaneamente. La chiamata al patch comando senza specificare alcun flag di attributo comporta un no-op.

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

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

Parametro etichetta

Indica quale versione (ad esempio, v23) si vuole aggiornare all'interno della distribuzione specificata. Se omesso, le modifiche richieste verranno applicate alla versione più recente nella distribuzione specificata. Per cercare l'etichetta per la versione da aggiornare, è possibile eseguire il appcenter codepush deployment history comando e fare riferimento alla Label colonna.

Parametro obbligatorio

Si tratta dello stesso parametro descritto nella sezione precedente e consente di aggiornare se la versione deve essere considerata obbligatoria o meno. Prestare attenzione che --mandatory e --mandatory true sono equivalenti, ma l'assenza di questo flag non è equivalente a --mandatory false. Se il parametro viene omesso, non verrà apportata alcuna modifica al valore della proprietà obbligatoria della versione di destinazione. Impostare questo parametro su --mandatory false per rendere esplicitamente facoltativo un rilascio.

Parametro Descrizione

Si tratta dello stesso parametro descritto nella sezione precedente e consente di aggiornare la descrizione per la versione (ad esempio, si è fatto un errore di digitazione durante il rilascio o si è dimenticato di aggiungere una descrizione a tutti). Se questo parametro viene omesso, non verrà apportata alcuna modifica al valore della proprietà description della versione di destinazione.

Parametro disabilitato

Si tratta dello stesso parametro descritto nella sezione precedente e consente di aggiornare se la versione deve essere disabilitata o meno. Prestare attenzione --disabled e --disabled true sono equivalenti, ma l'assenza di questo flag non equivale a --disabled false. Se il parametro viene omesso, non verrà apportata alcuna modifica al valore della proprietà disabilitata della versione di destinazione. Impostare questo parametro su per --disabled false rendere esplicitamente eseguibile una versione, se è stata disabilitata in precedenza.

Parametro di implementazione

Si tratta dello stesso parametro descritto nella sezione precedente e consente di aumentare la percentuale di implementazione della versione di destinazione. Questo parametro può essere impostato solo su un intero il cui valore è maggiore del valore di implementazione corrente. Inoltre, se si vuole "completare" l'implementazione e rendere disponibile la versione a tutti, è possibile impostare questo parametro su --rollout 100. Se questo parametro viene omesso, non verrà apportata alcuna modifica al valore del parametro di implementazione della versione di destinazione.

Inoltre, come accennato in precedenza, quando si rilascia un aggiornamento senza un valore di implementazione, viene trattato in modo equivalente per impostare l'implementazione su 100. Se è stato rilasciato un aggiornamento senza implementazione, non è possibile modificare la proprietà di implementazione tramite il patch comando poiché ciò sarebbe considerato ridurre la percentuale di implementazione.

Parametro della versione binaria di destinazione

Si tratta dello stesso parametro descritto nella sezione precedente e consente di aggiornare l'intervallo semver che indica quali versioni binarie una versione è compatibile con. Ciò può essere utile se si è fatto un errore quando si rilascia originariamente un aggiornamento (ad esempio, è stato specificato 1.0.0 ma 1.1.0è stato specificato ) o si vuole aumentare o ridurre l'intervallo di versione supportato da una versione (ad esempio, si è scoperto che una versione non funziona con 1.1.2 dopo tutto). Se questo parametro viene omesso, non verrà apportata alcuna modifica al valore della proprietà versione della versione di destinazione.

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

Promozione di Aggiornamenti

Dopo aver testato un aggiornamento in base a una distribuzione specifica (ad esempio, Staging), e si vuole promuoverlo "downstream" (ad esempio, dev-staging, staging-production>>), è possibile usare il comando seguente per copiare la versione da una distribuzione a un'altra:

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] 

Il promote comando crea una nuova versione per la distribuzione di destinazione, che include il codice esatto e i metadati (descrizione, obbligatoria e versione binaria di destinazione) dalla versione più recente della distribuzione di origine. Anche se è possibile usare il release comando per eseguire la migrazione manuale di un aggiornamento da un ambiente a un altro, il promote comando offre i vantaggi seguenti:

1. È più rapido, poiché non è necessario riassemblare gli asset di rilascio che si desidera pubblicare o ricordare la descrizione/versione binaria per la versione della distribuzione di origine.

2. È meno soggetto a errori, poiché l'operazione di promozione garantisce che l'esatta cosa già testata nella distribuzione di origine (ad esempio, ) diventerà attiva nella distribuzione di destinazione (ad esempio, StagingProduction).

È consigliabile che tutti gli utenti sfruttano automaticamente gli ambienti creati e creati Staging automaticamente e eseguono tutte le versioni direttamente in Staginge quindi promote da Staging a Production dopo il test Production appropriato.

Parametro description

Si tratta dello stesso parametro descritto nella sezione precedente e consente di eseguire l'override della descrizione che verrà usata per la versione promossa. Se non specificato, la nuova versione erediterà la descrizione dalla versione promossa.

Parametro disabilitato

Si tratta dello stesso parametro descritto nella sezione precedente e consente di eseguire l'override del valore del flag disabilitato che verrà usato per la versione alzata di livello. Se non specificato, la nuova versione erediterà la proprietà disabilitata dalla versione promossa.

Parametro obbligatorio

Si tratta dello stesso parametro descritto nella sezione precedente e consente di eseguire l'override del flag obbligatorio che verrà usato per la versione promossa. Se non specificato, la nuova versione erediterà la proprietà obbligatoria dalla versione promossa.

Nessun parametro di errore di rilascio duplicato

È lo stesso parametro di quello descritto nella sezione precedente.

Parametro di implementazione

Si tratta dello stesso parametro descritto nella sezione precedente e consente di specificare se la versione appena creata deve essere resa disponibile solo a una parte degli utenti. A differenza degli altri parametri dei metadati di versione (ad esempio, description), l'oggetto rollout di una versione non viene trasportato/ereditato come parte di una promozione e quindi è necessario impostarlo in modo esplicito se non si vuole che la versione appena creata sia disponibile per tutti gli utenti.

Parametro di versione binaria di destinazione

Si tratta dello stesso parametro descritto nella sezione precedente e consente di eseguire l'override della versione binaria di destinazione che verrà usata per la versione alzata di livello. Se non specificato, la nuova versione erediterà la proprietà della versione binaria di destinazione dalla versione promossa.

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

La cronologia delle versioni di una distribuzione non è modificabile, quindi non è possibile eliminare o rimuovere un aggiornamento dopo il rilascio. Tuttavia, se si rilascia un aggiornamento interrotto o contiene funzionalità indesiderate, è facile eseguirne il rollback usando il rollback comando :

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

L'esecuzione di questo comando crea una nuova versione per la distribuzione che include esattamente lo stesso codice e i metadati della versione precedente alla versione più recente. Si supponga, ad esempio, di aver rilasciato gli aggiornamenti seguenti all'app:

Versione	Descrizione	Obbligatorio
v1	Versione iniziale.	Sì
v2	Aggiunta di una nuova funzionalità	No
v3	Correzioni di bug	Sì

Se è stato eseguito il rollback comando in tale distribuzione, verrà creata una nuova versione (v4) che includeva il contenuto della v2 versione.

Versione	Descrizione	Obbligatorio
v1	Versione iniziale.	Sì
v2	Aggiunta di una nuova funzionalità	No
v3	Correzioni di bug	Sì
v4 (rollback da v3 a v2)	Aggiunta di una nuova funzionalità	No

Gli utenti finali che già acquisiti v3 ora verrebbero "spostati di nuovo" in v2 quando l'app esegue un controllo degli aggiornamenti. Inoltre, tutti gli utenti che erano ancora in esecuzione v2e, pertanto, non avevano mai acquisito v3, non riceveranno un aggiornamento perché eseguono già la versione più recente (questo è il motivo per cui il controllo degli aggiornamenti usa l'hash del pacchetto oltre all'etichetta di versione).

Se si vuole eseguire il rollback di una distribuzione a una versione diversa da quella precedente ,ad esempio ->v2, v3 è possibile specificare il parametro facoltativo--target-release:

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

Nota

La versione prodotta da un rollback verrà annotata nell'output del deployment history comando per identificarli più facilmente.

Visualizzazione della cronologia delle versioni

È possibile visualizzare una cronologia delle 50 versioni più recenti per una distribuzione di app specifica usando il comando seguente:

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

La cronologia visualizzerà tutti gli attributi relativi a ogni versione (ad esempio, etichetta, obbligatoria) e indicherà se sono state rilasciate versioni a causa di un'operazione di innalzamento di livello o rollback.

Inoltre, la cronologia visualizza le metriche di installazione per ogni versione. È possibile visualizzare i dettagli su come interpretare i dati delle metriche nella documentazione per il deployment list comando precedente.

Cancellazione della cronologia delle versioni

È possibile cancellare la cronologia delle versioni per una distribuzione usando il comando seguente:

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

Dopo l'esecuzione di questo comando, i dispositivi client configurati per ricevere gli aggiornamenti usando la chiave di distribuzione associata non riceveranno più gli aggiornamenti cancellati. Questo comando è irreversibile e quindi non deve essere usato in una distribuzione di produzione.

Firma codice

Che cos'è?

La firma del codice è un modo per creare firme digitali per i bundle che possono essere convalidati successivamente sul lato client prima dell'installazione.

Per quale motivo è necessario?

Gli sviluppatori vogliono sapere che il codice fornito è il codice scritto. La firma del codice è il meccanismo principale per fornire tale garanzia e può contribuire a mitigare o eliminare un'intera classe di attacchi man-in-the-middle.

Come funziona?

In primo luogo, lo sviluppatore genera una coppia di chiavi asimmetriche: la chiave privata verrà usata per le aggregazioni di firma; chiave pubblica per la verifica della firma del bundle. L'interfaccia della riga di comando di CodePush usa quindi la chiave privata per firmare i bundle durante releaserelease-react i comandi e release-cordova . La chiave pubblica viene fornita con l'applicazione per dispositivi mobili. Il controllo sulla generazione e la gestione delle chiavi è nelle mani dello sviluppatore.

Al termine del comando di rilascio, l'interfaccia della riga di comando calcola l'hash del contenuto del bundle e inserisce questo valore in un token JWT firmato con la chiave privata. Quando il plug-in CodePush scarica un bundle in un dispositivo, controlla il .codepushrelease file contenente il token JWT e convalida la firma JWT usando la chiave pubblica. Se la convalida non riesce, l'aggiornamento non viene installato.

Requisiti per l'uso di questa funzionalità

Se si prevede di usare questa funzionalità, seguire questa procedura:

1. Produrre un nuovo aggiornamento binario, incluso

   • aggiornamento del plug-in CodePush che supporta la firma del codice
   • configurare l'SDK per il push di codice per l'uso della chiave pubblica (vedere le sezioni pertinenti React Native SDK (iOS, Android) o Cordova SDK per informazioni dettagliate.

2. Produrre un nuovo aggiornamento CodePush destinato alla nuova versione binaria e specifica un --private-key-path valore di parametro (o -k)

Fare riferimento alle tabelle di compatibilità per identificare se la funzionalità di firma del codice è supportata all'interno dell'SDK/interfaccia della riga di comando:

CodePush SDK	Versione da cui supporta la firma del codice	Piattaforme supportate	Versione minima dell'interfaccia della riga di comando codePush richiesta
react-native-code-push	5.1.0	Android, iOS	2.1.0
cordova-plugin-code-push	1.10.0	Android, iOS	2.1.2

Generazione di chiavi

La firma del codice supporta chiavi RSA con codifica PEM (non certificati) per la firma. È possibile generarli tramite openssl, come illustrato di seguito:

# 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

Esempio di chiavi generate:

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

Rilascio dell'aggiornamento firmato

Per rilasciare l'aggiornamento firmato, è necessario usare --private-key-path l'opzione (o -k) per release o release-react comando .