Veröffentlichen von CodePush-Updates mithilfe der App Center-CLI

Artikel
03/17/2024

Wichtig

Visual Studio App Center wird am 31. März 2025 eingestellt. Sie können Visual Studio App Center zwar weiterhin verwenden, bis es vollständig eingestellt ist, es gibt jedoch mehrere empfohlene Alternativen, zu denen Sie eine Migration in Betracht ziehen können.

Erfahren Sie mehr über Supportzeitpläne und Alternativen.

Installation

Installieren von Node.js
Installieren Sie die App Center-CLI: npm install -g appcenter-cli

Erste Schritte

Erstellen Sie ein App Center-Konto , oder melden Sie sich mit dem Befehl über die CLI an appcenter login .
Registrieren Sie Ihre App bei CodePush, und geben Sie Ihre App optional für andere Entwickler in Ihrem Team weiter.
CodePush-ify Ihrer App, und verweisen Sie auf die Bereitstellung, die Sie verwenden möchten (Apache Cordova und React Native).
Release und Update für Ihre App.

Kontoverwaltung

Bevor Sie mit der Veröffentlichung von App-Updates beginnen können, melden Sie sich mit Ihrem vorhandenen CodePush-Konto an, oder erstellen Sie ein neues App Center-Konto. Führen Sie hierzu den folgenden Befehl aus, nachdem Sie die CLI installiert haben:

appcenter login

Mit diesem Befehl wird ein Browser gestartet, in dem Sie aufgefordert werden, sich entweder bei Ihrem GitHub- oder Microsoft-Konto zu authentifizieren. Nach der Authentifizierung wird ein CodePush-Konto erstellt, das mit Ihrer GitHub/MSA-Identität verknüpft ist, und es wird ein Zugriffsschlüssel generiert, den Sie zum Anmelden kopieren bzw. in die CLI einfügen können.

Hinweis

Nach der Registrierung werden Sie automatisch mit der CLI angemeldet, sodass Sie sich nicht erneut auf demselben Computer anmelden müssen, bis Sie sich explizit abmelden.

Authentifizierung

Die meisten Befehle innerhalb der App Center-CLI erfordern eine Authentifizierung. Bevor Sie also mit der Verwaltung Ihres Kontos beginnen können, melden Sie sich mit dem GitHub- oder Microsoft-Konto an, das Sie bei der Registrierung verwendet haben. Führen Sie dazu den folgenden Befehl aus:

appcenter login

Mit diesem Befehl wird ein Browserfenster gestartet, in dem Sie aufgefordert werden, sich entweder bei Ihrem GitHub- oder Microsoft-Konto zu authentifizieren. Es generiert einen Zugriffsschlüssel, der in die CLI kopiert und eingefügt werden kann (Sie werden dazu aufgefordert). Sie sind jetzt erfolgreich authentifiziert und können Ihr Browserfenster sicher schließen.

Wenn Sie überprüfen möchten, ob Sie bereits angemeldet sind, können Sie den folgenden Befehl ausführen, um die E-Mail-Adresse für Ihre aktuelle Authentifizierungssitzung, Ihren Benutzernamen und Ihren Anzeigenamen anzuzeigen:

appcenter profile list

Wenn Sie sich über die CLI anmelden, bleibt Ihr Zugriffsschlüssel für die Dauer Ihrer Sitzung auf dem Datenträger erhalten, sodass Sie sich nicht bei jedem Versuch, auf Ihr Konto zuzugreifen, anmelden müssen. Führen Sie den folgenden Befehl aus, um die Sitzung zu beenden und diesen Zugriffsschlüssel zu löschen:

appcenter logout

Wenn Sie vergessen, sich von einem Computer abzumelden, auf dem Sie keine laufende Sitzung verlassen möchten (z. B. den Laptop Ihres Freundes), können Sie die folgenden Befehle verwenden, um alle aktuellen Anmeldesitzungen aufzulisten und zu entfernen.

appcenter tokens list
appcenter tokens delete <machineName>

Zugriffstoken

Um sich beim CodePush-Dienst zu authentifizieren, ohne einen Browser zu starten oder Ohne Ihre GitHub- oder Microsoft-Anmeldeinformationen verwenden zu müssen (z. B. in einer CI-Umgebung), können Sie den folgenden Befehl ausführen, um ein "Zugriffstoken" zu erstellen (zusammen mit einem Namen, der beschreibt, wofür es vorgesehen ist):

appcenter tokens create -d "Azure DevOps Integration"

Der Schlüssel wird nur einmal angezeigt. Denken Sie also daran, ihn bei Bedarf irgendwo zu speichern! Nachdem Sie den neuen Schlüssel erstellt haben, können Sie dessen Wert mithilfe des --token Flags des Befehls angeben, mit dem login Sie die "headless"-Authentifizierung verwenden können, anstatt einen Browser zu starten.

appcenter login --token <accessToken>

Bei der Anmeldung mit dieser Methode wird das Zugriffstoken beim Abmelden nicht automatisch ungültig und kann in zukünftigen Sitzungen verwendet werden, bis es explizit vom App Center-Server entfernt wird. Sie sollten sich jedoch abmelden, nachdem Ihre Sitzung abgeschlossen ist, um Ihre Anmeldeinformationen vom Datenträger zu entfernen.

App-Verwaltung

Erstellen Sie vor dem Bereitstellen von Updates mithilfe des folgenden Befehls eine App mit App Center:

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

Wenn Ihre App sowohl für Android als auch für iOS verwendet wird, wird dringend empfohlen, separate Apps mit CodePush zu erstellen. Eine für jede Plattform. Auf diese Weise können Sie Updates für sie separat verwalten und freigeben, was auf lange Sicht die Dinge vereinfacht. Die meisten Personen suffixieren den App-Namen mit -Android und -iOS. Beispiel:

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

Hinweis

Die Verwendung derselben App für Android und iOS kann zu Installationsausnahmen führen, da das für iOS erstellte CodePush-Updatepaket einen anderen Inhalt als das für Android erstellte Update aufweist.

Tipp

Eine wichtige neue Funktionalität in der App Center-CLI ist die Möglichkeit, eine App mithilfe appcenter apps set-current <ownerName>/<appName>von als aktuelle App festzulegen. Wenn Sie eine App als aktuelle App festlegen, müssen Sie das Flag nicht in anderen CLI-Befehlen verwenden -a . Beispielsweise kann der Befehl appcenter codepush deployment list -a <ownerName>/<appName> auf appcenter codepush deployment list gekürzt werden, wenn die aktuelle App festgelegt ist. Mithilfe von können Sie überprüfen, welche App als aktuelle App appcenter apps get-currentIhres Kontos festgelegt ist. Durch das Festlegen der aktuellen App wird die Eingabe der meisten CLI-Befehle verkürzt.

Mit dem ursprünglichen CodePush verfügten Apps automatisch über zwei Bereitstellungen (Staging und Production). In App Center müssen Sie sie mit den folgenden Befehlen selbst erstellen:

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

Nachdem Sie die Bereitstellungen erstellt haben, können Sie mithilfe appcenter codepush deployment list --displayKeysvon auf die Bereitstellungsschlüssel für beide Bereitstellungen zugreifen, die Sie verwenden können, um Ihre mobilen Clients über die jeweiligen SDKs zu konfigurieren (Details zu Cordova und React Native).

Wenn Ihnen der Name, den Sie einer App gegeben haben, nicht gefällt, können Sie sie jederzeit mit dem folgenden Befehl umbenennen:

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

Warnung

Das Ändern des App-Namens kann zu unerwarteten Problemen bei der Branchkonfiguration und -builds für etwa 48 Stunden führen.

Wenn Sie eine App irgendwann nicht mehr benötigen, können Sie sie mit dem folgenden Befehl vom Server entfernen:

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

Seien Sie bei der Ausführung dieses Befehls vorsichtig, da alle Apps, die für die Verwendung konfiguriert wurden, keine Updates mehr erhalten.

Wenn Sie schließlich alle Apps auflisten möchten, die Sie beim App Center-Server registriert haben, führen Sie den folgenden Befehl aus:

appcenter apps list

App-Zusammenarbeit

Wenn Sie mit anderen Entwicklern an derselben CodePush-App arbeiten, können Sie diese mithilfe des App Center-Portals als Mitarbeiter hinzufügen, indem Sie die folgenden Anweisungen befolgen:

Wählen Sie im App Center-Portal die App aus, für die Sie Mitarbeiter hinzufügen möchten.
Klicken Sie im Navigationsbereich auf der linken Seite auf Einstellungen.
Klicken Sie auf den Link Projektmitarbeiter.
Geben Sie im Menü "Mitarbeiter" die E-Mail-Adressen der Projektmitarbeiter ein, um sie einzuladen.

Wichtig

Das App Center-Feature "Mitarbeiter" erwartet, dass sich jeder Mitarbeiter bereits mit der angegebenen E-Mail-Adresse bei App Center registriert hat.

Nach dem Hinzufügen verfügen alle Projektmitarbeiter sofort über die folgenden Berechtigungen in der freigegebenen App:

Anzeigen der App, ihrer Projektmitarbeiter, Bereitstellungen und des Releaseverlaufs
Veröffentlichen von Updates für alle Bereitstellungen der App
Höherstufen eines Updates zwischen einer der Bereitstellungen der App
Zurücksetzen aller Bereitstellungen der App
Patchen von Releases innerhalb einer der Bereitstellungen der App

Projektmitarbeiter können keine der folgenden Aktionen ausführen:

Umbenennen oder Löschen der App
Erstellen, Umbenennen oder Löschen neuer Bereitstellungen in der App
Löschen des Releaseverlaufs einer Bereitstellung
Hinzufügen oder Entfernen von Projektmitarbeitern aus der App (*)

Hinweis

Ein Entwickler kann sich selbst als Mitarbeiter aus einer App entfernen, die für ihn freigegeben wurde.

Wenn jemand im Laufe der Zeit nicht mehr mit Ihnen an einer App arbeitet, können Sie sie auch als Mitarbeiter über dieses Mitarbeitermenü im Portal entfernen.

Jedes Mal, wenn Sie alle Mitarbeiter auflisten möchten, die einer App hinzugefügt wurden, können Sie das Menü "Mitarbeiter" im Portal besuchen.

Bereitstellungsverwaltung

Aus Der Perspektive von CodePush ist eine App eine benannte Gruppierung für eine oder mehrere "Bereitstellungen". Während die App einen konzeptionellen "Namespace" oder "Bereich" für eine plattformspezifische Version einer App (z. B. den iOS-Port der Foo-App) darstellt, stellen ihre Bereitstellungen das eigentliche Ziel für die Veröffentlichung von Updates (für Entwickler) und die Synchronisierung von Updates (für Endbenutzer) dar. Bereitstellungen ermöglichen es Ihnen, mehrere "Umgebungen" für jede App zu einem bestimmten Zeitpunkt im Flug zu haben, und helfen Ihnen dabei, die Realität zu modellieren, dass Apps in der Regel von der persönlichen Umgebung eines Entwicklers in eine Test-/QA-/Stagingumgebung wechseln, bevor sie schließlich in die Produktion gelangen.

Hinweis

Wie Sie unten sehen werden, erfordern die releaseBefehle , promote und rollback sowohl einen App-Namen als auch einen Bereitstellungsnamen, um zu funktionieren, da es die Kombination der beiden ist, die einen Verteilungspunkt eindeutig identifiziert (z. B. möchte ich ein Update meiner iOS-App für meine Betatester veröffentlichen).

Wenn eine App beim CodePush-Dienst registriert ist, empfehlen wir, die folgenden Bereitstellungen zu erstellen: Staging und Production. Auf diese Weise können Sie mit der Veröffentlichung von Updates in einer internen Umgebung beginnen, in der Sie jedes Update gründlich testen können, bevor Sie sie an Ihre Endbenutzer übertragen. Dieser Workflow ist wichtig, um sicherzustellen, dass Ihre Releases für den Massenverbrauch bereit sind, und ist eine Praxis, die im Web seit langem etabliert ist.

Wenn eine Staging- und Produktionsversion Ihrer App ausreicht, um Ihre Anforderungen zu erfüllen, müssen Sie nichts anderes tun. Wenn Sie jedoch eine Alpha-, Entwicklungs- usw. -Bereitstellung wünschen, können Sie diese problemlos mit dem folgenden Befehl erstellen:

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

Wie bei Apps können Sie auch Bereitstellungen entfernen und umbenennen, indem Sie die folgenden Befehle verwenden:

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

Wenn Sie die Liste der Bereitstellungen anzeigen möchten, die eine bestimmte App enthält, können Sie den folgenden Befehl ausführen:

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

Die Installationsmetriken haben die folgende Bedeutung:

Aktiv : Die Anzahl der erfolgreichen Installationen, auf denen derzeit dieses Release ausgeführt wird (wenn der Benutzer Ihre App geöffnet hat, wird diese Version angezeigt bzw. ausgeführt). Diese Nummer ändert sich, wenn Endbenutzer ein Upgrade auf und von diesem Release durchführen. Diese Metrik zeigt sowohl die Gesamtzahl der aktiven Benutzer als auch den Prozentsatz Ihrer Gesamtzielgruppe an. Dies erleichtert die Ermittlung der Verteilung von Updates, die Ihre Benutzer derzeit ausführen, sowie die Beantwortung von Fragen wie "Wie viele meiner Benutzer haben mein neuestes Update erhalten?".
Gesamt: Die Gesamtzahl der erfolgreichen Installationen, die dieses Update insgesamt erhalten hat. Diese Zahl steigt nur, wenn neue Benutzer/Geräte sie installieren, sodass sie immer eine Obermenge der gesamtzahl der aktiven Anzahl ist. Ein Update gilt als erfolgreich, sobald notifyApplicationReady (oder sync) nach der Installation aufgerufen wird. Zwischen dem Zeitpunkt, in dem ein Update heruntergeladen und als erfolgreich markiert wird, wird es als "ausstehendes" Update gemeldet (weitere Details finden Sie unten).
Ausstehend : Gibt an, wie oft dieses Release heruntergeladen, aber noch nicht installiert wurde (die App wurde neu gestartet, um die Änderungen zu übernehmen). Diese Metrik erhöht sich also, wenn Updates heruntergeladen werden, und nimmt ab, wenn die entsprechenden heruntergeladenen Updates installiert werden. Diese Metrik gilt in erster Linie für Updates, die nicht für die sofortige Installation konfiguriert sind, und liefert ein umfassenderes Bild der Releaseeinführung für Apps, die zum Anwenden eines Updates auf eine Fortführung oder einen Neustart der App angewiesen sind (z. B. möchte ich ein Rollback für ein Update durchführen, und ich bin gespannt, ob es noch jemand heruntergeladen hat). Wenn Sie Updates für die sofortige Installation konfiguriert haben und weiterhin ausstehende Updates gemeldet werden, ist es wahrscheinlich, dass Sie (oder sync) nicht beim App-Start aufrufen notifyApplicationReady . Dies ist die Methode, die mit dem Senden von Installationsberichten beginnt und installierte Updates als erfolgreich markiert.
Rollbacks : Gibt an, wie oft für dieses Release automatisch ein Rollback auf dem Client ausgeführt wurde. Im Idealfall sollte diese Zahl null sein, und in diesem Fall wird diese Metrik nicht einmal angezeigt. Wenn Sie jedoch ein Update veröffentlicht haben, das einen Absturz im Rahmen des Installationsvorgangs beinhaltet, führt das CodePush-Plug-In den Endbenutzer zurück zur vorherigen Version und meldet dieses Problem an den Server zurück. Dies ermöglicht es Ihren Endbenutzern, die Blockierung aufzuheben, wenn Releases unterbrochen werden. Wenn Sie diese Telemetriedaten in der CLI anzeigen, können Sie fehlerhafte Releases identifizieren und darauf reagieren, indem Sie ein Rollback auf dem Server durchführen.
Rollout : Gibt den Prozentsatz der Benutzer an, die berechtigt sind, dieses Update zu erhalten. Diese Eigenschaft wird nur für Releases angezeigt, die einen "aktiven" Rollout darstellen und daher einen Rolloutprozentsatz von weniger als 100 % aufweisen. Da eine Bereitstellung zu einem bestimmten Zeitpunkt nur einen aktiven Rollout haben kann, wäre diese Bezeichnung nur für das neueste Release innerhalb einer Bereitstellung vorhanden.
Deaktiviert : Gibt an, ob das Release als deaktiviert markiert wurde oder nicht, und kann daher von Endbenutzern heruntergeladen werden. Diese Eigenschaft wird nur für versionen angezeigt, die deaktiviert sind.

Wenn die Metrikzelle meldet No installs recorded, gibt dies an, dass der Server für dieses Release keine Aktivität gesehen hat. Dies kann entweder daran sein, dass die Plug-In-Versionen, die Telemetrieunterstützung enthalten, ausgeschlossen wurden, oder dass noch keine Endbenutzer mit dem CodePush-Server synchronisiert haben. Sobald eine Installation erfolgt, sehen Sie, dass Metriken in der CLI für das Release aufgefüllt werden.

Veröffentlichen von Updates

Nachdem Ihre App für die Abfrage von Updates für den App Center-Server konfiguriert wurde, können Sie mit der Veröffentlichung von Updates beginnen. Um sowohl Einfachheit als auch Flexibilität zu gewährleisten, enthält die App Center-CLI drei verschiedene Befehle für die Veröffentlichung von Updates:

Allgemein : Gibt ein Update für den App Center-Server frei, das von einem externen Tool oder Buildskript (z. B. einer Gulp-Aufgabe, dem react-native bundle Befehl) generiert wurde. Dies bietet die größte Flexibilität bei der Anpassung in vorhandene Workflows, da es sich ausschließlich um codePush-spezifische Schritte handelt und ihnen den app-spezifischen Kompilierungsprozess überlässt.
React Native: Verwendet die gleiche Funktionalität wie der allgemeine Releasebefehl, übernimmt aber auch die Aufgabe, die aktualisierten App-Inhalte für Sie (JS-Paket und -Ressourcen) zu generieren, anstatt sowohl als auch react-native bundle auszuführenappcenter codepush release.
Cordova : Verwendet die gleiche Funktionalität wie der allgemeine Releasebefehl, übernimmt aber auch die Aufgabe, das App-Update für Sie vorzubereiten, anstatt zu verlangen, dass Sie sowohl cordova prepare (oder phonegap prepare) als auch dann appcenter codepush releaseausführen müssen.

Welche dieser Befehle Sie verwenden sollten, hängt hauptsächlich von Anforderungen oder Vorlieben ab. Es wird jedoch empfohlen, den relevanten plattformspezifischen Befehl zu starten (da er die Benutzeroberfläche erheblich vereinfacht) und dann den Allgemeinen release Befehl zu verwenden, wenn eine größere Kontrolle erforderlich ist.

Hinweis

Nur die 50 neuesten Releases in einer Bereitstellung können von den Clients ermittelt und heruntergeladen werden.

Veröffentlichen von Updates (Allgemein)

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

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

App-Name-Parameter

Dieser Parameter gibt den Namen der App Center-App an, für die dieses Update veröffentlicht wird. Wenn Sie nachschlagen möchten, können Sie den appcenter apps list Befehl ausführen, um Ihre Liste der Apps anzuzeigen.

Parameter "Inhalt aktualisieren"

Dieser Parameter gibt den Speicherort des aktualisierten App-Codes und der Ressourcen an, die Sie freigeben möchten. Sie können entweder eine einzelne Datei (z. B. ein JS-Paket für eine React Native-App) oder einen Pfad zu einem Verzeichnis (z. B. den /platforms/ios/www Ordner für eine Cordova-App) angeben. Sie müssen nicht mehrere Dateien oder Verzeichnisse zippen, um diese Änderungen bereitzustellen, da die CLI sie automatisch für Sie zippt.

Es ist wichtig, dass sich der angegebene Pfad auf die plattformspezifische, vorbereitete/gebündelte Version Ihrer App bezieht. In der folgenden Tabelle wird beschrieben, welchen Befehl Sie vor der Freigabe ausführen sollten, sowie den Speicherort, auf den Sie später mithilfe des updateContentsPath Parameters verweisen können:

Plattform	Prepare-Befehl	Paketpfad (relativ zum Projektstamm)
Cordova (Android)	`cordova prepare android`	`./platforms/android/assets/www` Verzeichnis
Cordova (iOS)	`cordova prepare ios`	`./platforms/ios/www` Verzeichnis
React Native Wo/Assets (Android)	`react-native bundle --platform android --entry-file <entryFile> --bundle-output <bundleOutput> --dev false`	Wert der `--bundle-output` Option.
React Native mit Assets (Android)	`react-native bundle --platform android --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false`	Wert der `--assets-dest` Option, die ein neu erstelltes Verzeichnis darstellen soll, das die Ressourcen und das JS-Paket der App enthält
React Native Wo/Assets (iOS)	`react-native bundle --platform ios --entry-file <entryFile> --bundle-output <bundleOutput> --dev false`	Wert der `--bundle-output` Option
React Native w/assets (iOS)	`react-native bundle --platform ios --entry-file <entryFile> --bundle-output <releaseFolder>/<bundleOutput> --assets-dest <releaseFolder> --dev false`	Wert der `--assets-dest` Option, die ein neu erstelltes Verzeichnis darstellen soll, das die Ressourcen und das JS-Paket der App enthält

Binärer Zielversionsparameter

Dieser Parameter gibt die Store-/Binärversion der Anwendung an, für die Sie das Update veröffentlichen, sodass nur Benutzer, für die diese Version ausgeführt wird, das Update erhalten, während Benutzer, die eine ältere oder neuere Version der App-Binärdatei ausführen, dies nicht. Dies ist aus folgenden Gründen nützlich:

Wenn ein Benutzer eine ältere Binärversion ausführt, ist es möglich, dass es breaking Changes im CodePush-Update gibt, die nicht mit dem kompatibel sind, was er gerade ausführt.
Wenn ein Benutzer eine neuere Binärversion ausführt, wird davon ausgegangen, dass das, was er ausführt, neuer (und möglicherweise inkompatibel) mit dem CodePush-Update ist.

Wenn Sie jemals ein Update für mehrere Versionen der App Store-Binärdatei verwenden möchten, können Sie den Parameter auch als Semverbereichsausdruck angeben. Auf diese Weise erhält jedes Clientgerät, auf dem eine Version der Binärdatei ausgeführt wird, die den Bereichsausdruck (semver.satisfies(version, range) rückgabe) trueerfüllt, das Update. Beispiele für gültige Semverbereichsausdrücke sind:

Bereichsausdruck	Wer erhält das Update?
`1.2.3`	Nur Geräte, auf denen die spezifische Binärversion `1.2.3` Ihrer App ausgeführt wird
`*`	Jedes Gerät, das für die Nutzung von Updates aus Ihrer CodePush-App konfiguriert ist
`1.2.x`	Geräte mit Hauptversion 1, Nebenversion 2 und jeder Patchversion Ihrer App
`1.2.3 - 1.2.7`	Geräte, auf denen eine beliebige Binärversion zwischen `1.2.3` (inklusive) und `1.2.7` (inklusive) ausgeführt wird
`>=1.2.3 <1.2.7`	Geräte, auf denen eine beliebige Binärversion zwischen `1.2.3` (inklusive) und `1.2.7` (exklusiv) ausgeführt wird
`1.2`	Entspricht `>=1.2.0 <1.3.0`.
`~1.2.3`	Entspricht `>=1.2.3 <1.3.0`.
`^1.2.3`	Entspricht `>=1.2.3 <2.0.0`.

Hinweis

Wenn der Semverausdruck der App mit einem speziellen Shellzeichen oder Operator wie >, ^oder ** * beginnt, wird der Befehl möglicherweise nicht ordnungsgemäß ausgeführt, wenn Sie den Wert nicht in Anführungszeichen umschließen, da die Shell nicht die richtigen Werte für unseren CLI-Prozess liefert. Daher empfiehlt es sich, den Parameter der App targetBinaryVersion beim Aufrufen des release Befehls in doppelte Anführungszeichen umzuschließen, z. B appcenter codepush release -a <ownerName>/<appName> updateContents ">1.2.3". .

In der folgenden Tabelle wird der Versionswert beschrieben, den CodePush erwartet, dass der Semverbereich Ihres Updates für jeden app-Typ erfüllt wird:

Plattform	Quelle der Binärversion
Cordova	Das `<widget version>` Attribut in der config.xml-Datei
React Native (Android)	Die `android.defaultConfig.versionName` -Eigenschaft in der Datei build.gradle des Projekts
React Native (iOS)	Der `CFBundleShortVersionString` Schlüssel in der Datei Info.plist
React Native (Windows)	Der `<Identity Version>` Schlüssel in der Datei "Package.appxmanifest "

Hinweis

Wenn der Binärversion in den Metadatendateien eine Patchversion fehlt, 2.0z. B. , wird sie als Patchversion von 0behandelt, 2.0 -> 2.0.0d. h. .

Parameter "Bereitstellungsname"

Dieser Parameter gibt an, für welche Bereitstellung Sie das Update freigeben möchten. Die Standardeinstellung ist Staging, aber wenn Sie bereit sind, die Bereitstellung in oder einer Ihrer eigenen benutzerdefinierten Bereitstellungen durchzuführen Production, legen Sie dieses Argument explizit fest.

Tipp

Der Parameter kann entweder --deployment-name mit oder -dfestgelegt werden.

Description-Parameter

Dieser Parameter stellt ein optionales "Änderungsprotokoll" für die Bereitstellung bereit. Der Wert wird auf den Client umgedreht, sodass Ihre App beim Erkennen des Updates auswählen kann, ob sie dem Endbenutzer angezeigt werden soll (z. B. über einen Dialog "Was ist neu?"). Diese Zeichenfolge akzeptiert Steuerzeichen wie \n und \t , sodass Sie Leerzeichenformatierungen in Ihre Beschreibungen einfügen können, um die Lesbarkeit zu verbessern.

Tipp

Dieser Parameter kann mit --descriptionfestgelegt werden.

Parameter deaktiviert

Dieser Parameter gibt an, ob ein Update von Endbenutzern heruntergeladen werden kann oder nicht. Wenn nicht angegeben, wird das Update nicht deaktiviert. Stattdessen laden Benutzer es in dem Moment herunter, in dem Ihre App aufruft sync. Dieser Parameter kann nützlich sein, wenn Sie ein Update freigeben möchten, das nicht sofort verfügbar ist, bis Sie es explizit patchen und möchten, dass Endbenutzer es herunterladen (z. B. ein Ankündigungsblogbeitrag wurde live geschaltet).

Tipp

Dieser Parameter kann entweder mit --disabled oder -xfestgelegt werden.

Erforderlicher Parameter

Dieser Parameter gibt an, ob das Update als obligatorisch betrachtet werden soll oder nicht (z. B. enthält es ein kritisches Sicherheitsfix). Dieses Attribut wird auf den Client umgedreht, der dann entscheiden kann, ob und wie er es erzwingen möchte.

Hinweis

Dieser Parameter ist ein "Flag", sodass sein Fehlen darauf hinweist, dass das Release optional ist, und sein Vorhandensein gibt an, dass es obligatorisch ist. Sie können einen Wert angeben (z. B. ), die Angabe --mandatory ist jedoch ausreichend, --mandatory trueum eine Version als obligatorisch zu kennzeichnen.

Das obligatorische Attribut ist eindeutig, da der Server es bei Bedarf dynamisch ändert, um sicherzustellen, dass die Semantik der Versionen der App für Ihre Endbenutzer beibehalten wird. Stellen Sie sich beispielsweise vor, Sie haben die folgenden drei Updates für Ihre App veröffentlicht:

Freigabe	Erforderlich?
v1	Nein
V2	Yes
V3	No

Wenn ein Endbenutzer derzeit ausführt v1und den Server nach einem Update fragt, antwortet er mit v3 (da dies der neueste ist), aber er konvertiert das Release dynamisch in "obligatorisch", da dazwischen ein obligatorisches Update veröffentlicht wurde. Dieses Verhalten ist wichtig, da der in v3 enthaltene Code inkrementell zu dem in v2enthalten ist. Was auch immer obligatorisch gemacht wird v2 , ist v3 weiterhin obligatorisch für alle, die nicht bereits erworben v2haben.

Wenn ein Endbenutzer derzeit ausführt v2und den Server nach einem Update fragt, antwortet er mit v3, lässt die Version jedoch optional. Dies liegt daran, dass sie bereits das obligatorische Update erhalten haben und daher die Richtlinie von v3nicht geändert werden muss. Dieses Verhalten ist der Grund, warum wir sagen, dass der Server das obligatorische Flag "dynamisch konvertiert", da das obligatorische Attribut, soweit das Release geht, immer mit dem Wert gespeichert wird, den Sie beim Freigeben angegeben haben. Sie wird nur bei Bedarf bei Bedarf geändert, wenn ein Endbenutzer auf eine Updateüberprüfung reagiert.

Das beschriebene Verhalten gilt nur für Sie, wenn Sie ein Update freigeben, das als mandatorymarkiert ist. Der Server ändert eine optional Version nur dann in mandatory , wenn wie oben dargestellt vermischte mandatory Updates vorhanden sind.

Ein Release, das als mandatory gekennzeichnet ist, wird nie in optionalkonvertiert.

Tipp

Dieser Parameter kann entweder mit oder --mandatory festgelegt werden. -m*

Kein Fehlerparameter für doppelte Freigaben

Dieser Parameter gibt an, dass die CLI anstelle eines Fehlers eine Warnung generieren soll, wenn das Update mit der neuesten Version der Bereitstellung identisch ist. Es ist nützlich für Continuous Integration-Szenarien, in denen erwartet wird, dass kleine Änderungen Möglicherweise Releases auslösen, wenn sich kein Produktionscode geändert hat.

Rolloutparameter

Wichtig

Damit dieser Parameter wirksam wird, müssen Ihre Endbenutzer die Version 1.6.0-beta+ (für Cordova) oder 1.9.0-beta+ (für React Native) des CodePush-Plug-Ins ausführen. Wenn Sie ein Update freigeben, das eine Rollouteigenschaft angibt, ist kein Endbenutzer, der eine ältere Version des Cordova- oder React Native-Plug-Ins ausführt, für das Update berechtigt. Bis Sie die erforderliche Version des plattformspezifischen CodePush-Plug-Ins (wie bereits erwähnt) übernommen haben, wird nicht empfohlen, einen Rolloutwert für die Versionen der App festzulegen, da es am Ende niemand erhält.

Dieser Parameter gibt den Prozentsatz der Benutzer (als ganze Zahl zwischen 1 und 100) an, die für den Empfang dieses Updates berechtigt sein sollten. Es kann hilfreich sein, wenn Sie neue Releases mit einem Teil der App-Zielgruppe (z. B. 25 %) "fliegen" und Feedback erhalten oder für Ausnahmen oder Abstürze watch möchten, bevor Sie sie allgemein für alle verfügbar machen. Wenn dieser Parameter nicht festgelegt ist, wird standardmäßig festgelegt 100%. Sie müssen es nur so festlegen, dass die Anzahl der Benutzer begrenzt wird.

Bei der Verwendung der Rolloutfunktion sind einige zusätzliche Überlegungen zu beachten:

Sie können kein neues Update für eine Bereitstellung freigeben, deren neueste Version ein "aktiver" Rollout ist (die Rollouteigenschaft ist ungleich NULL). Der Rollout muss "abgeschlossen" sein (festlegen der rollout Eigenschaft auf 100), bevor Sie weitere Updates für die Bereitstellung freigeben können.
Wenn Sie ein Rollback für eine Bereitstellung durchführen, deren neueste Version ein "aktiver" Rollout ist, wird der Rolloutwert gelöscht, wodurch das Rolloutverhalten effektiv deaktiviert wird.
Im Gegensatz zu den mandatory Feldern und description wird die -Eigenschaft nicht weitergegeben, wenn Sie ein Release von einer Bereitstellung in eine andere höherstufen rollout . Wenn Sie also möchten, dass das neue Release (in der Zielbereitstellung) einen Rolloutwert aufweisen soll, müssen Sie ihn explizit festlegen, wenn Sie den promote Befehl aufrufen.

Tipp

Dieser Parameter kann entweder mit oder --rollout festgelegt werden. -r*

Veröffentlichen von Updates (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]

Der release-react Befehl ist eine React Native spezifische Version des "vanilla"release-Befehls, der alle gleichen Parameter unterstützt (z. B. , --description), aber den Prozess der Veröffentlichung von Updates vereinfacht, --mandatoryindem sie die folgenden zusätzlichen Aufgaben ausführen:

Führen Sie den react-native bundle Befehl aus, um die Updateinhalte (JS-Bundle und -Ressourcen) zu generieren, die für den CodePush-Server freigegeben werden. Es verwendet so weit wie möglich vernünftige Standardwerte (z. B. erstellen eines Nicht-Dev-Builds, vorausgesetzt, eine iOS-Eintragsdatei wird index.ios.jsgenannt), macht aber auch die relevanten react-native bundle Parameter verfügbar, --sourcemap-outputum Flexibilität zu ermöglichen (z. B. ).
Rückschluss auf dieses targetBinaryVersion Release mithilfe des Versionsnamens, der in den Dateien Info.plist (für iOS) und build.gradle (für Android) des Projekts angegeben ist.

Um den Unterschied zu veranschaulichen, den der release-react Befehl machen kann, zeigt das folgende Beispiel, wie Sie mithilfe des Befehls "vanilla" release ein Update für eine React Native App generieren und freigeben können:

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

Um das entsprechende Verhalten mit dem release-react Befehl zu erreichen, ist der folgende Befehl erforderlich, der weniger fehleranfällig ist:

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

App-Name-Parameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Bereitstellungsnameparameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Description-Parameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Erforderlicher Parameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Kein Fehlerparameter für doppelte Freigaben

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Rolloutparameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter. Wenn nicht angegeben, wird das Release allen Benutzern zur Verfügung gestellt.

Binärversionsparameter des Ziels

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter. Wenn nicht angegeben, wird standardmäßig die genaue Version verwendet, die in den Dateien Info.plist (für iOS) und build.gradle (für Android) der App angegeben ist.

Parameter "Bundlename"

Dieser Parameter gibt den Dateinamen an, der für das generierte JS-Bundle verwendet werden soll. Wenn nicht angegeben, wird der Standardpaketname für die angegebene Plattform verwendet: Standard.jsbundle (iOS), index.android.bundle (Android) und index.windows.bundle (Windows).

Tipp

Dieser Parameter kann entweder mit oder --bundle-name festgelegt werden. -b*

Entwicklungsparameter

Dieser Parameter gibt an, ob ein nicht minimiertes JS-Bündel für die Entwicklung generiert werden soll. Wenn sie nicht angegeben bleibt, wird standardmäßig festgelegt false , wo Warnungen deaktiviert sind und das Bundle minimiert wird.

Tipp

Dieser Parameter kann mit --development*

Parameter deaktiviert

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Eingabedateiparameter

Dieser Parameter gibt den relativen Pfad zur JavaScript-Stamm-/Eintragsdatei der App an. Wenn diese Datei nicht angegeben wird, wird standardmäßig index.ios.js (für iOS), index.android.js (für Android) oder index.windows.bundle (für Windows) verwendet, falls diese Datei vorhanden ist, oder andernfallsindex.js .

Tipp

Dieser Parameter kann entweder mit oder --entry-file festgelegt werden. -e*

Gradle-Dateiparameter (nur Android)

Dieser Parameter gibt den relativen Pfad zur Datei build.gradle an, den die CLI verwenden soll, wenn versucht wird, die Zielbinärversion für das Release automatisch zu ermitteln. Dieser Parameter ist nur für erweiterte Szenarien vorgesehen, da die CLI die Datei build.gradle des Projekts automatisch in "standard" React Native Projekten finden kann. Wenn sich die Gradledatei des Projekts jedoch an einem beliebigen Speicherort befindet, den die CLI nicht ermitteln kann, können Sie mit diesem Parameter weiterhin CodePush-Updates freigeben, ohne den --target-binary-version Parameter explizit festlegen zu müssen. Da build.gradle ein erforderlicher Dateiname ist, erzielen die Angabe des Pfads zum enthaltenden Ordner oder des vollständigen Pfads zur Datei selbst den gleichen Effekt.

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

Tipp

Dieser Parameter kann entweder mit oder --gradle-file festgelegt werden. -g*

Plist-Dateiparameter (nur iOS)

Dieser Parameter gibt den relativen Pfad zur Datei Info.plist an, den die CLI beim Versuch verwenden soll, die Zielbinärversion für das Release automatisch zu ermitteln. Dieser Parameter ist nur für erweiterte Szenarien vorgesehen, da die CLI die Info.plist-Datei des Projekts automatisch in "standard" React Native Projekten finden kann, und Sie den --plistFilePrefix Parameter verwenden können, um Plist-Dateien pro Umgebung zu unterstützen (z. B. STAGING-Info.plist). Wenn sich die plist des Projekts jedoch an einem beliebigen Speicherort befindet, den die CLI nicht ermitteln kann, können Sie mit diesem Parameter weiterhin CodePush-Updates freigeben, ohne den --target-binary-version Parameter explizit festlegen zu müssen.

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

Tipp

Dieser Parameter kann entweder mit oder --plist-file festgelegt werden. -p*

Plist-Dateipräfixparameter (nur iOS)

Dieser Parameter gibt das Dateinamenpräfix der Datei Info.plist an, die von der CLI verwendet werden soll, wenn versucht wird, die Zielbinärversion für das Release automatisch zu ermitteln. Dies kann nützlich sein, wenn Sie plist-Dateien pro Umgebung erstellt haben (z . B. DEV-Info.plist, STAGING-Info.plist), und Sie CodePush-Updates freigeben möchten, ohne den --target-binary-version Parameter explizit festlegen zu müssen. Durch Angabe eines --plist-file-prefixsucht die CLI an den folgenden Speicherorten nach einer Datei mit dem Namen <prefix>-Info.plist, anstelle von Info.plist (das Standardverhalten ist): ./ios und ./ios/<appName>. Wenn sich die plist-Datei des Projekts nicht in einem dieser Verzeichnisse befindet (z. B. ist Ihre App eine native iOS-App mit eingebetteten RN-Ansichten) oder eine völlig andere Dateibenennungskonvention verwendet, sollten Sie den --plist-file Parameter verwenden.

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

Quellzuordnungsausgabeparameter

Dieser Parameter gibt den relativen Pfad an, zu dem die Quellzuordnungsdatei des generierten JS-Bundles geschrieben werden soll. Wenn nicht angegeben, werden keine Quellzuordnungen generiert.

Tipp

Dieser Parameter kann entweder mit oder --sourcemap-output festgelegt werden. -s*

Name der Buildkonfiguration

Name der Buildkonfiguration, die die Binärversion angibt, auf die Sie für dieses Release abzielen möchten. Beispiel: "Debuggen" oder "Release" (nur iOS).

Hinweis

Dieser Parameter sollte beim Erstellen mit Xcode 11 und höher verwendet werden, um die von Xcode verwendete Standardkonfiguration außer Kraft zu setzen.

Release Updates (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]

Der release-cordova Befehl ist eine Cordova-spezifische Version des "vanilla"release-Befehls, der alle gleichen Parameter unterstützt (z. B. , --description), aber den Prozess der Veröffentlichung von Updates vereinfacht, --mandatoryindem die folgenden zusätzlichen Aufgaben ausgeführt werden:

Führen Sie den cordova prepare Befehl (oder phonegap prepare) aus, um den Updateinhalt (www-Ordner ) zu generieren, der für den CodePush-Server freigegeben wird.
Rückschluss auf dieses targetBinaryVersion Release mithilfe des Versionsnamens, der in der config.xml-Datei des Projekts angegeben ist.

Um den Unterschied zu veranschaulichen, den der release-cordova Befehl machen kann, zeigt das folgende Beispiel, wie Sie mithilfe des Befehls "vanilla" release ein Update für eine Cordova-App generieren und freigeben können:

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

Um das entsprechende Verhalten mit dem release-cordova Befehl zu erreichen, ist der folgende Befehl erforderlich, der weniger fehleranfällig ist:

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

App-Name-Parameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Bereitstellungsnameparameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Description-Parameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Erforderlicher Parameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Kein Fehlerparameter für doppelte Freigaben

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Rolloutparameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter. Wenn nicht angegeben, wird das Release allen Benutzern zur Verfügung gestellt.

Binärversionsparameter des Ziels

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter. Wenn er nicht angegeben bleibt, zielt der Befehl standardmäßig nur auf die angegebene Version in den Metadaten des Projekts ab (Info.plist , wenn dieses Update für iOS-Clients gilt, und build.gradle für Android-Clients).

Parameter deaktiviert

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Buildparameter

Dieser Parameter gibt an, ob Sie beim Generieren Ihrer aktualisierten Webressourcen anstelle von cordova prepare ausführen cordova build möchten (was das Standardverhalten ist). Es ist nützlich, wenn Ihr Projekt vor oder nach Build-Hooks enthält (z. B. zum Transpilieren von TypeScript), und daher reicht die Ausführung cordova prepare von CodePush nicht aus, um ein Update zu erstellen und zu veröffentlichen. Wenn sie nicht angegeben bleibt, wird standardmäßig verwendet false.

Tipp

Dieser Parameter kann entweder mit oder --build festgelegt werden. -b*

Patchen von Updatemetadaten

Nach der Veröffentlichung eines Updates kann es Szenarien geben, in denen Sie mindestens eines der Metadatenattribute ändern möchten (Beispielsweise haben Sie vergessen, eine kritische Fehlerbehebung als obligatorisch zu markieren, möchten Sie den Rolloutprozentsatz eines Updates erhöhen). Sie können dies ganz einfach tun, indem Sie den folgenden Befehl ausführen:

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]

Hinweis

Dieser Befehl lässt das Ändern des tatsächlichen Updateinhalts einer Version (z. B. www ordner einer Cordova-App) nicht zu. Wenn Sie auf ein Release reagieren möchten, das als fehlerhaft erkannt wurde, sollten Sie den Rollbackbefehl verwenden, um es sofort zurückzusetzen, und bei Bedarf ein neues Update mit dem entsprechenden Fix freigeben, wenn es verfügbar ist.

Abgesehen von und <ownerName>/<appName>deploymentNamesind alle Parameter optional. Daher können Sie diesen Befehl verwenden, um ein einzelnes Attribut oder alle attribute gleichzeitig zu aktualisieren. Das Aufrufen des patch Befehls ohne Angabe eines Attributflags führt zu einem 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%

Bezeichnungsparameter

Gibt an, welche Version (z. v23B. ) Sie innerhalb der angegebenen Bereitstellung aktualisieren möchten. Wenn sie nicht angegeben werden, werden die angeforderten Änderungen auf das neueste Release in der angegebenen Bereitstellung angewendet. Um die Bezeichnung für das Release nachzuschlagen, das Sie aktualisieren möchten, können Sie den appcenter codepush deployment history Befehl ausführen und auf die Label Spalte verweisen.

Erforderlicher Parameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter und ermöglicht Es Ihnen, zu aktualisieren, ob das Release als obligatorisch betrachtet werden soll oder nicht. Achten Sie darauf, dass --mandatory und --mandatory true gleichwertig sind, aber das Fehlen dieses Flags entspricht nicht --mandatory false. Wenn der Parameter ausgelassen wird, wird der Wert der obligatorischen Eigenschaft der Zielfreigabe nicht geändert. Legen Sie diesen Parameter auf fest --mandatory false , um eine Version explizit optional zu machen.

Description-Parameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter und ermöglicht es Ihnen, die Beschreibung für das Release zu aktualisieren (z. B. haben Sie beim Freigeben einen Tippfehler gemacht oder vergessen, überhaupt eine Beschreibung hinzuzufügen). Wenn dieser Parameter nicht angegeben wird, wird der Wert der Description-Eigenschaft der Zielversion nicht geändert.

Parameter deaktiviert

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter und ermöglicht Es Ihnen, zu aktualisieren, ob das Release deaktiviert werden soll oder nicht. Achten Sie darauf --disabled und --disabled true sind gleichwertig, aber das Fehlen dieses Flags entspricht nicht --disabled false. Wenn der Parameter ausgelassen wird, wird der Wert der deaktivierten Eigenschaft der Zielfreigabe nicht geändert. Legen Sie diesen Parameter auf fest --disabled false , damit ein Release explizit erworben werden kann, wenn es zuvor deaktiviert war.

Rolloutparameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter und ermöglicht es Ihnen, den Rolloutprozentsatz des Zielreleases zu erhöhen. Dieser Parameter kann nur auf eine ganze Zahl festgelegt werden, deren Wert größer als der aktuelle Rolloutwert ist. Wenn Sie den Rollout "abschließen" und das Release für alle verfügbar machen möchten, können Sie diesen Parameter auf --rollout 100festlegen. Wenn dieser Parameter ausgelassen wird, wird der Wert des Rolloutparameters des Zielreleases nicht geändert.

Darüber hinaus wird es, wie oben erwähnt, beim Freigeben eines Updates ohne Rolloutwert gleichbedeutend mit dem Festlegen des Rollouts auf 100behandelt. Wenn Sie ein Update ohne Rollout veröffentlicht haben, können Sie die Rollouteigenschaft des Updates nicht über den patch Befehl ändern, da dies als Eine Senkung des Rolloutprozentsatzes angesehen wird.

Binärversionsparameter des Ziels

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter und ermöglicht ihnen das Aktualisieren des Semverbereichs , der angibt, mit welchen Binärversionen ein Release kompatibel ist. Dies kann nützlich sein, wenn Sie beim ursprünglichen Veröffentlichen eines Updates einen Fehler gemacht haben (z. B. wenn Sie 1.0.0 angegeben, aber bedeuteten), 1.1.0oder Wenn Sie den Von einem Release unterstützten Versionsbereich erhöhen oder verringern möchten (beispielsweise haben Sie festgestellt, dass ein Release mit einem Release doch nicht funktioniert 1.1.2 ). Wenn dieser Parameter weggelassen wird, wird der Wert der Versionseigenschaft der Zielversion nicht geändert.

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

Förderung Updates

Nachdem Sie ein Update für eine bestimmte Bereitstellung (z. B. Staging) getestet haben und es "downstream" heraufstufen möchten (z. B. dev-staging>, staging-production>), können Sie den folgenden Befehl verwenden, um das Release von einer Bereitstellung in eine andere zu kopieren:

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]

Der promote Befehl erstellt eine neue Version für die Zielbereitstellung, die den genauen Code und die Metadaten (Beschreibung, Obligatorische und Zielbinärversion) aus der neuesten Version der Quellbereitstellung enthält. Sie können den release Befehl zwar verwenden, um ein Update "manuell" von einer Umgebung in eine andere zu migrieren, der promote Befehl bietet jedoch die folgenden Vorteile:

Dies ist schneller, da Sie die Releaseressourcen, die Sie veröffentlichen möchten, nicht neu zusammensetzen müssen, oder sich die Beschreibungs-/Binärversion merken müssen, die für die Veröffentlichung der Quellbereitstellung vorgesehen ist.
Dies ist weniger fehleranfällig, da der Heraufstufenvorgang sicherstellt, dass genau das, was Sie bereits in der Quellbereitstellung getestet haben (z. B. Staging) in der Zielbereitstellung aktiv wird (z. B Production. ).

Es wird empfohlen, dass alle Benutzer die automatisch erstellten Staging Umgebungen und Production Umgebungen nutzen und alle Releases direkt für Stagingund nach dem promote entsprechenden Test von Staging bis Production ausführen.

Description-Parameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter und ermöglicht es Ihnen, die Beschreibung zu überschreiben, die für die heraufgestufte Version verwendet wird. Wenn nicht angegeben, erbt das neue Release die Beschreibung von der heraufgestuften Version.

Parameter deaktiviert

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter und ermöglicht es Ihnen, den Wert des deaktivierten Flags zu überschreiben, das für die heraufgestufte Version verwendet wird. Wenn nicht angegeben, erbt das neue Release die deaktivierte Eigenschaft von der heraufgestuften Version.

Erforderlicher Parameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter und ermöglicht es Ihnen, das obligatorische Flag zu überschreiben, das für die heraufgestufte Version verwendet wird. Wenn nicht angegeben, erbt die neue Version die obligatorische Eigenschaft von der heraufgestuften Version.

Kein Fehlerparameter für doppelte Freigaben

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter.

Rolloutparameter

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter und ermöglicht Es Ihnen, anzugeben, ob die neu erstellte Version nur für einen Teil Ihrer Benutzer verfügbar gemacht werden soll. Im Gegensatz zu den anderen Releasemetadatenparametern (z. B description. ) wird der rollout eines Releases nicht im Rahmen einer Heraufstase übertragen bzw. geerbt. Daher müssen Sie dies explizit festlegen, wenn das neu erstellte Release nicht für alle Benutzer verfügbar sein soll.

Binärversionsparameter des Ziels

Es ist derselbe Parameter wie der im obigen Abschnitt beschriebene Parameter und ermöglicht es Ihnen, die Zielbinärversion zu überschreiben, die für die heraufgestufte Version verwendet wird. Wenn dies nicht angegeben ist, erbt die neue Version die Binäre Zielversionseigenschaft von der heraufgestuften Version.

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

Der Releaseverlauf einer Bereitstellung ist unveränderlich, sodass Sie ein Update nach der Veröffentlichung nicht mehr löschen oder entfernen können. Wenn Sie jedoch ein Update freigeben, das fehlerhaft ist oder unbeabsichtigte Features enthält, ist es einfach, es mithilfe des rollback Befehls zurückzusetzen:

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

Durch Ausführen dieses Befehls wird ein neues Release für die Bereitstellung erstellt, das genau denselben Code und dieselben Metadaten wie die Version vor der neuesten enthält. Stellen Sie sich beispielsweise vor, Sie haben die folgenden Updates für Ihre App veröffentlicht:

Freigabe	BESCHREIBUNG	Obligatorisch.
v1	Erste Veröffentlichung!	Yes
V2	Neues Feature hinzugefügt	No
V3	Behebung von Programmfehlern	Yes

Wenn Sie den rollback Befehl für diese Bereitstellung ausgeführt haben, wird ein neues Release (v4) erstellt, das den Inhalt der v2 Version enthält.

Freigabe	BESCHREIBUNG	Obligatorisch.
v1	Erste Veröffentlichung!	Yes
V2	Neues Feature hinzugefügt	No
V3	Behebung von Programmfehlern	Yes
v4 (Rollback von v3 zu v2)	Neues Feature hinzugefügt	No

Endbenutzer, die bereits erworben wurden v3 , werden jetzt zurück verschoben v2 , wenn die App eine Updateprüfung durchführt. Darüber hinaus erhalten alle Benutzer, die noch ausgeführt v2und daher noch nie erworben v3hatten, kein Update, da sie bereits die neueste Version ausführen (aus diesem Grund verwendet unsere Updateüberprüfung den Pakethash zusätzlich zur Releasebezeichnung).

Wenn Sie ein Rollback für eine Bereitstellung auf eine andere Version als das vorherige ausführen möchten (z. B. v3 ->v2), können Sie den optionalen --target-release Parameter angeben:

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

Hinweis

Das durch ein Rollback erzeugte Release wird in der Ausgabe des deployment history Befehls mit Anmerkungen versehen, um sie leichter zu identifizieren.

Anzeigen des Releaseverlaufs

Mit dem folgenden Befehl können Sie einen Verlauf der 50 neuesten Releases für eine bestimmte App-Bereitstellung anzeigen:

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

Der Verlauf zeigt alle Attribute zu jedem Release an (z. B. Bezeichnung, obligatorisch) und gibt an, ob Releases aufgrund einer Heraufstufung oder eines Rollbackvorgangs erstellt wurden.

Bereitstellungsverlauf

Darüber hinaus werden im Verlauf die Installationsmetriken für jedes Release angezeigt. Sie können die Details zum Interpretieren der Metrikdaten in der Dokumentation für den obigen deployment list Befehl anzeigen.

Löschen des Releaseverlaufs

Sie können den Releaseverlauf für eine Bereitstellung mit dem folgenden Befehl löschen:

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

Nach dem Ausführen dieses Befehls erhalten Clientgeräte, die für den Empfang von Updates mit dem zugehörigen Bereitstellungsschlüssel konfiguriert sind, die gelöschten Updates nicht mehr. Dieser Befehl ist irreversibel und sollte daher nicht in einer Produktionsbereitstellung verwendet werden.

Code-Signierung

Was ist das?

Die Codesignatur ist eine Möglichkeit, digitale Signaturen für Bundles zu erstellen, die später vor der Installation clientseitig überprüft werden können.

Warum ist das nötig?

Entwickler möchten wissen, dass der von ihnen gelieferte Code der von ihnen geschriebene Code ist. Die Codesignatur ist der primäre Mechanismus zum Bereitstellen dieser Sicherheit und kann dazu beitragen, eine ganze Klasse von Man-in-the-Middle-Angriffen zu minimieren oder zu beseitigen.

Wie funktioniert dies?

Zunächst generiert der Entwickler ein asymmetrisches Schlüsselpaar: Der private Schlüssel wird zum Signieren von Bundles verwendet; der öffentliche Schlüssel für die Überprüfung der Bündelsignatur. Die CodePush-CLI verwendet dann den privaten Schlüssel, um Bündel während und releaserelease-reactrelease-cordova -Befehlen zu signieren. Der öffentliche Schlüssel wird mit der mobilen Anwendung geliefert. Die Kontrolle über die Generierung und Verwaltung von Schlüsseln liegt in den Händen des Entwicklers.

Am Ende des Releasebefehls berechnet die CLI den Inhaltshash des Bundles und platziert diesen Wert in einem JWT, der mit dem privaten Schlüssel signiert ist. Wenn das CodePush-Plug-In ein Bundle auf ein Gerät herunterlädt, überprüft es die .codepushrelease Datei mit dem JWT und überprüft die JWT-Signatur mithilfe des öffentlichen Schlüssels. Wenn die Überprüfung fehlschlägt, wird das Update nicht installiert.

Anforderungen für die Verwendung dieses Features

Wenn Sie planen, dieses Feature zu verwenden, führen Sie die folgenden Schritte aus:

Erstellen eines neuen binären Updates, einschließlich
- Aktualisiertes CodePush-Plug-In, das Die Codesignatur unterstützt
- konfigurieren Sie Ihr Code-Push-SDK für die Verwendung Ihres öffentlichen Schlüssels (Ausführliche Informationen finden Sie in den entsprechenden Abschnitten React Native SDK (iOS, Android) oder Cordova SDK).
Erstellen eines neuen CodePush-Updates, das auf die neue Binärversion abzielt und einen --private-key-path (oder -k) Parameterwert angibt

In unseren Kompatibilitätstabellen finden Sie informationen dazu, ob die Codesignaturfunktion in Ihrem SDK/IHRER CLI unterstützt wird:

CodePush SDK	Version, von der die Codesignatur unterstützt wird	Unterstützte Plattformen	Minimale CodePush CLI-Version erforderlich
`react-native-code-push`	5.1.0	Android, iOS	2.1.0
`cordova-plugin-code-push`	1.10.0	Android, iOS	2.1.2

Schlüsselgenerierung

Die Codesignatur unterstützt PEM-codierte RSA-Schlüssel (Nichtzertifikate) zum Signieren. Sie können sie wie unten gezeigt über openssl generieren:

# 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

Beispiel für generierte Schlüssel:

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

Freigeben eines signierten Updates

Um signiertes Update freizugeben, sollten Sie die Option (oder -k) für release oder release-react verwenden --private-key-path .

Freigeben über

Veröffentlichen von CodePush-Updates mithilfe der App Center-CLI

Installation

Erste Schritte

Kontoverwaltung

Authentifizierung

Zugriffstoken

App-Verwaltung

App-Zusammenarbeit

Bereitstellungsverwaltung

Veröffentlichen von Updates

Veröffentlichen von Updates (Allgemein)

App-Name-Parameter

Parameter "Inhalt aktualisieren"

Binärer Zielversionsparameter

Parameter "Bereitstellungsname"

Description-Parameter

Parameter deaktiviert

Erforderlicher Parameter

Kein Fehlerparameter für doppelte Freigaben

Rolloutparameter

Veröffentlichen von Updates (React Native)

App-Name-Parameter

Bereitstellungsnameparameter

Description-Parameter

Erforderlicher Parameter

Kein Fehlerparameter für doppelte Freigaben

Rolloutparameter

Binärversionsparameter des Ziels

Parameter "Bundlename"

Entwicklungsparameter

Parameter deaktiviert

Eingabedateiparameter

Gradle-Dateiparameter (nur Android)

Plist-Dateiparameter (nur iOS)

Plist-Dateipräfixparameter (nur iOS)

Quellzuordnungsausgabeparameter

Name der Buildkonfiguration

Release Updates (Cordova)

App-Name-Parameter

Bereitstellungsnameparameter

Description-Parameter

Erforderlicher Parameter

Kein Fehlerparameter für doppelte Freigaben

Rolloutparameter

Binärversionsparameter des Ziels

Parameter deaktiviert

Buildparameter

Patchen von Updatemetadaten

Bezeichnungsparameter

Erforderlicher Parameter

Description-Parameter

Parameter deaktiviert

Rolloutparameter

Binärversionsparameter des Ziels

Förderung Updates

Description-Parameter

Parameter deaktiviert

Erforderlicher Parameter

Kein Fehlerparameter für doppelte Freigaben

Rolloutparameter

Binärversionsparameter des Ziels

Rollback Updates

Anzeigen des Releaseverlaufs

Löschen des Releaseverlaufs

Code-Signierung

Was ist das?

Warum ist das nötig?

Wie funktioniert dies?

Anforderungen für die Verwendung dieses Features

Schlüsselgenerierung

Freigeben eines signierten Updates

Zusätzliche Ressourcen