Kanäle

A Live Update-Kanal verweist auf eine bestimmte JS-Bundle-Ausgabe Ihrer App, die an alle Geräte weitergegeben wird, die auf das Update lauschen und auf den Kanal eingestellt sind. Wenn Sie das __CAPGO_KEEP_0__ Live-Updates-__CAPGO_KEEP_1__ in Ihrer App installieren, überprüfen alle auf den Kanal eingestellten native Binärdateien bei jedem App-Start nach verfügbaren Updates. Sie können die Ausgabe, auf die ein Kanal verweist, jederzeit ändern und können auch auf vorherige Builds zurückkehren, wenn erforderlich. install the Capgo Live Updates SDK Kanäle Bieten Keine Vertraulichkeit

Live-Update-Verschlüsselung

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 Wie ein Gerät einen Kanal auswählt (Priorität) Abschnitt mit dem Titel “Wie ein Gerät einen Kanal auswählt (Priorität)”

Wenn ein Gerät nach einem Update sucht, entscheidet __CAPGO_KEEP_0__, welcher Kanal in dieser strengen Reihenfolge (höchste Priorität zuerst) verwendet wird:

When a device checks for an update, Capgo decides which channel to use in this strict order (highest priority first):

1. Zwangsmapping des Geräts (Dashboard) – Manuell eine bestimmte Geräte-ID auf einen Kanal festlegen. Verwenden Sie dies für dringende Debugging oder kontrolliertes Testen mit einem einzelnen echten Benutzer. Dies gewinnt immer.
2. Cloud-Übernahme (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 erneute Installation des Binärs löscht ihn nicht; die Löschung der Geräte-Einträge tut es auch nicht.
3. Plugin setChannel() lokaler Kanal – Erstellt, wenn die App aufgerufen wird 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-Übernahme-UI angezeigt.

Instant Channel Switching mit setChannel()

Ab Plugin-Version 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 (abhängig von Ihrer Hauptversion), setChannel() funktioniert anders: es kontaktiert den Backend, um überprüfen Sie, dass der Kanal erlaubt ist (Überprüfung, ob Selbstzuweisung für diesen Kanal aktiviert ist), dann speichert der Kanal ortsintern auf dem Gerät als . Das bedeutet, dass der neue Kanal sofort defaultChannelwirkt für die nächste Aktualisierungsprüfung—keine Wartezeit für die Replikation. Zuvor

speicherte die Kanal-Überschreibung im Backend-Datenbank (wie Dashboard oder __CAPGO_KEEP_0__ Änderungen) und Geräte mussten auf Datenreplikation (bis zu 2 Minuten) warten, bevor der neue Kanal erkannt wurde. Die neue Verhaltensweise liest nur vom Backend (für die Validierung) und speichert lokal, was den Kanalwechsel sofort macht. setChannel() saved the channel override to the backend database (like Dashboard or API changes), and devices had to wait for data replication (up to 2 minutes) before the new channel was recognized. The new behavior only reads from the backend (for validation) and stores locally, making channel switches instant.

ortsintern ist, macht es setChannel() nicht deshalb erstelle eine Eintragsperipherieüberschreibung im Capgo-Dashboard. Die Peripherieüberschreibungs-UI zeigt nur Überschreibungen an, die aus dem Dashboard oder dem öffentlichen API erstellt wurden.

Hinweis: Even wenn ein Kanal nach der lokalen Festlegung verboten wird, wird der Backend während der Update-Überprüfungen den Kanal noch immer validieren, sodass die Sicherheit aufrechterhalten wird.

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

4. Capacitor-Konfiguration defaultChannel (Standardbau für Testversion) – Wenn vorhanden in capacitor.config.* und keine Zwangs-/Überschreibungs-/Lokalkanal existiert, startet die App auf diesem Kanal (z.B. beta, qa, pr-123). Für TestFlight-/Internetauftritte vorgesehen, damit Tester automatisch auf einem Vorkabelkanal landen.
5. Hauptkanal (primäre Pfad ~99% der Benutzer) – Wenn Sie eine Standardkanal in der Dashboard markieren, werden alle normalen Endnutzer (kein Zwang, keine Dashboard/API-Übernahme, keine Plugin-Local-Kanal, keine Konfiguration Standardkanal) hier angeschlossen. Ändern Sie es, 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 der Cloud-Standard ist erlaubt; in diesem Fall muss das Gerät Schritt 1–4 entsprechen, um Updates zu erhalten.

Best Practice:

• Behandeln Sie 1–4 als Ausnahmen / Testebereiche; wenn Sie einen Cloud-Standard setzen, sollten sich echte Benutzer in ihn einfließen. Wenn Sie ihn nicht setzen, seien Sie bei der Entscheidung, wie Benutzer angeschlossen werden (typischerweise via Konfiguration oder per-Geräte-Übernahmen), vorsichtig. defaultChannel Konfigurieren Sie nur
• in Binärdateien, die Sie explizit an Tester verschicken. Das Ignorieren des Standardkanals hält die Produktionslogik zentral im Dashboard. defaultChannel Verwenden Sie
• sparsam in der Produktion – hauptsächlich für QA oder gezielte Diagnosen. setChannel() Wenn ein Kanal für die Plattform (iOS/Android/Electron-Schalter) deaktiviert ist, wenn er sonst ausgewählt werden würde, springt der Auswahlprozess darüber hinweg und setzt sich fort.

Zusammenfassung: Zwang > Dashboard/__CAPGO_KEEP_0__-Übernahme > Plugin-Local-Kanal > Konfiguration

Summary: Force > Dashboard/API Override > Plugin setChannel() Summary: Force > Dashboard/__CAPGO_KEEP_0__ Override > Plugin local channel > Config defaultChannel > Cloud Default.

Standardkanalverhalten

Die Festlegung eines Cloud-Standards ist optional, aber es dient normalerweise als allgemeiner Pfad für neue Geräte. Ohne einen solchen, erhalten nur Geräte, die sich auf zwingenden Zuordnungen, Überschreibungen oder einem defaultChannel im Capacitor-Konfiguration

• aktualisierungen. Wenn Sie sich entscheiden, Standards zu 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 Überschreibungen wird hier angeschlossen. Plattform-spezifische Standards ios-production – Wenn Sie Kanäle nach Plattformen aufteilen (z.B. android-production mit nur iOS aktiviert electron-production mit nur Android aktiviert und

mit nur Electron aktiviert), markieren Sie jeden als Standard für seine Plattform. iOS-Geräte gehen zum iOS-Standard, Android-Geräte zum Android-Standard und Electron-Anwendungen zum Electron-Standard. Beachten Sie, dass der Cloud-Standard und defaultChannel In beiden besetzen dieselbe Entscheidungsebene. Wenn Sie einen Cloud-Standard setzen, müssen Sie den Wert in Ihrer __CAPGO_KEEP_0__-Konfiguration nicht duplizieren – lassen Sie ihn leer. capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel für Binärdateien, die Sie absichtlich an Tester oder QA liefern, wenn Sie möchten, dass sie auf einem Nicht-Produktionskanal starten, selbst wenn der Cloud-Standard anders ist. defaultChannel Sie können die Standards jederzeit im Dashboard ändern. Wenn Sie einen Standard austauschen, befolgen neue Geräte den neuen Routing sofort und bestehende Geräte folgen den normalen Vorrangregeln beim nächsten Mal, wenn sie sich anmelden.

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 den Kanal umbenennen oder löschen, wann immer Sie möchten. Um zusätzliche Kanäle später hinzuzufügen:

Klicke auf den „Neuen Kanal“-Button

1. Go to the “Channels” section of the Capgo dashboard
2. Kanalnamen können alles sein, was Sie möchten. Eine gängige Strategie besteht darin, Kanäle Ihren Entwicklungsstufen zuzuordnen, wie z.B.:
3. __CAPGO_KEEP_0__

__CAPGO_KEEP_0__

• 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

Konfiguration des Kanals in Ihrer App

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 Kanal.

Öffnen Sie Ihr capacitor.config.ts (oder capacitor.config.json) Datei. Unter der plugins Abschnitt, setzen Sie optional defaultChannel für Test Builds (intern / QA). Für Produktionsbuilds 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.
    },
  },
};

Als Nächstes bauen Sie Ihre Web-App und führen 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 den sie zuvor konfiguriert waren.

Vorsicht

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

Verwenden defaultChannel Erstellt nur in test/internen Builds; löschen Sie es für die Produktion, damit die Benutzer die Cloud-Standard (wenn gesetzt) anstelle der Routing-Duplikation in der native Konfiguration folgen.

Sie können dennoch ein Gerät zwingen (festlegen) oder eine Überschreibung später anwenden – diese überschreiben sofort den Konfigurationswert.

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. Siehe „Standardkanalverhalten“ für Routing-Szenarien.
• Plattformfilter: Aktivieren oder deaktivieren Sie die Lieferung an iOS, Android, oder Electron Geräte pro Kanal.
• Unter native deaktivieren Sie die automatische Downgrade: Verhindert die Lieferung eines Updates, wenn das Geräte-native-App-Version neuere ist als die Kanal-Bundle (z.B. Gerät auf 1.2.3, während der Kanal 1.2.2 hat).
• Entwicklungsbuilds zulassen: Ermöglichen Sie Updates für Entwicklungsbuilds (nützlich für die Testung).
• Zulassen von Emulatordiensten: Genehmigung von Updates für Emulatoren/Simulatoren (wirksam für Tests).
• Zulassen der Selbstzuweisung von Geräten: Lässt die App zu diesem Kanal umschalten, sobald sie gestartet wird ( setChannelWenn deaktiviert, setChannel funktioniert nicht für diesen Kanal.

Schrittweise Rollouts

Ein Kanal kann ein stabiles Bundle beibehalten, während er ein separates Rollout-Ziel einem festen Gerätekohort allmählich zugänglich macht. Sie können ein Rollout einstellen, wieder aufnehmen, vorantreiben, zurückrollen und eine automatische Fehlerantwort konfigurieren, ohne den Kanal für alle zu ändern. Weitere Informationen finden Sie unter Schrittweise Rollouts für das Liefermodell, die Dashboard-Workflow, API Felder und CLI Befehle.

Automatisierte Updatestrategien deaktivieren

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

• major: Blockt ein Ziel-Bundle, dessen Hauptversion höher ist als die nativ basierte Basisversion des Geräts (version_build). Beispiel: 1.2.3 -> 2.0.0 er wird blockiert; 1.2.3 -> 1.9.0 er wird zugelassen.
• minor: Blockt ein Ziel-Bundle, dessen Haupt- oder Minorversion sich von version_build unterscheidet. Beispiel: 1.2.3 -> 1.3.0 er wird blockiert; 1.2.3 -> 1.2.4 er wird zugelassen.
• patch: Striktster Modus. Blockt jede Änderung an der Haupt-, Minor- oder Patchnummer. Nur Suffix-Änderungen sind während MAJOR.MINOR.PATCH identisch bleibt, zulässig. Beispiele: 1.0.0-beta.1 -> 1.0.0-beta.2 er wird zugelassen, 1.0.0+build.1 -> 1.0.0+build.2 er wird zugelassen, 1.0.0 -> 1.0.1 Wird blockiert.
• metadata: Erfordert eine Mindestaktualisierungsversion in jedem Bundle. Konfigurieren Sie über CLI mit --min-update-version oder --auto-min-update-version. Wenn fehlend, wird das Channel als fehlerhaft markiert und Updates werden abgelehnt, bis es gesetzt ist.
• none: Allen Updates entsprechend der semver-Kompatibilität zulassen.

Diese Strategien vergleichen das Ziel-Bundle des Kanals mit der native Basis, die als version_build, nicht mit dem aktuellen heruntergeladenen Bundle, das als version_name.

Learnen Sie mehr Details und Beispiele in Disable updates strategy unter /docs/cli/commands/#disable-updates-strategy.

Beispiel (CLI):

# 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

Mit setChannel() aus Ihrer App verwenden

Der setChannel() Methode ermöglicht es Ihrer App, sich programmatisch bei Laufzeit auf Kanäle umzuschalten. Dies ist insbesondere nützlich für:

• QA/Debug-Menüs, bei denen Tester zwischen Kanälen umschalten können
• Beta-Programm-Opt-in-Flüsse
• Feature-Flag-Implementierungen
• Szenarien für A/B-Tests

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() heißt:

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

Warum das wichtig ist: In älteren Versionen, setChannel() speicherte den Kanal-Übertrag in der Backend-Datenbank (gleich wie Dashboard oder API-Änderungen). 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.

Dashboard-Ansicht: Ein Kanal, der mit dem Plugin konfiguriert wurde, macht das Gerät nicht als Geräte-Überschreibung im Capgo-UI sichtbar. Nur Kanalzuweisungen, die aus der Konsole oder dem öffentlichen API erstellt wurden, werden dort aufgelistet. Verwenden Sie die Konsole oder API , wenn Sie eine von Administratoren sichtbare Überschreibung benötigen.

Sicherheitshinweis: Auch wenn die Berechtigungen eines Kanals nach der lokalen Konfiguration geändert werden (z.B. Selbstzuweisung deaktiviert), wird der Backend die Kanalberechtigungen während der Update-Überprüfungen noch immer validieren, um die Sicherheit aufrechtzuerhalten.

Vergleich der Kanaländerungsverfahren:

Methode	Wirkungszeit	Persistiert	Sichtbar in Geräte-Überschreibungs-UI	Verwendungsfall
setChannel() von Plugin	Echtzeit	Gerät nur (lokal)	Nein	Benutzerinitiierte Kanalwechsel in der App
Dashboard-Geräteüberschreibung	Höchstens 2 min	Hintergrund-Datenbank	Ja	Administratorinitiierte Änderungen für bestimmte Geräte
API Kanalzuweisung	Höchstens 2 min	Hintergrund-Datenbank	Ja	Automatisierte Hintergrundintegrationen

For die beste Benutzererfahrung bei der Erstellung von UIs, die zwischen Kanälen wechseln, verwenden Sie immer die Funktion des Plugins. setChannel() Methoden.

Mindestversionen für lokale Kanalwechsel: 5.34.0, 6.34.0, 7.34.0, oder 8.0.0 (abhängig von Ihrer Hauptversion). Jede kleine Versionennummer entspricht dem gleichen Funktionsumfang in allen Hauptversionen (z.B. X.34.0 enthält die gleichen Funktionen, egal ob X 5, 6, 7 oder 8 ist). Siehe Plugin-Installation Versionstags.

Zuweisen eines Bundles zu einem Kanal

Um eine Live-Update zu deployen, müssen Sie ein neues JS-Bundle-Build hochladen und es einem Kanal zuweisen. Sie können dies in einem Schritt mit dem Capgo CLI:

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

Dies wird Ihre gebauten Web-Assets hochladen und die neue Bundle als aktives Build für das Development Kanal. Jede Anwendung, die auf das Kanal lauscht, wird die Aktualisierung beim nächsten Mal erhalten, wenn sie nach einer aktualisiert.

Sie können auch Builds auf Kanäle von der “Bundles”-Sektion des Capgo-Dashboards zuweisen. Klicken Sie auf das Menüsymbol neben einem Build und wählen Sie “Zuweisen an Kanal” aus, um den Kanal für das 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 Versionsnummerierung Ihrer Bundles empfehlen wir die Verwendung von semantischen Versionen mit Capgo’s Semver-Tester und Voreinstellungen für Kanal-spezifische Builds. Zum Beispiel könnte eine Beta-Version als 1.2.3-beta.1.

dieser Ansatz mehrere Vorteile bietet:

• Es kommuniziert offensichtlich die Beziehung zwischen Builds. 1.2.3-beta.1 ist offensichtlich eine Voreinstellung für 1.2.3.
• It ermöglicht die Wiederholung von Versionsnummern über Kanäle, was die Verwirrung reduziert.
• It ermöglicht klare Rückerstattungspfade. Wenn Sie von 1.2.3, wissen 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.4Semver mit Vorklassifikationsidentifikatoren verwenden

Verwendung von 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-Updates

Abschnitt mit dem Titel „Rückgängig machen eines Live-Updates“

Klicken Sie auf den Namen des Kanals, auf den Sie zurückgreifen möchten

1. Finden Sie den Build, auf den Sie zurückgreifen möchten, und klicken Sie auf das Krönchen-Symbol
2. Rückgängig machen des Builds
3. Der ausgewählte Build wird sofort wieder der aktive Build für diesen Kanal. Apps erhalten die zurückgegriffene Version beim nächsten Mal, wenn sie nach einer Aktualisierung suchen.

Section titled “

Automatisierung der Bereitstellung

Für fortgeschrittene Workflows können Sie Ihre Live-Update-Bereitstellungen als Teil Ihres CI/CD-Pipelines automatisieren. Indem Sie Capgo in Ihren Build-Prozess integrieren, können Sie neue Bundle automatisch hochladen und ihnen Kanäle zuweisen, sobald Sie bestimmte Branches pushen oder neue Releases erstellen.

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

Mindestberechtigte PR-Vorschau

Verwenden Sie einen 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 gebunden; er hat einfach keine Organisationsebene.

1. Haben Sie einen Organisation administrator einen sicheren API-Schlüssel erstellen, der nur für die Vorschau-App limitiert ist und ausgewählt App-Vorschau. Siehe API Schlüssel.
2. Verwenden Sie einen einzigartigen, nicht öffentlichen 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 einem Befehl promoten, dann löschen Sie den Besitzkanal und die Bundle, wenn die PR schließt:

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 das Bundle hoch und promotet es in einem Flow. Die Reinigung ist atomar und eignungsüberprüft: Der Schlüssel kann nur einen Kanal löschen, den er erstellt hat und seinen verbundenen, nicht geteilten Bundle. Er kann einen bestehenden Haupt-/Standardkanal, einen anderen Vorschau-Schlüssels Kanal oder einen anderen Schlüssels Bundle nicht ändern, promoten oder löschen.

Wenn Rezensenten ein QR code oder Vorschau-URL benötigen, muss ein Administrator die Vorschauen 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

An App Preview key cannot enable previews itself because it has no app-settings permission. In GitHub Actions, run secret-bearing preview jobs on pull_requestIn __CAPGO_KEEP_0__ Aktionen, führen Sie geheime Vorschaujobs auf pull_request_target, nicht github.event.pull_request.head.repo.full_name == github.repository.

, und beschränken Sie sie auf PRs mit gleicher Repository wie

Abschnitt mit dem Titel „Auf einem Gerät bereitstellen“

1. Install the Capgo SDK in your app
2. Installieren Sie die __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ in Ihrer App
3. Konfigurieren Sie die App, um auf Ihren gewünschten Kanal zu hören
4. Ein Build hochladen und diesem Kanal zuweisen

Die App starten und auf das Update warten! Für eine detailliertere Anleitung siehe die Live-Updates bereitstellen guide. Viel Erfolg beim Aktualisieren!

Erweiterte 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-Test
• Schrittweise Einführung neuer Funktionen
• Testprogramme für Beta-Versionen

Erhalten Sie Informationen, wie Sie diese erweiterten Anwendungsfälle in unserer Anleitung umsetzen können: Wie Sie Benutzer nach Tarif und Kanälen segmentieren und Funktionsschalter und A/B-Test durchführen.

Fortsetzen Sie mit Kanälen

Wenn Sie Channels verwenden, um die Kanalroutenplanung und die rollende Veröffentlichung zu planen, verbinden Sie es mit Channels für die Implementierungsdetails in Channels, Channels für die Implementierungsdetails in Channels, Beta-Testlösung für den Produktworkflow in Beta-Testlösung, Versionziel-Lösung für den Produktworkflow in Versionziel-Lösung, und Capgo Environment Best Practices: Staging with One Mobile App ID for the practical context in Capgo Environment Best Practices: Staging with One Mobile App ID.