Kanäle

A Live Update-Kanal verweist auf eine bestimmte JS-Bundle-Build Ihres Apps, die mit allen Geräten konfiguriert ist, um auf Updates zu hören. Wenn Sie die Live Update Live Updates __CAPGO_KEEP_1__ installiere die Capgo Live Updates SDK in your app, any native binary configured to that channel will check for available updates whenever the app is launched. You can change the build a channel points to at any time and can also roll back to previous builds if needed.

Kanäle Bieten Keine Vertraulichkeit

Channels control update eligibility, not bundle secrecy. Even if a channel is private or self-assignment is disabled, any unencrypted bundle uploaded to Capgo should still be treated as a public asset delivered to clients. Encryption protects the delivery path and authenticity of updates, but shipped bundles can still be reverse engineered from the distributed app with enough effort because the public key is part of the client. See Live Update Verschlüsselung für weitere Informationen.

Wie ein Gerät einen Kanal auswählt (Priorität)

Wenn ein Gerät nach einer Aktualisierung sucht, entscheidet Capgo, welchen Kanal in dieser strengen Reihenfolge (mit höchster Priorität zuerst) verwendet werden soll:

1. Zwangsmapping des Geräts (Dashboard) – Manually pin a specific device ID to a channel. Use for urgent debugging or controlled testing with a single real user. This always wins. Capgo removes the mapping 90 days after the last override write. See Console und die API-Überprüfungen gelten 90 Tage..
2. Cloud-Überprüfung (pro Gerät) über das Dashboard oder API – Erstellt, wenn Sie den Kanal des Geräts im Dashboard oder über API ändern. Verwenden Sie dies für QA-Benutzer, die zwischen Feature- / PR-Kanälen wechseln oder um ein Benutzerproblem nachzustellen. Eine Neinstallation des Binärs löscht es nicht; die Löschung der Geräte-Überprüfung tut es.
3. Plugin setChannel() lokaler Kanal – Erstellt, wenn die App setChannel() und der Backend bestätigt, dass der Zielkanal die Selbstzuweisung zulässt. Der ausgewählte Kanal wird lokal auf dem Gerät gespeichert, wirkt sofort ein und wird nicht im Geräte-Überprüfungs-UI angezeigt.

Schnelles Kanalwechseln mit setChannel()

Ab der Plugin-Version 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 (abhängig von Ihrer Hauptversion) (abhängig von Ihrer Hauptversion) setChannel() funktioniert anders: es kontaktiert den Backend-Server, um zu validieren ob der Kanal erlaubt ist (Überprüfung, ob Selbstzuweisung für diesen Kanal aktiviert ist), dann speichert es den Kanal lokale auf dem Gerät als defaultChannelDies bedeutet, dass der neue Kanal sofort wirksam wird für die nächste Aktualisierung überprüfen—warten Sie nicht auf die Replikation.

Zuvor setChannel() speicherte der Kanal-Übertrag in der Backend-Datenbank (wie Dashboard oder API-Änderungen) und Geräte mussten auf Datenreplikation (bis zu 2 Minuten) warten, bevor der neue Kanal anerkannt wurde. Das neue Verhalten liest nur vom Backend (für die Validierung) und speichert lokal, was den Kanalwechsel sofort macht.

Da setChannel() nur lokal ist, tut es nicht Erstelle einen Eintrag für das Geräte-Überschreiben in der Capgo-Oberfläche. Die Geräte-Überschreibungs-Oberfläche zeigt nur Überschreibungen an, die aus der Oberfläche oder der öffentlichen API erstellt wurden.

Hinweis: Sollte ein Kanal nach lokaler Einstellung gesperrt werden, wird der Backend die Validierung des Kanals während der Update-Überprüfungen durchführen, sodass die Sicherheit gewährleistet ist.

Wichtig: Wenn Änderungen an den Kanälen über die Oberfläche oder API vorgenommen werden, besteht ein Replicationsverzug von bis zu 2 Minuten, bevor alle Edge-Server die Änderung widerspiegeln. Für eine sofortige Kanalwechsel verwenden Sie setChannel() aus Ihrer App code—sie validiert mit dem Backend und setzt den Kanal lokal für einen sofortigen Effekt.

4. Capacitor-Konfiguration defaultChannel __CAPGO_KEEP_0__ (Standard für Testversionen) – Wenn vorhanden in capacitor.config.* und kein Zwang/Überschreiben/Lokaler Kanal existiert, startet die App auf diesem Kanal (z.B. beta, qa, pr-123Zurückgelassen für Testversionen/Innere Builds, damit Tester automatisch auf einem Vorkabel-Kanal landen. Produktionsbuilds lassen dies normalerweise ungesetzt.
5. Cloud Standardkanal (Hauptpfad ~99% der Benutzer) – Wenn Sie einen Standardkanal im Dashboard markieren, werden alle normalen Endnutzer (kein Zwang, keine Dashboard/API-Übernahme, keine Plugin-Standardkanal, keine Konfiguration Standardkanal) hier angewiesen. Ändern Sie ihn, um sofort auszurollen oder zurückzurufen – kein neuer Binärdatei. Wenn Sie plattform-spezifische Standards haben (z. B. ein iOS nur, ein Android nur, ein Electron nur), landet jeder Gerät auf dem Standard, der seiner Plattform entspricht. Das Ignorieren des Cloud-Standards ist erlaubt; in diesem Fall muss das Gerät auf Schritte 1–4 abstimmen, um Updates zu erhalten.

Gute Praxis:

• Behandeln Sie 1–4 als Ausnahmen / Testebenen; wenn Sie einen Cloud-Standard setzen, sollten sich echte Benutzer in ihn einfließen. Wenn Sie keinen setzen, sollten Sie bewusst darüber nachdenken, wie Benutzer sich anbinden (typischerweise via) defaultChannel in config or per-device overrides).
• Verwenden Sie defaultChannel in Binärdateien, die Sie explizit an Tester liefern. Wenn es leer bleibt, bleibt die Produktionslogik zentral im Dashboard.
• Use setChannel() selten in der Produktion—hauptsächlich für QA oder gezielte Diagnosen.

If a channel is disabled for the platform (iOS/Android/Electron toggles) when it would otherwise be chosen, the selection process skips it and continues down the list.

Zusammenfassung: Zwang > Dashboard/API Übernehmen > Plugin setChannel() lokale Kanal > Konfiguration defaultChannel > Standard-Cloud.

Console und API-Überschreibungen gelten nach 90 Tagen nicht mehr.

Für zwingende Zuweisungen und Dashboard- oder öffentliche API-Kanal-Überprüfungen werden pro Gerät Zuweisungen in Capgo gespeichert. Ein Reinigungsjob löscht diese Zuweisungen. 90 Tage nach dem letzten Schreibvorgang.. Ein Update-Check ändert nicht diesen Zeitpunkt. Nur das erneute Schreiben der Überschreibung (oder das Löschen durch dich selbst) ändert den Timestamp.

Dies ist nicht dasselbe wie Geräteinventar-RetentionGeräteinventar entfernt Geräte, die seit 90 Tagen nicht mit Capgo verbunden waren. Die Reinigung der Überschreibungen entfernt die Zuweisung, selbst wenn das Gerät noch aktiv ist.

Für eine Zuweisung, die nicht durch diese Reinigung entfernt wird:

• Set defaultChannel context capacitor.config.* (überlebt eine Wiederinstallation; erfordert ein neues natives Binärdatei, um es später zu ändern).
• Aufrufen setChannel() Von der App. Auf Plugin 5.34.0 / 6.34.0 / 7.34.0 / 8.0.0 und später, ist diese Zuweisung lokal und wird durch diese Reinigung nicht entfernt. Durch Wiederinstallation der App wird es gelöscht, daher muss die App setChannel() wieder aufrufen, wenn Sie das Kanal noch wollen.

Der Kanal Geräte Konsolen- und öffentliche API-Zuweisungen werden im Geräte-Überschreibungs-UI nur aufgelistet. Sie werden nicht alle Geräte auf dem Kanal aufgelistet und sie werden nicht lokale setChannel() assignments.

Überschreibungs-Hinweis auf der Geräte-Übersicht des Kanals.

Standardverhalten des Kanals

Ein Cloud-Standard setzen ist optional, aber er dient normalerweise als allgemeiner Pfad für neue Geräte. Ohne einen solchen Standard erhalten nur Geräte, die auf zwingenden Zuordnungen, Überwriten oder einem defaultChannel in der Capacitor-Konfiguration erhalten Updates. Wenn Sie die Standards markieren, beachten Sie diese Muster:

• Einziger Standard (am häufigsten) – Wenn ein Kanal für iOS, Android und Electron aktiviert ist, wird er zum einzigen Standard; jedes Gerät ohne Überwriten wird hier angewiesen.
• Plattform-spezifische Standards – Wenn Sie Kanäle nach Plattformen aufteilen (z. B. ios-production mit nur iOS aktiviert, android-production mit nur Android aktiviert und electron-production mit nur Electron aktiviert), markieren Sie jeden als Standard für seine Plattform. iOS-Geräte gehen zum iOS-Standard, Android-Geräte gehen zum Android-Standard und Electron-Anwendungen gehen zum Electron-Standard.

Denken Sie daran, dass der Cloud-Standard und defaultChannel im capacitor.config.* beide denselben Entscheidungsschritt einnehmen. Wenn Sie einen Cloud-Standard setzen, müssen Sie den Wert nicht im Capacitor-Konfigurationsdatei duplizieren—lassen Sie ihn einfach leer. defaultChannel leer für Produktionsbuilds. Reservieren defaultChannel für Binärdateien, die Sie absichtlich an Tester oder QA liefern, wenn Sie möchten, dass sie auf einem nicht-Produktionskanal starten, auch wenn der Cloud-Standard anders ist.

Sie können die Standards jederzeit im Dashboard ändern. Öffnen Sie den Kanal, dann Verwalten in App-Einstellungen, which takes you to App-Informationenführt. Der Standard ist nicht mehr ein Schalter auf der Kanal-Seite. Wenn Sie einen Standard austauschen, folgen neue Geräte sofort den neuen Routen und bestehende Geräte folgen den normalen Vorrangregeln beim nächsten Mal, wenn sie sich abmelden.

Einrichten eines Kanals

Während der Einrichtung erstellen Sie den ersten Kanal (die meisten Teams nennen ihn “Produktion”), aber nichts ist gesperrt – Sie können jeden Kanal jederzeit umbenennen oder löschen. Um zusätzliche Kanäle später hinzuzufügen:

1. Gehe zur "Kanäle"-Sektion der Capgo-Oberfläche.
2. Klicken Sie auf den ‘Neuen Kanal’-Button
3. Ein Namen für den Kanal eingeben und auf ‘Erstellen’ klicken

Kanalnamen können alles sein, was Sie wollen. Eine gängige Strategie besteht darin, Kanäle Ihren Entwicklungsstufen zuzuordnen, wie zum Beispiel:

• Development - für die Überprüfung von Live-Updates auf lokalen Geräten oder Emulatoren
• QA - für Ihre QA-Team, um Updates vor einer breiteren Veröffentlichung zu überprüfen
• Staging - für die endgültige Überprüfung in einem Produktionsumfeld
• Production - für die Version Ihres Apps, die Benutzer von den App-Stores erhalten

Kanal in Ihrer App konfigurieren

Nachdem Sie Ihre Kanäle erstellt haben, müssen Sie Ihre App so konfigurieren, dass sie auf den entsprechenden Kanal hört. In diesem Beispiel verwenden wir den Development Öffnen Sie Ihr

(oder capacitor.config.ts (or capacitor.config.json) Datei. Unter dem plugins optional Sektion einrichten defaultChannel für Testversionen (intern / QA). Für Produktionsversionen bevorzugen Sie die Unterlassung, damit Geräte die Cloud-Standard verwenden, es sei denn, dies wird explizit überschrieben.

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

Nächsten, bauen Sie Ihre Webanwendung und führen Sie npx cap sync um die aktualisierte Konfigurationsdatei in Ihre iOS-, Android- und Electron-Projekte zu kopieren. Wenn Sie diesen Synchronisierungsstep überspringen, werden Ihre native Projekte weiterhin diejenige Kanal verwenden, für die sie zuvor konfiguriert waren.

Vorsicht

Kanalwahl-Reihenfolge: Zwang > Dashboard/API Geräteüberschreibung > Plugin setChannel() lokaler Kanal > Konfiguration defaultChannel > Standard-Cloud.

Use defaultChannel nur in Test-/Internen Builds; lassen Sie es für die Produktion aus, damit die Benutzer der Standard-Cloud (wenn gesetzt) folgen, anstatt die Routen in der native Konfiguration zu duplizieren.

Sie können ein Gerät noch zwingen (festlegen) oder eine Überschreibung später anwenden – diese übernehmen sofort die Konfigurationswerte.

Die Kanalnamen sind case-sensitive.

Kanaloptionen und Strategien

Kanäle haben mehrere Optionen, die steuern, wer Updates erhalten kann und wie Updates geliefert werden. Die wichtigsten sind unten aufgeführt. Sie können diese von der Webanwendung, der CLI, oder der öffentlichen API konfigurieren.

• Standardkanal: Optional markieren Sie den Kanal oder die plattform-spezifischen Kanäle, die neue Geräte anbinden. In der Konsole befindet sich dies auf der App-Informationen-Seite (Verwalten Sie in App-Einstellungen aus der Kanal-Seite). Siehe “Standardverhalten des Kanals” für Routen-Szenarien.
• Plattformfilter: Aktivieren oder deaktivieren Sie die Lieferung an iOS, Androidoder Electron Geräte pro Kanal.
• Unter native deaktivieren: Verhindert das Senden einer Aktualisierung, wenn die Geräte-App-Version neuere ist als die Kanal-Bundle-Version (z.B. Gerät auf 1.2.3, während der Kanal 1.2.2 hat).
• Entwicklungsbauarten zulassen: Aktualisierungen für Entwicklungsbaustellen zulassen (nützlich für Tests). CLI: --dev / --no-dev.
• Allow production builds: Permit updates to production (store) builds. Leave this on for channels that serve real users. CLI: --prod / --no-prod.
• Emulatoren zulassen: Aktualisierungen für Emulatoren/Simulator zulassen (nützlich für Tests). CLI: --emulator / --no-emulator.
• Allow physical devices: Permit updates to real phones and tablets. Leave this on for production channels. CLI: --device / --no-device.
• Geräte zur Selbstzuweisung zulassen: Lassen Sie die App sich auf diesen Kanal umschalten, wenn __CAPGO_KEEP_0__: setChannelWenn deaktiviert, __CAPGO_KEEP_0__: setChannel für diesen Kanal fehlschlagen wird. CLI: --self-assign / --no-self-assign.
• Herunterladungsformat: Wählen Sie, ob Geräte ein vollständiges Zip-Datei, nur die geänderten Delta-Dateien oder das Beste beider ("all, zip, delta, zip_from_builtin, delta_from_builtin). See Herunterladungsformat für das Konsolenmenü und wenn jede Modus nützlich ist.

Schrittweise Bereitstellung

A channel can keep a stable bundle while gradually exposing a separate rollout target to a sticky device cohort. You can pause, resume, promote, roll back, and configure an automatic failure response without switching the channel for everyone. See Schrittweise Bereitstellung für das Liefermodell, das Dashboard-Workflow, API-Felder und CLI-Befehle.

Deaktivieren Sie die automatischen Update-Strategien

Verwenden Sie diese, um festzulegen, welche Arten von Updates der Kanal automatisch liefern wird. Optionen:

• Verwenden Sie dies, um festzulegen, welche Arten von Updates der Kanal automatisch liefern soll. Optionen:version_build). Example: 1.2.3 -> 2.0.0 ist blockiert; 1.2.3 -> 1.9.0 ist erlaubt.
• minor: Blockt eine Ziel-Paketversion, deren Haupt- oder Minor-Version sich von version_buildBeispiel: 1.2.3 -> 1.3.0 ist blockiert; 1.2.3 -> 1.2.4 ist erlaubt.
• patch: Striktster Modus. Blockt jede Änderung an der Haupt-, Minor- oder Patchnummer. Nur Suffix-Änderungen sind erlaubt, während MAJOR.MINOR.PATCH bleibt identisch. Beispiele: 1.0.0-beta.1 -> 1.0.0-beta.2 ist erlaubt, 1.0.0+build.1 -> 1.0.0+build.2 ist erlaubt, 1.0.0 -> 1.0.1 ist blockiert.
• metadata: Erfordert eine Mindestaktualisierungsversionsmetadaten auf jedem Paket. Konfigurieren Sie dies über CLI mithilfe --min-update-version or --auto-min-update-versionWenn fehlend, wird das Channel als fehlerhaft markiert und Updates werden abgelehnt, bis es gesetzt wird.
• keine: Alle Updates zulassen Kompatibilität nach semver.

Diese Strategien vergleichen das Zielbundle des Kanals mit der native Baseline, die als version_buildnicht das aktuell heruntergeladene Bundle, das als version_name.

Mehr Details und Beispiele finden Sie in der Strategie zur Deaktivierung von Updates unter /docs/cli/commands/#disable-updates-strategy.

Beispiel (CLI). Der Channel muss bereits existieren ("channel set Mit setChannel() aus Ihrer App

# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

# Production channel: store builds on real devices, no emulators
npx @capgo/cli@latest channel set production com.example.app --prod --device --no-emulator

Verwenden Sie setChannel() aus Ihrer App

Der setChannel() Methode ermöglicht es Ihrer App, Channels programmatisch während der Ausführung zu wechseln. Dies ist insbesondere nützlich für:

• QA/Debug-Menüs, bei denen Tester zwischen Channels wechseln können
• Beta-Programm-Opt-in-Flüsse
• Feature-Flag-Implementierungen
• A/B-Test-Szenarien

import { CapacitorUpdater } from '@capgo/capacitor-updater';

// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });

// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

Wie setChannel() funktioniert (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Wenn setChannel() aufgerufen wird:

1. Hintergrundvalidierung (nur Lesen): Ein Anfrage wird an den Capgo-Backend gesendet, um zu überprüfen, ob der Kanal zugelassen ist (Überprüfung der Selbstzuweisungsrechte)
2. Aktualisierung des lokalen Speichers: Wenn die Validierung erfolgreich ist, wird der Kanal im Gerätespeicher als defaultChannel
3. Echtzeit-Effekt: Die nächste Aktualisierung überprüft den neuen Kanal sofort (keine Wartezeit für die Replikation)

Warum das wichtig ist: In älteren Versionen setChannel() speicherte die Überprüfung des Kanal-Überladens im Backend-Database (gleich wie Dashboard oder API-Änderungen). Die Geräte mussten auf die Backend-Replikation (bis zu 2 Minuten) warten, bevor der Kanal-Wechsel wirksam wurde. Jetzt setChannel() liest nur vom Backend (für die Validierung) und speichert lokal, was den Kanal-Wechsel sofort wirksam macht.

Anzeige im Dashboard: Ein mit dem Plugin gesetzter Kanal macht das Gerät nicht als Geräte-Überladung im Capgo-UI sichtbar. Nur Kanalzuweisungen, die aus dem Dashboard oder dem öffentlichen API erstellt wurden, werden dort aufgelistet. Benutzen Sie das Dashboard oder API , wenn Sie eine admin-sichtbare Überladung benötigen.

Sicherheitsanmerkung: Wenn sich die Berechtigungen eines Kanals nach der lokalen Einstellung ändern (z.B. Selbstzuweisung ist deaktiviert), wird der Backend den Kanal während der Aktualisierungsprüfungen noch immer überprüfen, um die Sicherheit aufrechtzuerhalten.

Vergleich der Kanaländerungsverfahren:

Methode	Wirkungszeit	Persistiert in	Angezeigt auf Gerät	Übernehmen	Verwendungszweck
setChannel() von Plugin	Echtzeit	Gerät nur (lokal)	No	Keine (bis du es änderst oder neu installierst)	Benutzerinitiierte Kanalwechsel in der App
Geräteüberschreibung auf der Dashboard-Seite	bis zu 2 Minuten	Hintergrund-Datenbank	Ja	90 Tage nach letzten Überprüfungsschreiben	90 Tage nach der letzten Überschreibungsaktion
API Kanalzuweisung	bis zu 2 Minuten	Hintergrund-Datenbank	Ja	90 Tage nach der letzten Änderung	Automatisierte Backend-Integrationen

Für die beste Benutzererfahrung bei der Erstellung von UIs für Kanalwechsel verwenden Sie immer die Funktion des Plugins. setChannel() method.

Mindestversionen für lokale Kanalwechsel: 5.34.0, 6.34.0, 7.34.0, or 8.0.0 (depending on your major version). Each minor version number corresponds to the same feature set across all major versions (e.g., X.34.0 includes the same features whether X is 5, 6, 7, or 8). See Erweiterungsinstallation Zuweisung eines Bundles an einen Kanal

Zuweisung eines Bundles an einen Kanal

Um ein live update zu deployen, müssen Sie ein neues JS-Bundle-Build hochladen und ihm einen Kanal zuweisen. Sie können dies in einem Schritt mit dem Capgo CLI tun:

npx @capgo/cli@latest bundle upload --channel=Development

Dies wird Ihre gebauten Web-Assets hochladen und das neue Bundle als aktives Build für den Development Kanal setzen. Jeder App, die auf diesen Kanal lauscht, erhält die Aktualisierung beim nächsten Mal, wenn sie nach einer aktualisiert werden.

Sie können auch Builds auf Kanäle im Bereich 'Bundles' der Capgo-Oberfläche zuweisen. Klicken Sie auf das Menüsymbol neben einem Build und wählen Sie 'Zu Kanal zuweisen', um den Kanal für dieses Build auszuwählen.

Bundle-Versionierung und Kanäle

Es ist wichtig zu beachten, dass Bundles in Capgo global für Ihre App sind und nicht spezifisch auf einzelne Kanäle beschränkt sind. Das gleiche Bundle kann auf mehrere Kanäle zugewiesen werden.

Bei der Versionsierung Ihrer Bundles empfehlen wir die Verwendung von semantischer Versionsierung mit Capgo's Semver-Tester und Vorabversionen für kanalbezogene Builds. Zum Beispiel könnte eine Beta-Version als 1.2.3-beta.1.

In CI, wenn die lokale Version bereits hochgeladen wurde, verwenden Sie npx @capgo/cli@latest bundle upload --auto-bump (optional) major, minor, patch/fix, metadata, oder ai) so der CLI bis zu einem freien Namen aus dem kanal verbundenen Bundle springt. aiso dass __CAPGO_KEEP_0__ sich von dem Kanal-Bundle bis zu einem freien Namen weiterentwickelt. Mit patch mit keiner vorherigen Capgo Version. Sie können es nicht kombinieren. --bundle. See CI/CD-Integration und das CLI Referenz.

Dieser Ansatz hat mehrere Vorteile:

• Es vermittelt die Beziehung zwischen Builds klar. 1.2.3-beta.1 ist offensichtlich eine Vorversion von 1.2.3.
• Es ermöglicht die Wiederverwendung von Versionsnummern über Kanäle hinweg, was Verwirrung reduziert.
• Es ermöglicht klare Rückschrittspfade. Wenn Sie von einem zurückrollen müssen 1.2.3wissen Sie 1.2.2 ist die vorherige stabile Version.

Hier ist ein Beispiel dafür, wie Sie Ihre Bundle-Versionen mit einer typischen Kanal-Konfiguration ausrichten können:

• Development Kanal: 1.2.3-dev.1, 1.2.3-dev.2, usw.
• QA Kanal: 1.2.3-qa.1, 1.2.3-qa.2, usw.
• Staging Kanal: 1.2.3-rc.1, 1.2.3-rc.2, usw.
• Production Kanal: 1.2.3, 1.2.4, usw.

Verwendung semver mit Voreinstellung-Identifikatoren ist eine empfohlene Vorgehensweise, aber nicht strikt erforderlich. Der Schlüssel ist es, eine Versionsierungsschablone zu finden, die die Beziehungen zwischen Ihren Builds klar kommuniziert und mit Ihrem Teams Entwicklungsprozess übereinstimmt.

Rückgängig machen eines Live Update

Wenn Sie ein live update bereitstellen, das einen Fehler enthält oder anderweitig zurückgezogen werden muss, können Sie leicht auf einen vorherigen Build zurückgreifen. Aus der ‘Kanäle’-Sektion der Dashboard-Seite:

1. Klicken Sie auf den Namen des Kanals, den Sie zurücksetzen möchten
2. Find die Build, die du zurücksetzen möchtest, und klicke auf das Krönchen-Icon
3. Bestätigen Sie die Aktion

Die ausgewählte Version wird sofort wieder die aktive Version für diesen Kanal sein. Apps erhalten die zurückgerollte Version beim nächsten Mal, wenn sie nach einer Aktualisierung suchen.

Automatisierung der Bereitstellung

Für fortgeschrittene Workflows können Sie Ihre live update-Bereitstellungen automatisieren, indem Sie sie als Teil Ihres CI/CD-Pipelines ausführen. Durch die Integration von Capgo in Ihren Build-Prozess können Sie neue Pakete automatisch hochladen und ihnen Kanäle zuweisen, sobald Sie bestimmte Branches pushen oder neue Releases erstellen.

Besuchen Sie die CI/CD-Integration Dokumente, um mehr über die Automatisierung von Capgo-Live-Updates zu erfahren.

Mindestberechtigung für PR-Vorschauen

Use an App-Vorschau API-Schlüssel, wenn CI einen temporären Kanal pro Pull-Request benötigt, aber bestehende Haupt-/Standardkanäle nicht verwalten muss. Der Schlüssel bleibt der eigenen Organisation und der ausgewählten App zugeordnet; er hat einfach keine Organisationsebene. Jeder nicht öffentliche Vorschaukanal, den es erstellt, erhält seine eigenen automatischen, kanal-spezifischen Lebenszyklusberechtigungen.

1. Erstellen Sie einen sicheren API-Schlüssel, der nur auf das Preview-App-Verzeichnis beschränkt ist und auswählen App-Vorschau. Siehe API-Schlüssel.
2. Eine eindeutige, nicht öffentliche Kanal wie pr-123. Passen Sie nicht --default, --self-assign, Rollout-Optionen oder --delete-linked-bundle-on-upload.
3. Hochladen und die PR-Bundle in einer Befehlszeile, dann löschen Sie den Kanal und die Bundle, die Sie besitzen, wenn die PR geschlossen ist:

APP_ID="com.example.app"
PREVIEW_CHANNEL="pr-123"
BUNDLE_VERSION="1.2.3-pr.123"

npx @capgo/cli@latest bundle upload "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "$PREVIEW_CHANNEL" \
  --bundle "$BUNDLE_VERSION"

npx @capgo/cli@latest channel delete "$PREVIEW_CHANNEL" "$APP_ID" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found

bundle upload --channel erstellt einen fehlenden Kanal, lädt die Bundle hoch und fördert sie in einem Flow. Die Reinigung ist atomar und auf die Eigentümerschaft überprüft: Der Schlüssel kann nur einen Kanal löschen, den er erstellt hat und seinen verbundenen, ungeteilten Bundle. Er kann nicht ändern, fördern oder löschen einen bestehenden Haupt-/Standardkanal, einen anderen Vorschau-Schlüssels Kanal oder ein anderes Schlüssels Bundle.

Wenn Rezensionen eine QR code- oder Vorschau-URL benötigen, muss ein Administrator die Vorschau einmal für die App aktivieren:

npx @capgo/cli@latest app set "$APP_ID" --preview
npx @capgo/cli@latest get-qr "$APP_ID" --channel "$PREVIEW_CHANNEL" --apikey "$CAPGO_PREVIEW_KEY" --url

Ein App-Vorschau-Schlüssel kann keine Vorschau selbst aktivieren, da er keine Berechtigung für App-Einstellungen hat. In GitHub Aktionen führen Sie geheime Vorschau-Aufträge auf pull_request, not pull_request_targetund beschränken sie auf PRs innerhalb des gleichen Repositorys mit github.event.pull_request.head.repo.full_name == github.repository.

Zu einem Gerät bereitstellen

Jetzt, dass Sie die Kanäle verstehen, sind Sie bereit, Live-Updates auf echten Geräten zu deployen. Der grundlegende Prozess ist:

1. Installieren Sie die Capgo SDK in Ihrer App
2. Installieren Sie die __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ in Ihrer App
3. Hochladen eines Builds und ihm diesen Kanal zuweisen
4. Starte die App und warte auf die Aktualisierung!

Für eine detailliertere Anleitung, siehe das Live-Updates-Deploying guide. Viel Erfolg beim Aktualisieren!

Fortgeschrittene Kanalnutzung: Benutzersegmentierung

Kanäle können für mehr als nur Entwicklungsstufen verwendet werden. Sie sind ein mächtiges Werkzeug für die Benutzersegmentierung, das Funktionen wie:

• Funktionsschalter für verschiedene Benutzerstufen
• A/B-Testungen
• Schrittweise Einführung neuer Funktionen
• Beta-Test-Programme

Lernen Sie, wie Sie diese fortgeschrittenen Anwendungsfälle in unserem Leitfaden umsetzen. Wie Sie Benutzer nach Tarif und Kanälen segmentieren und Funktionsschalter und A/B-Testungen durchführen.

Fortfahren von Kanälen

Wenn Sie Kanäle verwenden Kanäle um Channelrouting und eine rollierende Veröffentlichung zu planen, verbinden Sie es mit Kanäle für die Implementierungsdetails in Kanälen, Kanäle für die Implementierungsdetails in Kanälen, zur Implementierungsdetail in Kanälen, für das Produktworkflow in der Beta-Testlösung, zur Produktworkflow in Testlösung für Beta-Versionen, für das Produktworkflow in der Version-Zielsystemlösung und Capgo Umgebungsbest Practices: Staging mit einem Mobile-App-ID für den praktischen Kontext in Capgo Umgebungsbest Practices: Staging mit einem Mobile-App-ID.