Kanäle

Ein Live-Update-Kanal verweist auf eine bestimmte JS-Bundle-Ausgabe Ihrer App, die mit allen Geräten geteilt wird, die auf das Abhören dieses Kanals für Updates konfiguriert sind. Wenn Sie installieren Sie die Capgo Live-Updates SDK in Ihrer App, überprüfen alle native Binärdateien, die auf diesen Kanal konfiguriert sind, bei jedem Start der App 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.

Kanäle bieten keine Vertraulichkeit

Kanäle steuern die Updateberechtigung, nicht die Paketgeheimhaltung. Selbst wenn ein Kanal privat ist oder die Selbstzuweisung deaktiviert ist, sollte jede unverschlüsselte Paketdatei, die auf Capgo hochgeladen wird, immer noch als öffentliches Asset behandelt werden, das an die Clients geliefert wird. Die Verschlüsselung schützt den Übertragungsweg und die Authentizität der Updates, aber die verschickten Pakete können immer noch mit ausreichendem Aufwand rückgängig gemacht werden, weil der öffentliche Schlüssel Teil des Clients ist. Siehe Verschlüsselung von Live-Updates für weitere Informationen.

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

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

1. Zwangsmapping eines Geräts (Dashboard) – Ein bestimmtes Geräte-ID manuell an einen Kanal anhängen. Verwenden Sie dies für dringende Debugging oder kontrolliertes Testen mit einem einzelnen echten Benutzer.
2. Cloud-Übernahme (pro-Gerät) über 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 den Aufruf macht 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 und wird nicht im Geräte-Übernahme-UI angezeigt. setChannel() and the backend validates that the target channel allows self-assignment. The selected channel is stored locally on that device, takes effect instantly, and is not shown in the Device Override UI.

Instantaner Channel-Wechsel mit setChannel()

Ab der Plugin-Version 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 (abhängig von Ihrer Hauptversion), setChannel() funktioniert es anders: Es kontaktiert den Backend, um zu überprüfen ob der Channel zugelassen ist (Überprüfung, ob Selbstzuweisung für diesen Channel aktiviert ist), dann speichert es den Channel lokal auf dem Gerät als defaultChannelDies bedeutet, dass der neue Channel sofort wirksam ist für den nächsten Update-Check—keine Wartezeit für die Replication. works differently: it contacts the backend to

Zuvor setChannel() speicherte die Kanalüberschreibung im Backend-Datenbank (wie Dashboard oder API Änderungen) und die Geräte mussten auf Datenreplication (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 eine sofortige Kanalwechsel ermöglicht.

Da setChannel() ist lokal nur, es schafft create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

Geräteüberschreibungseinträge im __CAPGO_KEEP_0__ Dashboard. Die Geräteüberschreibung-UI zeigt nur Überschreibungen an, die aus dem Dashboard oder dem öffentlichen __CAPGO_KEEP_1__ erstellt wurden. Hinweis:

Even wenn ein Kanal nach lokaler Einstellung verboten wird, wird der Backend die Kanalvalidierung während der Update-Überprüfungen durchführen, sodass die Sicherheit aufrechterhalten wird. When channel changes are made via the Dashboard or API, there is still a replication lag of up to 2 minutes before all edge servers reflect the change. For instant channel switching, use setChannel() Wenn Kanaländerungen über das Dashboard oder code vorgenommen werden, besteht noch ein Replication-Lag von bis zu 2 Minuten, bevor alle Edge-Server die Änderung widerspiegeln. Für einen sofortigen Kanalwechsel verwenden Sie

4. aus Ihrer App Capacitor—es validiert mit dem Backend und setzt den Kanal lokal für sofortigen Effekt. defaultChannel (Testbau-Standard) – Wenn vorhanden in capacitor.config.* und keine Zwang/Übernahme/lokale Kanal existiert, startet die App auf diesem Kanal (z. B. beta, qa, pr-123). Geplant für TestFlight/innere Builds, damit Tester automatisch auf einem Vorab-Release-Kanal landen. Produktionsbuilds lassen diesen normalerweise ungesetzt.
5. Cloud-Standardkanal (Hauptpfad ~99% der Benutzer) – Wenn Sie einen Standardkanal im Dashboard markieren, werden alle normalen Endbenutzer (kein Zwang, keine Dashboard/API-Übernahme, kein Plugin-Lokalkanal, keine Konfiguration-Standardkanal) hier angeschlossen. Ändern Sie ihn, um sofort auszurollen oder zurückzurufen – kein neuer Binärdatei. Wenn Sie plattform-spezifische Standards (z. B. eine iOS-only, eine Android-only, eine Electron-only) haben, landet jeder Gerät auf dem Standard, der seiner Plattform entspricht. Das Ignorieren des Cloud-Standard-Kanals ist erlaubt; in diesem Fall muss das Gerät auf Schritte 1-4 abgestimmt sein, um Updates zu erhalten.

Gute Praxis:

• Behandeln Sie 1-4 als Ausnahmen/Testing Layers; wenn Sie einen Cloud-Standard setzen, sollten realen Benutzern in ihn fließen. Wenn Sie ihn nicht setzen, sollten Sie bewusst sein, wie Benutzer angeschlossen werden (typischerweise via defaultChannel Konfigurieren Sie
• nur in Binärdateien, die Sie explizit an Tester verschicken. Das Ignorieren des Cloud-Standard-Kanals hält die Produktionslogik zentral im Dashboard. defaultChannel Verwenden Sie
• Use setChannel() sparsam in der Produktion—hauptsächlich für QA oder gezielte Diagnosen.

Wenn ein Kanal für die Plattform (iOS/Android/Electron-Toggle) deaktiviert ist, wenn er sonst ausgewählt werden würde, springt die Auswahl über ihn hinweg und geht weiter mit der Liste.

Zusammenfassung: Force > Dashboard/API Override > Plugin setChannel() lokaler Kanal > Config defaultChannel > Cloud Standard.

Standardverhalten des Kanals

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 an gezwungenen Zuordnungen, Überschreibungen oder einem defaultChannel in der Capacitor-Konfiguration, Updates.

• Einzelner Standard (am häufigsten) – Wenn ein Kanal iOS, Android und Electron aktiviert hat, wird er zum einzigen Standard; jedes Gerät ohne Überschreibungen wird hier anhaften.
• Plattform-spezifische Standards – Wenn Sie die Kanäle nach Plattform aufteilen (z.B. nur iOS aktivieren, nur Android aktivieren und nur Electron aktivieren), 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. ios-production Denken Sie daran, dass der Cloud-Standard und "in" denselben Entscheidungsschicht besetzen. Wenn Sie einen Cloud-Standard setzen, müssen Sie den Wert nicht in Ihrer __CAPGO_KEEP_0__-Konfiguration duplizieren – lassen Sie ihn leer für Produktionsbuilds. Reserve " für Binärdateien, die Sie absichtlich an Tester oder QA liefern, wenn Sie sie starten möchten, bevor sie auf einem Nicht-Produktionskanal sind, selbst wenn der Cloud-Standard anders ist. android-production Sie können die Standards jederzeit im Dashboard ändern. Wenn Sie einen Standard austauschen, folgen neue Geräte sofort den neuen Routen und bestehende Geräte folgen den normalen Vorherrschaftsregeln beim nächsten Mal, wenn sie sich anmelden. electron-production Einrichten eines Kanals

Einrichten eines Kanals defaultChannel Kanäle nach Plattform aufteilen 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 Kanäle nach Plattform aufteilen defaultChannel Kanäle nach Plattform aufteilen

Kanäle nach Plattform aufteilen

Kanäle nach Plattform aufteilen

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

1. Gehe zur 'Kanäle'-Sektion der Capgo-Oberfläche
2. Klicke auf den Button 'Neuer Kanal'
3. Gib einen Namen für den Kanal ein und klicke auf 'Erstellen'

Kanalnamen können alles sein, was Sie möchten. 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 konfigurieren 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 das Development Kanal.

Öffnen Sie Ihr capacitor.config.ts (oder capacitor.config.json) Datei. Unter der plugins Abschnitt, setzen Sie optional 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 Web-Anwendung und führen Sie npx cap sync aus, 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.

Achtung

Reihenfolge der Kanalwahl: Zwang > API-Geräteüberschreibung > Plugin setChannel() lokaler Kanal > Konfiguration defaultChannel > Standardwerte von Cloud.

Verwenden defaultChannel nur in Test-/Internen Builds; löschen Sie es für die Produktion, damit die Benutzer dem Cloud-Standard folgen, anstatt die Routen in der native Konfiguration zu duplizieren.

Sie können den Zwang (Pin) eines Geräts oder eine Überschreibung später noch 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 Routen-Szenarien.
• Plattformfilter: Aktivieren oder deaktivieren Sie die Lieferung an iOS, Android, oder Electron Geräte pro Kanal.
• Deaktivieren Sie die automatische Downgrade unter Native: Verhindert die Übermittlung einer Aktualisierung, wenn die Geräte-App-Version neuere ist als die Kanal-Bundle (z.B. Gerät auf 1.2.3, während der Kanal 1.2.2 hat).
• Ermöglichen Sie Entwicklungsbuilds: Ermöglichen Sie Aktualisierungen für Entwicklungsbuilds (nützlich für Tests).
• Ermöglichen Sie Emulatoren/Geräten: Ermöglichen Sie Aktualisierungen für Emulatoren/Simulatoren (nützlich für Tests).
• Ermöglichen Sie die Selbstzuweisung von Geräten: Lassen Sie die App auf diesem Kanal umschalten, indem Sie setChannelbenutzen. Wenn deaktiviert, setChannel fehlschlägt für diesen Kanal.

Progressive Rollouts

Ein Kanal kann ein stabiles Bundle beibehalten, während er ein separates Rollout-Ziel allmählich einer festen Gerätegruppe zugänglich macht. Sie können ein Update aussetzen, wieder aufnehmen, vorantreiben, zurückrollen und eine automatische Fehlerantwort konfigurieren, ohne den Kanal für alle zu ändern. Siehe Progressive Rollouts für das Liefermodell, das Dashboard-Workflow, API Felder und CLI Befehle.

Auto-Update-Strategien deaktivieren

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

• major: Blockiert ein Zielpaket, dessen Hauptversion höher ist als die nativ basierte Basisversion des Geräts (version_buildBeispiel: 1.2.3 -> 2.0.0 ist blockiert; 1.2.3 -> 1.9.0 ist erlaubt.
• minor: Blockiert ein Zielpaket, dessen Haupt- oder Minorversion sich von version_buildBeispiel: 1.2.3 -> 1.3.0 ist blockiert; 1.2.3 -> 1.2.4 ist erlaubt.
• Patch: Strangster Modus. Blockiert 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 wird blockiert.
• Metadaten: Erfordert eine Mindestversion von Update-Metadaten auf jedem Bundle. Konfigurieren Sie dies über CLI mit --min-update-version oder --auto-min-update-versionwird blockiert. Wenn fehlt, wird der Kanal als fehlerhaft markiert und Updates werden abgelehnt, bis sie gesetzt werden.
• keine: Allen Updates zufolge Kompatibilität nach semver.

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

Erhalten Sie weitere Details und Beispiele in der Disable-Updates-Strategie unter /docs/cli/commands/#disable-updates-strategie.

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

Die setChannel() Methode ermöglicht es Ihrer App, programmatisch zwischen Kanälen umzuschalten. Dies ist insbesondere nützlich für:

• QA/Debug-Menüs, bei denen Tester zwischen Kanälen umschalten können
• Flüsse für die Beta-Programm-Opt-in
• Implementierungen von Feature-Flags
• 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+)

Wann 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. Lokale Speicheraktualisierung: Wenn die Überprüfung erfolgreich ist, wird der Kanal im Gerätespeicher als defaultChannel
3. Echtzeit-Effekt: Der nächste Update-Check verwendet den neuen Kanal sofort (keine Wartezeit für die Replikation)

Weshalts dieses wichtig ist: Bei älteren Versionen setChannel() speicherte die Übernahme des Kanal-Übersetzers im Backend-Datenbank (ebenso wie Dashboard oder API Änderungen). Geräte mussten auf Backend-Replikation (bis zu 2 Minuten) warten, bevor die Kanaländerung wirksam wurde. Jetzt setChannel() liest nur vom Backend (für die Validierung) und speichert lokal, was Kanalwechsel sofort wirksam macht.

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

Sicherheitshinweis: Even wenn die Kanalberechtigungen nach der lokalen Einstellung geändert werden (z.B. Selbstzuweisung deaktiviert), wird der Backend die Kanalvalidierung während der Update-Überprüfungen sicherstellen, um die Sicherheit aufrechtzuerhalten.

Vergleich der Kanaländerungsverfahren:

Methode	Wirkungsdauer	Persistiert in	Gezeigt in Geräte-Überschreibungs-UI	Verwendungsfall
setChannel() Ja	Von Plugin	Instant	Gerät nur (lokal)	Nein
Benutzerinitiierte Kanalwechsel in-app	Dashboard-Geräte-Überschreibung	Hoch bis 2 min	Hintergrund-Datenbank	Ja
API Kanalzuweisung	Bis zu 2 Minuten	Hintergrund-Datenbank	Ja	Automatisierte Hintergrundintegrationen

Für die beste Benutzererfahrung bei der Erstellung von UIs für das Wechseln von Kanälen, verwenden Sie immer die Methode des Plugins. setChannel() Mindestversionen für lokale Kanalwechsel:

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

Ein Bundle einer Kanal zuweisen

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 durchführen:

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 abonniert ist, erhält das Update beim nächsten Mal, wenn sie nach einem Update suchen.

Sie können auch Builds auf Kanäle aus der ‘Bundles’-Sektion des Capgo-Dashboards zuweisen. Klicken Sie auf das Menüsymbol neben einem Build und wählen Sie ‘Auf Kanal zuweisen’ aus, 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 Versionsnummerierung Ihrer Bundles empfehlen wir die Verwendung semantisches Versionsmanagement 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 dass CLI von dem kanalbezogenen Bundle bis zu einem freien Namen springt. Mit ai, erkennt Workers AI den Grad von der lokalen vs. vorherigen Delta-Manifest (fällt zurück auf patch mit keinem vorherigen Capgo-Version). Sie können es nicht mit --bundle kombinieren. Siehe und das __CAPGO_KEEP_0__-Referenz CLI reference.

Diese Vorgehensweise hat mehrere Vorteile:

• Es kommuniziert offensichtlich die Beziehung zwischen Builds. 1.2.3-beta.1 ist offensichtlich eine Vorabversion von 1.2.3.
• Es ermöglicht die Wiederholung von Versionsnummern über Kanäle, was die Verwirrung reduziert.
• Es ermöglicht klare Rückschrittspfade. Wenn Sie von 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önnten:

• Development Kanal: 1.2.3-dev.1, 1.2.3-dev.2etc.
• QA Kanal: 1.2.3-qa.1, 1.2.3-qa.2etc.
• 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 Voreinstellungen für vorveröffentlichte Identifikatoren ist eine empfohlene Vorgehensweise, aber nicht strikt erforderlich. Der Schlüssel ist, 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

Wenn Sie ein Live-Update bereitstellen, das ein Fehler einführt oder anderweitig rückgängig gemacht werden muss, können Sie leicht auf einen vorherigen Build zurückkehren. Aus der „Kanäle“-Sektion der Oberfläche:

1. Klicken Sie auf den Namen des Kanals, den Sie rückgängig machen möchten
2. Finden Sie den Build, auf den Sie zurückkehren möchten, und klicken Sie auf das Krönchen-Symbol
3. Bestätigen Sie die Aktion

Die ausgewählte Build wird sofort wieder die aktive Build für diesen Kanal. Apps erhalten die zurückgesetzte 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 als Teil Ihres CI/CD-Pipelines automatisieren. 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 Dokumentationen, um mehr über die Automatisierung von Capgo-Live-Updates zu erfahren.

Mindestberechtigung für Vorabansichten

Verwenden Sie ein 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 Organisationseinheit. Jeder nicht öffentliche Vorschaukanal, den es erstellt, erhält seinen eigenen automatischen, kanal-basierten Lebenszyklusberechtigung.

1. Haben Sie einen Organisation administrator einen sicheren API-Schlüssel erstellen lassen, der nur auf den Vorschauapp anwendbar ist und auswählen App-VorschauSiehe API-Schlüssel.
2. Verwenden Sie einen eindeutigen, nicht öffentlichen Kanal wie pr-123Passen Sie keine --default, --self-assignAusrollen und Optionen oder --delete-linked-bundle-on-upload.
3. Laden Sie das PR-Bundle hoch und fördern Sie es in einem Befehl, dann löschen Sie den Kanal und das Bundle, wenn der 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 das Bundle hoch und fördert es in einem Workflow. 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 Kanal eines anderen Vorschau-Schlüssels oder ein Bundle eines anderen Schlüssels nicht ändern, fördern oder löschen.

Wenn Rezensenten eine 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

Ein App-Vorschau-Schlüssel kann die Vorschauen nicht selbst aktivieren, da er keine Anwendungseinstellungen hat. In GitHub Aktionen führen Sie geheime Vorschau-Aufträge auf pull_request, nicht pull_request_target, und beschränken Sie sie auf gleiche-Repository-PRs mit github.event.pull_request.head.repo.full_name == github.repository.

Auf einem Gerät bereitstellen

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

1. Installieren Sie das Capgo SDK in Ihrer App
2. Konfigurieren Sie die App, um auf Ihren gewünschten Kanal zu hören
3. Ein Build hochladen und diesem Kanal zuweisen
4. Die App starten und auf die Aktualisierung warten!

Für eine detailliertere Anleitung siehe das Live-Updates bereitstellen Leben lang aktualisieren!

Erweiterte Kanalnutzung: Benutzersegmentierung

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

• Funktionsschalter für verschiedene Benutzerstufen
• A/B-Tests
• Schrittweise Einführung neuer Funktionen
• Beta-Testprogramme

Erfahren Sie, wie Sie diese fortgeschrittenen Anwendungsfälle in unserer Anleitung umsetzen können: Wie Sie Benutzer nach Tarif und Kanälen segmentieren und Feature-Flags und A/B-Tests durchführen können.

Weiterhin von Kanälen

Wenn Sie Kanäle verwenden Kanäle Kanäle zur Planung der Kanalsteuerung und der schrittweisen Veröffentlichung sowie zum Verbinden mit Kanäle für die Implementierungsdetails in Kanälen für die Implementierungsdetails in Kanälen Beta-Testlösung Beta-Testlösung für das Produktworkflow in Beta-Testlösung Version-Zielsystem-Lösung für das Produktworkflow in Version-Zielsystem-Lö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.