Fix Capgo Standardkanal nicht aktualisieren

Fix __CAPGO_KEEP_0__ Standardkanal nicht aktualisieren Capgo Neue Geräte werden sofort eingerichtet. Bestehende Installationen bleiben auf ihrem alten Kanal, bis sie sich erneut anmelden, was viele Fälle erklärt, in denen ein Capgo Cloud-Standardkanal nicht aktualisiert wird.

Arbeiten Sie durch die Überprüfungen in der Reihenfolge. Bestätigen Sie zunächst die Gerätezuweisung, dann die App-Build, den Synchronisierungsstatus, die Rollout-Regeln, die Protokolle und die Rollback-Einstellungen.

Inhaltsverzeichnis

• Schritt 1: Bestätigen Sie, dass das Gerät dem Standardkanal zugewiesen ist.
• Schritt 2: Überprüfen Sie die App, die Native Runtime und die Update-Kompatibilität.
• Schritt 3: Überprüfen Sie, ob die Bereitstellung tatsächlich den Standardkanal erreicht hat.
• Schritt 4: Zwingen Sie eine frische Synchronisierung an und überprüfen Sie die Geräteseitigen Protokolle.
• Schritt 5: Überprüfen Sie die Rollout-Regeln, die Versionsgitter und die automatische Rollback-Funktion.
• Schritt 6: Verwenden Sie Echtzeit-Analysen, um den genauen Fehlerpunkt zu finden.
• Schritt 7: Verhindern Sie, dass der Standardkanal veraltet wird.
• Häufig gestellte Fragen
• Zusammenfassung

Schritt 1: Bestätigen Sie, dass das Gerät der Standardkanal zugewiesen ist

Ziel ist es herauszufinden, welches Regelwerk derzeit die Gerätekennung bestimmt. Ein Cloud-Standard gilt nur, wenn eine stärkere Zuweisung das Gerät nicht bereits beansprucht hat.

Öffnen Sie das Capgo-Dashboard und überprüfen Sie das betroffene Gerät. Überprüfen Sie dessen aktuelle Kanal, App-ID, Version und letzten Check-in-Zeit. Vergleichen Sie diese Werte mit einem Gerät, das die erwartete Aktualisierung erhalten hat. Diese Vergleich zeigt oft schnell den Fehler auf.

Die Kanalwahl folgt einer Reihenfolge. Ein zwingender Kanal hat Vorrang. Ein Dashboard- oder API-Geräte-Übertrag kommt als nächstes. Ein lokaler Kanal, der durch die App gesetzt wurde, folgt dann. Dann prüft Capgo die native App-Konfiguration. Der Cloud-Standard ist der Ausfall.defaultChannelDiese Reihenfolge bedeutet, dass ein Gerät einen geänderten Cloud-Standard ohne Dashboard-Fehler ignorieren kann. Zum Beispiel kann ein Testbau immer noch einen lokalen Kanal von einem früheren Test haben. Die App verwendet diesen lokalen Wert, bis Sie ihn löschen.

Verwenden Sie das

__CAPGO_KEEP_0__-Updater-Debugging-Guide Capgo updater debugging guide Nächsten, überprüfen Sie Ihre __CAPGO_KEEP_0__-Konfiguration. Eine typische Konfiguration kann einen Kanal wie folgt enthalten:

Der Feld ist optional. Wenn Sie es auslassen, kann das Gerät den Cloud-Standard übernehmen. Das kann gut für Produktionsbuilds funktionieren, da die Kanalroutung im Capacitor-Cloud bleibt. Wenn Sie es einfügen, stellen Sie sicher, dass der Wert dem tatsächlich bereitgestellten Kanal entspricht.

const config = { plugins: { CapacitorUpdater: { defaultChannel: 'production' } }
}

Schritt 2: Überprüfen Sie die Capgo-Konfiguration

Now suchen Sie nach lokalen Überschreibungen in der Anwendung code. Ein Aufruf zusetChannel()ändern die lokale Zwischenspeicherung. Es wird keine Backend-Überschreibung erstellen. Das Dashboard zeigt daher möglicherweise keine Überschreibung an, obwohl die App weiterhin die lokale Kanal verwendet.

Löschen Sie diesen lokalen Wert, wenn das Gerät wieder auf die normale Routensteuerung zurückkehren soll. Verwenden Sie den Plugin-Methode, die die Geräte-Kanal-Zuweisung entfernt, oder entfernen Sie code, das den Kanal festlegt, und installieren Sie die App erneut, um einen sauberen Test durchzuführen.

Hauptergebnis: Ein geänderter Cloud-Standard kann eine stärkere Geräte-, App- oder lokale Kanalzuweisung nicht ersetzen.

Schritt 2: Überprüfen Sie die App, Native Runtime und Update-Kompatibilität

Ziel ist es, zu beweisen, dass die installierte App den bereitgestellten Bundle akzeptieren kann. Ein korrekter Kanal kann jedoch immer noch keine Aktualisierung an ein inkompatibles Native Runtime liefern.

Beginnen Sie mit der App-ID. Die auf dem Gerät installierte App muss die gleiche App-Identität wie das Projekt verwenden, in dem Sie den Bundle hochgeladen haben. Ein Missmatch kann wie ein Kanalproblem aussehen, weil das Gerät die falsche Capgo-App überprüft.

Vergleichen Sie dann die Native Runtime-Version mit den Kompatibilitätsregeln des Bundles. Capgo-Live-Updates können JavaScript, CSS und Web-Assets ändern. Sie können jedoch keine Native-Plugin hinzufügen oder die Native-Projekt code nach dem Versand der App ändern. Native-Änderungen benötigen immer noch eine neue Store-Build.

Denken Sie an die native Runtime als Rahmen um das Web code. Wenn das neue Bundle eine native API erwartet, die die installierte App nicht hat, Capgo sollte es nicht anwenden. Erstellen und hochladen Sie eine kompatible native Version, bevor Sie das Bundle testen.

Überprüfen Sie die Version und Plattform der installierten App. Testen Sie ein Android-Bundle auf Android zuerst. Testen Sie ein iOS-Bundle auf iOS. Bestätigen Sie auch, dass das Bundle die richtige App-Version ansteuert, wenn Ihr Kanal Versionssperren verwendet.

Nachdem Sie sich geändert habendefaultChannelführen Sie den Sync-Befehl vom Projektroot aus:

npx cap sync

Dieser Schritt kopiert die aktualisierte Konfiguration in die native Projekte. Bearbeiten Siecapacitor.configohne Synchronisierung lässt die native App ihre alten Kanal-Einstellungen. Ein frischer Build aus dieser veralteten native Projekt wird immer wieder denselben Ergebnis reproduzieren.

Für einen sauberen Test erstellen Sie eine neue App nach dem Synchronisieren. Verlassen Sie sich nicht auf einen alten Binary, das auf Ihrem Telefon installiert ist. Entfernen Sie es, wenn Sie die gespeicherten lokalen Kanal-Zustände löschen möchten, installieren Sie dann die neue Build und überprüfen Sie den Kanal erneut.

Die Capgo Aktualisierungsverhaltensdokumentation erklärt, wann der Updater nach einem Bundle sucht. Nutzen Sie diese Zeitung, wenn Sie testen. Starten Sie die App oder bewegen Sie sie wieder in den Vordergrund, dann lassen Sie den Check zu Ende gehen, bevor Sie entscheiden, dass die Aktualisierung fehlgeschlagen ist.

Überprüfen Sie auch die native Versionssperre des Bundles. Ein Bundle kann in der richtigen Kanal existieren und trotzdem nicht verfügbar sein, weil seine Mindestapp-Version nicht mit dem Gerät übereinstimmt. Lesen Sie die Release-Details im Dashboard anstatt anzunehmen, dass die neueste Upload auf jeden Installationsfall zutrifft.

Wenn die App diese Prüfungen besteht, haben Sie den Fehler bereits eingedämmt. Die nächste Frage ist, ob die Veröffentlichung überhaupt in den vorgesehenen Kanal gelangt ist.

Schritt 3: Bestätigen Sie, dass die Bereitstellung tatsächlich den Standardkanal erreicht hat

Ziel ist es, zu bestätigen, dass das Bundle im Kanal existiert, den das Gerät auflöst. Das Hochladen eines Bundles in einen Kanal macht es nicht automatisch in jedem Kanal verfügbar.

Öffnen Sie den Kanal in Capgo Cloud. Überprüfen Sie die aktive Bundle, seine Version und seinen Bereitstellungszustand. Vergleichen Sie den Kanalnamen mit dem Wert, der von der App zurückgegeben wird. Achten Sie auf kleine Unterschiede wieproductiongegenüberprodKanalnamen müssen genau übereinstimmen.

Wenn Sie über CI/CD bereitstellen, überprüfen Sie die Ausgabe der Befehlsausgabe aus demselben Job, der das Bundle hochgeladen hat. Bestätigen Sie die App-ID und den Kanal, der der CLI übergeben wurde. Ein Pipeline kann mit einem erfolgreichen Upload abschließen, während sie versehentlich einen Staging-Kanal ansteuert.

Überprüfen Sie den Status des Bundles. Ein Entwurf oder inaktives Release kann im Dashboard sichtbar sein, aber für Geräte nicht verfügbar sein. Wenn der Kanal eine rollende Veröffentlichung hat, erfüllt das betroffene Gerät möglicherweise nicht die Rollout-Regel.

Verwenden Sie ein bekanntes Testgerät. Geben Sie ihm eine klare Rolle. Zum Beispiel pinnen Sie ein Gerät an einen Testkanal und lassen Sie ein anderes Gerät auf den Cloud-Standard. Hochladen Sie eine harmlose Änderung und vergleichen Sie dann ihre Einträge im Check-in-Protokoll. Dies entfernt das Rätselraten aus der Testung.

Capgo’s lebendige OTA-Motor ist für Änderungen auf der Web-Schicht konzipiert. Er kann eine JavaScript-Bundle, CSS- oder Asset-Update ohne Wartezeit auf eine neue Store-Überprüfung durchführen. Diese Geschwindigkeit hängt von der Aktivität der Veröffentlichung in dem genauen Kanal ab, den das Gerät überprüft.

Wenn Sie vor Kurzem den Cloud-Standard geändert haben, beachten Sie die Gerätezeit. Neue Installationen verwenden den neuen Routenpfad sofort. Bestehende Geräte wechseln normalerweise, wenn sie ihre nächste Update-Überprüfung durchführen. Das Schließen und Wiedereröffnen der App kann dabei helfen, diesen Check auszulösen, kann aber einen festgelegten Kanal nicht überschreiben.

Nun überprüfen Sie das Ergebnis innerhalb der App. Rufen Sie __CAPGO_KEEP_0__ nach dem Start des Updaters auf. Loggen Sie die zurückgegebene Kanal-Seite neben der App-Version und der Bundle-Version. Dies ist nützlicher als die Überprüfung nur auf der Dashboard, da es zeigt, was das Gerät glaubt.getChannel()Erwarten Sie eine Verzögerung, wenn die App nur bei der Start- oder Vordergrund-Überprüfung überprüft. Testen Sie nicht, indem Sie eine Seite öffnen, die den Updater nie startet. Fügen Sie den Check in einen bekannten Startpfad für einen kurzen Testbuild ein und entfernen Sie das zusätzliche Logging vor der Veröffentlichung.

Wenn die zurückgegebene Kanal-Seite richtig ist, aber kein Bundle ankommt, gehen Sie zu Kompatibilität und Rollout-Regeln über. Wenn die zurückgegebene Kanal-Seite falsch ist, kehren Sie zu Schritt 1 zurück und löschen Sie die Zuweisung, die den Cloud-Standard übernimmt.

Schritt 4: Zwingen Sie einen frischen Synchronisation durch und inspizieren Sie die Geräte-Seitigen Protokolle

Das Ziel ist es, einen veralteten lokalen Zustand von einem serverseitigen Lieferungsproblem zu trennen. Ein frischer Check-in gibt Ihnen neue Beweise.

Schritt 4: Zwingen Sie einen frischen Synchronisation durch und inspizieren Sie die Geräte-Seitigen Protokolle

Stellen Sie zunächst sicher, dass das Gerät Zugriff auf das Netzwerk hat. Ein erfolgreicher App-Sitzung beweist nicht, dass der Updater seinen Endpunkt erreichen kann. Unternehmensfilter, VPN-Regeln, Captive-Portale oder ein abgelaufenes Sitzung können den Update-Antrag blockieren.

Bringen Sie die App in den Vordergrund. Warten Sie, bis der Updater-Check abgeschlossen ist. Wenn Ihre App ein Update-Status-Ereignis ausgibt, loggen Sie dieses Ereignis mit dem aktuellen Kanal. Vermeiden Sie es, nur “Update gestartet” zu loggen. Sie müssen wissen, ob die App eine Bundle gefunden, heruntergeladen, überprüft, installiert oder abgelehnt hat.

Verwenden Sie Capgo’s Geräteprotokolle, um die erste fehlgeschlagene Phase zu finden. Das erste Fehler ist meist nützlicher als das finale “Update fehlgeschlagen”-Message. Zum Beispiel weist ein fehlender Kanal auf Routing hin. Eine Kompatibilitätsablehnung weist auf das native Laufzeitumfeld oder die Versionskontrolle hin. Ein Downloadfehler weist auf Netzwerkzugriff oder den Bundle-Antrag hin.

Ein erneutes Installieren ist ein nützliches Test, aber es ändert die Beweise. Durch ein erneutes Installieren kann der lokale Kanalzustand gelöscht werden. Verwende es nachdem du den aktuellen Kanal und die Protokolle aufgenommen hast, nicht vorher.

Für eine wiederholbare Überprüfung, fange diese Werte in einer Protokollzeile auf:

• App-Id und native App-Version
• Abgeleiteter Kanal vongetChannel()
• Letzter Überprüfungszeitpunkt
• Bundle-Version, die vom Server gefunden wurde
• Installations- oder Ablehnungsresultat

Dieser kleine Eintrag hilft, wenn das Gerät einem Tester gehört, der das Problem nicht auf Anfrage reproduzieren kann. Es gibt auch Ihrem CI-Team einen klaren Signal für automatisierte Rauchtests.

Verwenden Sie den offiziellen Capgo Capacitor Updater-Quellrepository, wenn Sie das Plugin API-Verhalten untersuchen müssen. Insbesondere achten Sie auf die Differenz zwischen einer lokalen Kanaländerung und einer Dashboard-Gerätezuweisung.

Tipp: Erteilen Sie dem aufgelösten Kanal vor dem Löschen eine Aufzeichnung. Ansonsten verlieren Sie die Klarstellung, die das Versagen erklärt hat.

Schritt 5: Überprüfung von Rollout-Regeln, Versionsgittern und automatischen Zurückrollen

Das Ziel ist es, zu überprüfen, ob Capgo absichtlich die Bundle-Auslieferung zurückgehalten oder umgekehrt hat. Ein fehlendes Update ist manchmal eine Sicherheitsregel, die wie geplant funktioniert.

Öffnen Sie die Kanal-Einstellungen und überprüfen Sie jede Regel, die der Veröffentlichung zugewiesen ist. Suchen Sie nach Mindestanforderungen an die App-Version, Prozentsatz-Einstellungen für die Auslieferung, Gerätefiltern und Bedingungen, die der Veröffentlichung zugeordnet sind. Ein Gerät außerhalb der Regel bleibt auf seiner aktuellen Bundle, selbst wenn der Kanal korrekt ist.

Überprüfen Sie die Versionsformatierung ebenfalls. Capgo verwendet semantische Versionsverwaltung, um Releases zu vergleichen. Eine Versionsprüfung, die für einen Menschen richtig aussieht, kann sich anders verhalten, wenn die App oder das Bundle ein unerwartetes Format verwendet. Halten Sie das Format konsistent zwischen native Builds und OTA-Releases.

Überprüfen Sie dann das Rollbackverhalten. Ein automatisches Rollback kann ein Gerät auf ein vorheriges Bundle zurücksetzen, nachdem eine gescheiterte Gesundheitsprüfung erfolgt ist. Das Dashboard kann das ältere aktive code anzeigen, während die erwartete Veröffentlichung anwesend, aber nicht verfügbar ist.

Löschen Sie ein verdächtiges Bundle nicht, bevor Sie seine Ereignisse überprüft haben. Die Löschung entfernt wertvolle Beweise. Zuerst dokumentieren Sie die Bundle-Version, den Kanal, den Ausrollungsstatus und die Rollback-Gründe. Dann entscheiden Sie, ob Sie die Veröffentlichung aussetzen oder eine bekannte gute Version veröffentlichen.

Verwenden Sie einen gestuften Kanal für riskante Änderungen. Senden Sie das Bundle an einen kleinen Testgruppe zuerst. Überwachen Sie die Adoption und die Fehlermeldungen. Sobald die Veröffentlichung wie erwartet verhält, können Sie die Ausrollung vorantreiben. Dies verhindert, dass eine schlechte Web-Schicht-Änderung auf einmal alle aktiven Geräte erreicht.

Rollback repariert nur code, die OTA ändern kann. Wenn der Fehler von einem fehlenden native Plugin oder einem inkompatiblen native API kommt, benötigen Sie einen neuen Store-Build. Die Übertragung eines älteren JavaScript-Bundles fügt das fehlende native Stück nicht hinzu.

Wenn Sie eine Regel untersuchen, stellen Sie drei Fragen:

• Erfüllt diese Geräte die Anwendungsversion?
• Findet sich das Gerät in der Ausrollungsgruppe?
• Hat eine Gesundheitsprüfung oder eine manuelle Aktion es auf ein älteres Bundle zurückgesetzt?

Capgo ist hier nützlich, weil das gleiche Kanalmodell eine veröffentlichte Version, eine Rückschaltfunktion und eine Aktualisierungsaktivität in einem Workflow transportieren kann. Halten Sie die Regelmenge klein. Ein kurzer Richtlinienzusammenhang ist einfacher zu überprüfen als eine Stapel von Ausnahmen, die während eines Vorfalls erstellt wurden.

Wenn Sie API-basierte Prüfungen benötigen, enthält die Capgo-öffentliche API-Dokumentation beschreibt Ressourcen für Geräte, Kanäle und Pakete. Verwenden Sie es, um den Serverblick mit dem Bericht des Apps zu vergleichen. Diese Vergleich kann einen veralteten Filter in der Dashboard-Ansicht oder eine von der Automatisierung erstellte Gerätezuweisung offenlegen.

Eine Rückschaltung ist ein Sicherheitszaun und kein Ersatz für Tests. Halten Sie in jedem Produktionskanal eine bekannte gute Paketversion bereit.

Schritt 6: Verwenden Sie Echtzeit-Analysen, um den genauen Ausfallpunkt zu finden

Das Ziel besteht darin, "nicht aktualisiert" nicht als einen Ausfall zu behandeln. Analysen können zeigen, ob das Gerät nie eingeholt hat, keine geeignete Paketversion gefunden hat, während des Downloads gescheitert ist oder später zurückgerollt wurde.

Beginnen Sie mit der betroffenen Gerätegruppe. Filtern Sie nach App-Version, Plattform, Kanal und Paketversion. Suchen Sie nach einem Muster. Wenn nur eine alte App-Build scheitert, könnte das Problem ein natürlicher Kompatibilitätszaun sein. Wenn alle Geräte in einem Kanal scheitern, untersuchen Sie den Kanal oder die Bereitstellung.

Vergleichen Sie die Akzeptanz über die Zeit. Ein flaches Line nach der Veröffentlichung deutet auf Routing- oder Zulassungsprobleme hin. Eine Steigerung gefolgt von einem Rückgang deutet auf Installationsfehler oder Rückschaltungen hin. Eine langsame Steigerung deutet einfach darauf hin, dass die Geräte das App noch nicht geöffnet haben.

Verwenden Sie Timestamps mit Vorsicht. Die Zeitangabe im Dashboard kann sich von der lokalen Uhrzeit des Benutzers unterscheiden. Passen Sie das Updateereignis mit dem letzten Check-in des Geräts ab. Dies hilft, wenn ein Tester sagt, das Update sei fehlgeschlagen, bevor die App tatsächlich überprüft hatte.

Analytics hilft Ihnen auch dabei, einen Kanalwechsel sicher zu testen. Ändern Sie eine Variable nach der anderen. Halten Sie die Bundle-Konstanten während Sie die Routen testen. Dann halten Sie die Routen-Konstanten während Sie einen neuen Bundle testen. Wenn Sie beide ändern, kann die Daten nicht sagen, welche Änderung das Problem gelöst hat.

Falls ein Vorfall auftritt, speichern Sie ein kleines Beweis-Satz:

• Geräte-Identifikator oder interne Test-Bezeichnung
• Abgeschlossener Kanal
• Native-App-Version
• Erwartete Bundle und installierte Bundle
• Letzte Check-in-Zeit
• Rollback- oder Ablehnungsereignis

Capgo’s Echtzeit-Ansicht ist am nützlichsten, wenn Ihr Release-Prozess Updates über CI/CD sendet. Ein Deploy-Job kann ein Bundle hochladen, während ein Überwachungsschritt überprüft, ob Testgeräte den beabsichtigten Kanal und Bundle melden. Das verwandelt einen manuellen Hinweis in einen Release-Gate.

Halten Sie die Analytics-Daten an die Release-Records gebunden. Schreiben Sie den Commit- oder Build-Bezug in Ihre Deploy-Notizen. Wenn zwei Bundles ähnliche Versionsschlagwörter haben, sagt der Build-Bezug Ihnen, welcher code tatsächlich umgesetzt wurde.

Falls nur bestehende Geräte nach einem Cloud-Default-Wechsel fehlschlagen, warten Sie auf ihren nächsten Check-in, bevor Sie weitere Einstellungen ändern. Ein neuer Install ist ein nützlicher Kontrolle. Er sagt Ihnen, ob der Default-Route für Geräte, die keine alte lokale Zustände haben, funktioniert.

Schritt 7: Verhindere, dass die Standardkanal veraltet wird

Das Ziel besteht darin, das Kanalverschieben sichtbar zu machen, bevor es die Benutzer beeinflusst. Ein kleiner Release-Checkliste kann die meisten Wiederholungsfälle verhindern.

Wählen Sie ein Routingmodell für jede Anwendungslandschaft. Für die Produktion können Sie möglicherweise überspringen und lassen Sie Cloud die Standardkanal steuern. Für einen Testbuild können Sie einen expliziten Kanal festlegen. Die gefährliche Konfiguration ist eine Mischung aus alten lokalen Überprüfungen, veralteten native Konfigurationen und einem neuen Cloud-Standard, den niemand überprüft.defaultChanneland let Capgo Cloud control the default. For a test build, you may set an explicit channel. The dangerous setup is a mix of old local overrides, stale native config, and a new Cloud Default that nobody verifies.

im Buildpfad nach Konfigurationsänderungen. Stellen Sie sicher, dass das Build-Prozess fehlschlägt, wenn der Synchronisierungs-Schritt fehlschlägt. Die Kommandozeilenanweisung ist einfach, aber das Ignorieren dieses Schritts kann die Kanalversion von gestern in die native Binärdatei von heute einbauen.npx cap syncFügen Sie einen Rauchtest nach der Bereitstellung hinzu. Das Testgerät sollte die App starten,

aufrufen, prüfen, ob die erwartete Bundle verfügbar ist und das Ergebnis protokollieren. Die Überprüfung ist oft der fehlende Schritt in OTA-Workflows. Eine Upload allein beweist sehr wenig.getChannel()Halten Sie den lokalen Kanal __CAPGO_KEEP_0__ hinter einem klaren Feature-Flag. Wenn ein Testhilfsprogramm

Keep local channel code behind a clear feature flag. If a test helper callssetChannel()Verwenden Sie einen Release-Checkliste wie folgt:

Bestätigen Sie die App-ID und die native Version.

1. Schritt 7: Verhindere, dass die Standardkanal veraltet wird
2. Ziehe das Zielkanal aus.
3. Hochladen Sie das Bundle in das Zielkanal.
4. Bestätigen Sie, dass das Bundle aktiv ist.
5. Laufen Sie den Gerätesmoke-Test aus.
6. Überprüfen Sie das zurückgegebene Kanal mitgetChannel().
7. Beobachten Sie die Adoption, bevor Sie die Rollout breiter machen.

Halten Sie die Rollback-Schutzfunktion für Produktionsversionen aktiv. Ein häufiges Versagensmuster besteht darin, ohne klaren Kanal oder Rollback-Plan zu deployen. Das lässt dem Team weniger sichere Möglichkeiten, einen schlechten Bundle zu stoppen.

Capgo verwendet eine Abonnement pro Organisation, mit einer 14-tägigen kostenlosen Testversion. Behandeln Sie die Testversion als Chance, Ihren Release-Flow auf echten App-Builds zu testen, nicht nur, um eine Dashboard zu inspizieren. Versuchen Sie einmal einen aufgeteilten Deployment, einmal einen Rollback-Test und einmal einen automatischen Kanal-Check.

Die Sicherheit gehört in das gleiche Checklist. Schützen Sie die CI/CD-Tokens. Limitieren Sie, wer den Cloud-Standard ändern kann. Halten Sie die Produktionsdeployment-Kredentials aus lokalen Skripten aus. Eine unautorisierte Kanaländerung kann wie ein veralteter Gerät aussehen, bis Sie die Audit-Trail überprüfen.

Für Teams, die oft liefern, halten Sie den Prozess langweilig. Ein Befehl zum Deployen. Ein bekanntes Testgerät. Eine klare Kanalregel. Verfolgen, annehmen, rückgängig machen.

Hauptsächliche Erkenntnis: Verhindern Sie veraltete Routen, indem Sie die Konfiguration synchronisieren, lokale versteckte Überschreibungen vermeiden, den aufgelösten Kanal testen und die Rollback-Ready-Option bereitstellen.

FAQ

Wie ist der Capgo Cloud-Standardkanal nicht auf bestehende Geräte aktualisiert?

Bestehende Geräte behalten möglicherweise ihren alten Kanal, bis ihr nächster Update-Check erfolgt. Ein lokaler Kanal, eine Dashboard-Übernahme oder eine gezwungene Zuweisung können auch Vorrang vor dem Cloud-Standard haben. Bestätigen Sie die vom Gerät aufgelöste Kanal mitgetChannel(), klären Sie jede stärkere Zuweisung und bringen Sie die App in den Vordergrund.

Ändert sich der Capgo Cloud-Standard, ändert sich das für alle installierten Apps?

Nein, eine Änderung des Cloud-Standards ändert nicht sofort die Kanal-Einstellung aller installierten Apps. Neue Geräte können den neuen Standard sofort verwenden. Bestehende Installationen müssen sich vorher anmelden, bevor sie umschalten können, und sie werden auch nicht umschalten, wenn eine stärkere Kanal-Regel oder eine lokale Übernahme gilt.

Was tut npx cap sync bei einer Änderung des Capgo Kanals?

npx cap synckopiert die aktualisierte Capacitor-Konfiguration in die native Projekte. Wenn Sie die Änderung überspringen, kann die nächste native Build möglicherweise noch den alten Kanal-Einstellung enthalten. Führen Sie den Befehl vom Projekt-Root aus, dann bauen und installieren Sie ein frisches Test-Programm.defaultChannelErstellt setChannel einen Geräte-Übernahme im __CAPGO_KEEP_0__?

Does setChannel create a device override in Capgo?

ändert die Kanal-Einstellung, die lokal vom App gespeichert wird. Sie erstellt keine Backend-Geräte-Übernahme, daher kann der __CAPGO_KEEP_0__-Dashboard die Geräte nicht als übernommen anzeigen. Klären Sie die lokale Zuweisung, wenn das Gerät wieder auf die Standard-Route zurückkehren soll, und überprüfen Sie das Ergebnis mitsetChannel()Ändert sich der Capgo Cloud-Standard, ändert sich das für alle installierten Apps?getChannel().

Kann Capgo native code über eine OTA-Bundle aktualisieren?

Nein, Capgo OTA-Updates gelten für die Web-Schicht code wie JavaScript, CSS und Assets. Eine native Erweiterung, Berechtigung oder native API-Änderung erfordert eine neue Store-Build. Wenn das Bundle native code erwartet, die die installierte App nicht besitzt, kann die Aktualisierung auch dann abgelehnt werden, wenn der Kanal korrekt ist.

Zusammenfassung

Beginnen Sie mit der aufgelösten Kanal, nicht mit der Standard-Einstellung des Dashboards. Überprüfen Sie die Zuweisungen, führen Sie npx cap sync, überprüfen Sie das Bundle gegen die native Runtime und überprüfen Sie die Geräteprotokolle, bevor Sie die Ausrollungsregeln ändern. Dann fügen Sie einen kleinen Post-Deploy-Test in Capgo hinzu, der getChannel()aufruft und die erwartete Bundle bestätigt.