Fix Capgo Default Channel Not Updating Devices

Modifier le Cloud par défaut dans Capgo routes les appareils neufs tout de suite. Les installations existantes peuvent rester sur leur ancien canal jusqu'à ce qu'elles se reconnectent, ce qui explique de nombreux cas où un canal par défaut cloud Capgo ne met pas à jour les appareils.

Vérifiez les éléments dans l'ordre. Confirmez d'abord l'affectation du dispositif, puis inspectez la construction de l'application, l'état de synchronisation, les règles de déploiement, les journaux et les paramètres de retrait.

Table des matières

• Étape 1 : Confirmez que l'appareil est affecté au canal par défaut.
• Étape 2 : Vérifiez l'application, le runtime natif et la compatibilité de mise à jour
• Étape 3 : Vérifiez que la mise en production a bien atteint le canal par défaut
• Étape 4 : Forcer une Synchronisation Fraîche et Examiner les Journal de l'Appareil
• Étape 5 : Examinez les règles de déploiement, les portes de version et le retrait automatique.
• Étape 6 : Utilisez les Analyses en temps réel pour identifier l'endroit exact de l'erreur
• Étape 7 : Empêchez le Canal par Défaut de devenir Obsolète
• FAQ
• Conclusion

Étape 1 : Confirmez que l'appareil est affecté au Canal par Défaut

Le but est de déterminer quelles règles décident actuellement le canal de l'appareil. Un Canal par Défaut ne s'applique que lorsque des affectations plus fortes n'ont pas déjà revendiqué l'appareil.

Ouvrez le tableau de bord Capgo et inspectez l'appareil affecté. Vérifiez son canal actuel, son ID d'application, sa version et sa dernière connexion. Comparez ces valeurs avec celles d'un appareil qui a reçu l'actualisation attendue. Cette comparaison montre souvent rapidement l'issue.

La sélection du canal suit un ordre. Un canal forcé a la priorité en premier. Un canal de tableau de bord ou API vient ensuite. Un canal local défini par l'application suit ensuite. Ensuite, Capgo vérifiedefaultChanneldans la configuration de l'application native. Le Cloud par défaut est le redoublement.

Cet ordre signifie que l'appareil peut ignorer un canal par défaut modifié sans erreur de tableau de bord. Par exemple, une mise en ligne de test peut toujours avoir un canal local d'une mise en ligne de test antérieure. L'application continue à utiliser cette valeur locale jusqu'à ce que vous la supprimiez.

Utilisez le guide de débogage de l'actualiseur Capgo lorsque le canal résolu est vide ou inattendu. Il couvre le cas où l'application n'a pas de défaut utilisable et l'appareil n'a pas de surcharge.

Vérifiez ensuite votre configuration Capacitor. Une mise en place typique peut inclure un canal comme celui-ci :

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

Ce champ est facultatif. Si vous le laissez vide, le dispositif peut hériter du Cloud par défaut. Cela peut fonctionner bien pour les builds de production car le routage du canal reste dans le Cloud Capgo. Si vous le spécifiez, assurez-vous que la valeur correspond au canal que vous utilisez réellement.

Recherchez maintenant les surcharges locales dans l'application code. Une appelle à setChannel()modifie la cache local. Il ne crée pas une surcharge de dispositif backend. Le tableau de bord peut donc montrer aucune surcharge même si l'application utilise toujours le canal local.

Supprimez cette valeur locale lorsque le dispositif doit revenir à la navigation normale. Utilisez la méthode du plugin qui supprime l'affectation du canal du dispositif, ou supprimez le code qui définit le canal et réinstallez l'application pour un test propre.

Conclusion clé : Un canal par défaut modifié ne peut pas remplacer une affectation plus forte d'appareil, d'application ou de canal local.

Étape 2 : Vérifiez l'application, le runtime natif et la compatibilité de mise à jour

Le but est de prouver que l'application installée peut accepter le bundle que vous avez téléchargé. Un canal correct ne peut toujours pas livrer une mise à jour à un runtime natif incompatible.

Commencez par l'ID de l'application. L'application installée sur le dispositif doit utiliser la même identité d'application que le projet où vous avez téléchargé le bundle. Un désaccord peut ressembler à un problème de canal car le dispositif vérifie l'application Capgo incorrecte.

Comparez ensuite la version native du runtime avec les règles de compatibilité du bundle. Les mises à jour Capgo en temps réel peuvent modifier le JavaScript, le CSS et les actifs web. Elles ne peuvent pas ajouter un plugin natif ou modifier le projet natif code après la mise en production de l'application. Les modifications natives nécessitent toujours une nouvelle build de magasin.

Imaginez le runtime natif comme le cadre autour du web code. Si le nouveau bundle attend un API natif que l'application installée ne possède pas, Capgo ne doit pas l'appliquer. Effectuez une nouvelle build et téléchargez une version native compatible avant de tester ce bundle.

Inspectez la version et la plateforme de l'application installée. Testez un bundle Android sur Android en premier. Testez un bundle iOS sur iOS. Confirmez également que le bundle cible la bonne version de l'application lorsque votre canal utilise des portes de version.

Après avoir modifiédefaultChannel, run the sync command from the project root:

npx cap sync

Cette étape copie la configuration mise à jour dans les projets natifs. L'éditioncapacitor.configsans synchronisation laisse l'application natif sur son ancien paramétrage de canal. Une nouvelle build à partir de ce projet natif périmé continuera à reproduire le même résultat.

Pour un test propre, effectuez une nouvelle build de l'application après avoir synchronisé. N'attendez pas d'une ancienne version installée sur votre téléphone. Supprimez-la lorsque vous souhaitez supprimer l'état de canal local stocké localement, puis installez la nouvelle build et vérifiez le canal à nouveau.

Le Capgo comportement de mise à jour documenté explique quand le correcteur vérifie un bundle. Utilisez ce timing lors de vos tests. Lancez l'application ou la remettez en avant-plan, puis autorisez la vérification à se terminer avant de conclure que la mise à jour a échoué.

Vérifiez également la version native de la mise en bundle. Une mise en bundle peut exister dans le bon canal, mais rester inutilisable en raison de la version minimale de l'application qui ne correspond pas au dispositif. Lisez les détails de la mise en production dans le tableau de bord au lieu de supposer que la dernière mise à jour s'applique à chaque installation.

Si l'application passe ces vérifications, vous avez réduit la zone d'erreur. La prochaine question est de savoir si la mise en production a atteint le canal prévu.

Étape 3 : Vérifiez que la mise en production a bien atteint le canal par défaut

Le but est de confirmer que la mise en bundle existe dans le canal auquel le dispositif se connecte. Le téléchargement d'une mise en bundle dans un canal ne la rend pas disponible dans tous les canaux.

Ouvrez le canal dans Capgo Cloud. Vérifiez la mise en bundle active, sa version et son état de déploiement. Comparez le nom du canal avec la valeur renvoyée par l'application. Faites attention aux petites différences telles queproductionversusprod. Les noms de canal doivent correspondre exactement.

Si vous déployez à l'aide de CI/CD, inspectez la sortie de la commande provenant du même job qui a téléchargé la mise en bundle. Confirmez l'ID de l'application et le canal transmis à CLI. Un pipeline peut se terminer avec un téléchargement réussi tout en ciblant par erreur un canal de test.

Vérifiez ensuite l'état de la mise en bundle. Une mise en bundle de brouillon ou inactive peut être visible dans le tableau de bord mais inutilisable pour les dispositifs. Si le canal a une mise en production en roue de secours, le dispositif affecté peut ne pas répondre à sa règle de roue de secours.

Utilisez un appareil de test connu. Attribuez-lui un rôle clair. Par exemple, fixez un appareil à un canal de test et laissez un autre appareil sur le Cloud par défaut. Téléchargez une mise à jour sans risque, puis comparez ensuite leurs enregistrements de vérification. Cela élimine les suppositions de test.

Le moteur d'OTA en direct de Capgo est conçu pour les modifications de la couche web. Il peut déplacer une mise à jour de bundle JavaScript, CSS ou d'actif sans attendre une nouvelle évaluation de la boutique. Cette vitesse dépend de la mise à jour active dans le canal exact auquel le dispositif se connecte.

Si vous avez changé le Cloud par défaut il y a quelques instants, rappelez-vous la synchronisation du dispositif. Les installations nouvelles utilisent la nouvelle route dès le début. Les appareils existants passent généralement à la mise à jour lorsqu'ils effectuent leur prochaine vérification. Fermer et rouvrir l'application peuvent aider à déclencher cette vérification, mais cela ne peut pas contourner un canal fixé.

Now verify the result inside the app. CallgetChannel()après le démarrage de l'actualiseur. Enregistrez le canal retourné à côté de la version de l'application et de la version du bundle. Cela est plus utile que de vérifier uniquement le tableau de bord car cela montre ce que le dispositif croit.

Attendez-vous à une pause si l'application ne vérifie que lors du lancement ou en mode avant-plan. N'effectuez pas le test en ouvrant une page qui ne déclenche jamais l'actualiseur. Placez la vérification dans un chemin de démarrage connu pour une mise à jour de test courte, puis supprimez les logs supplémentaires avant la mise en production.

Si le canal retourné est correct mais aucune mise à jour n'arrive, passez à la compatibilité et aux règles de déploiement. Si le canal retourné est incorrect, retournez à l'étape 1 et supprimez l'affectation qui l'emporte sur le Cloud par défaut.

Étape 4 : Forcer une Synchronisation Fraîche et Examiner les Journal de l'Appareil

Le but est de séparer un état local périmé d'un problème de livraison côté serveur. Une nouvelle vérification vous donne de nouvelles preuves.

Premièrement, assurez-vous que le dispositif a accès à Internet. Une session d'application réussie ne prouve pas que l'actualiseur peut atteindre son point de terminaison. Les filtres d'entreprise, les règles VPN, les portails captifs ou une session expirée peuvent bloquer la demande d'actualisation.

Ensuite, amenez l'application à l'avant-plan. Attendez que la vérification de l'actualiseur se termine. Si votre application expose un événement de statut d'actualisation, enregistrez cet événement avec le canal actuel. Évitez de ne logger que « l'actualisation a commencé ». Vous devez savoir si l'application a trouvé un bundle, l'a téléchargé, l'a vérifié, l'a installé ou l'a rejeté.

Utilisez les journaux du dispositif de Capgo pour trouver la première étape échouée. La première erreur est généralement plus utile que le message final « l'actualisation a échoué ». Par exemple, un canal manquant pointe vers la routage. Un rejet de compatibilité pointe vers le runtime natif ou la porte de version. Une erreur de téléchargement pointe vers l'accès à Internet ou la demande de bundle.

Une réinstallation est un test utile, mais elle modifie la preuve. La réinstallation peut effacer l'état du canal local. Utilisez-l’après avoir capturé le canal actuel et les journaux, et non avant.

Pour un contrôle répétitif, enregistrez ces valeurs dans une seule ligne de journal :

• ID d'application et version native de l'application
• Canal résolu à partir degetChannel()
• Dernière vérification de mise à jour
• Version de bundle trouvée par le serveur
• Résultat d'installation ou de refus

Cette petite enregistrement aide lorsque le dispositif appartient à un testeur qui ne peut pas reproduire le problème à la demande. Cela donne également à votre équipe CI un signal clair pour les tests de fumée automatisés.

Utilisez le référentiel de source de mise à jour officiel Capgo Capacitor lorsque vous avez besoin d'inspecter le comportement du plugin API. En particulier, faites attention à la différence entre une modification du canal local et une affectation du dispositif sur le tableau de bord.

Conseil Pro : Capturer le canal résolu avant de le supprimer. Sinon, vous pouvez fixer l'état et perdre la piste qui expliquait l'échec.

Étape 5 : Examinez les règles de déploiement, les portes de version et les retours automatiques

L'objectif est de vérifier si Capgo a volontairement retenu ou inversé le bundle. Une mise à jour manquante peut parfois s'agir d'une règle de sécurité fonctionnant comme prévu.

Ouvrez les paramètres du canal et passez en revue chaque règle attachée à la mise à jour. Cherchez les versions d'application minimales, les paramètres de déploiement en pourcentage, les filtres de dispositif et les conditions liées à la mise à jour. Un appareil en dehors de la règle restera sur son bundle actuel même si le canal est correct.

Vérifiez également la forme de la version. Capgo utilise la versionnement semantique pour comparer les mises à jour. Une porte de version qui semble bonne aux yeux d'un homme peut encore se comporter différemment si l'application ou le bundle utilise une forme inattendue. Gardez la forme cohérente entre les builds natifs et les mises à jour OTA.

Ensuite, passez en revue le comportement de retrait. Un retrait automatique peut faire revenir un appareil à un bundle précédent après une vérification de santé échouée. Le tableau de bord peut afficher l'ancienne code active tandis que la mise à jour que vous attendez reste présente mais indisponible.

Ne supprimez pas un bundle suspect avant d'avoir passé en revue ses événements. La suppression supprime des preuves utiles. Enregistrez d'abord la version du bundle, le canal, l'état de déploiement et la raison de retrait. Ensuite, décidez si vous devez suspendre la mise à jour ou publier une version connue.

Utilisez un canal étape pour les changements risqués. Envoyez le bundle à un petit groupe de test. Observez l'adoption et les signaux d'erreur. Une fois que la mise à jour se comporte comme prévu, avancez la déploiement. Cela empêche une mauvaise modification de la couche web de parvenir à chaque appareil actif en même temps.

Seul le rollback répare code que l'OTA peut modifier. Si l'échec provient d'un plugin natif manquant ou d'un plugin natif API incompatible, vous avez besoin d'une nouvelle build de magasin.

Quand vous inspectez une règle, posez trois questions :

• Ce dispositif répond-t-il à la condition de version de l'application ?
• Is the device inside the rollout group?
• Did a health check or manual action return it to an older bundle?

Capgo est utile ici car le même modèle de canal peut transporter une mise en production étalée, supporter un rollback et afficher l'activité de mise à jour dans un flux de travail unique. Gardez le jeu de règles petit. Une politique courte est plus facile à auditor que des exceptions construites pendant une urgence.

If you need API-based checks, the La documentation publique API de Capgo décrit les ressources pour les appareils, les canaux et les lots. Utilisez-la pour comparer la vue serveur avec ce que l'application signale. Cette comparaison peut révéler un filtre de tableau de bord obsolète ou une affectation d'appareil créée par l'automatisation.

Une annulation est un garde-fou, pas un substitut aux tests. Gardez une version connue et valide disponible dans chaque canal de production.

Étape 6 : Utilisez les Analyses en temps réel pour identifier l'endroit exact de l'erreur

Le but est d'arrêter de considérer « non mis à jour » comme un seul échec. Les analyses peuvent montrer si le dispositif n'a jamais vérifié l'entrée, n'a trouvé aucun bundle éligible, a échoué pendant le téléchargement ou a annulé plus tard.

Démarrez par le groupe de dispositifs affectés. Filtrez par version d'application, plateforme, canal et version de bundle. Cherchez un modèle. Si seulement une ancienne version de l'application échoue, le problème peut être une porte de compatibilité native. Si tous les dispositifs d'un canal échouent, inspectez le canal ou la mise en production.

Comparez l'adoption au fil du temps. Une ligne plate après la mise en production suggère des problèmes de routage ou d'éligibilité. Une augmentation suivie d'une baisse suggère des erreurs d'installation ou d'annulation. Une augmentation lente peut simplement signifier que les dispositifs n'ont pas encore ouvert l'application.

Utilisez les horodatages avec soin. L'heure de l'événement du tableau de bord peut différer de l'heure locale de l'utilisateur. Correspondrez l'événement de mise à jour avec la dernière vérification du dispositif. Cela aide lorsque le testeur dit que la mise à jour a échoué avant que l'application n'ait vraiment vérifié.

Les analyses vous aident également à tester un changement de canal de manière sûre. Modifiez une variable à la fois. Gardez le bundle constant pendant que vous testez le routage. Ensuite, gardez le routage constant pendant que vous testez un nouveau bundle. Si vous modifiez les deux, les données ne peuvent pas vous dire laquelle des deux modifications a résolu le problème.

Pour un incident, sauvegardez un petit ensemble d'évidences :

• L'identifiant du dispositif ou l'étiquette de test interne
• Le canal résolu
• La version native de l'application
• Le bundle attendu et le bundle installé
• L'heure de la dernière vérification
• L'événement d'annulation ou de refus

La vue en temps réel de Capgo est la plus utile lorsque votre processus de mise en production envoie des mises à jour à travers CI/CD. Une tâche de déploiement peut télécharger un bundle, tandis qu'une étape de surveillance vérifie que les appareils de test signalent le canal et le bundle prévus. Cela transforme une plainte manuelle en une porte de sortie de version.

Liiez les données d'analytique aux enregistrements de version. Écrivez la référence de commit ou de build dans vos notes de déploiement. Lorsque deux bundles ont des étiquettes de version similaires, la référence de build vous dit lequel code a effectivement mis à jour.

Si seuls les appareils existants échouent après une modification de la valeur par défaut de Cloud, attendez leur prochaine vérification avant de modifier d'autres paramètres. Une nouvelle installation est un bon contrôle. Elle vous dit si la route par défaut fonctionne pour les appareils qui n'ont pas d'état local ancien.

Étape 7 : Prévenir que le Canal par Défaut devienne obsolète

L'objectif est de rendre visible la dérive de canal avant qu'elle n'affecte les utilisateurs. Un petit checklist de version peut prévenir la plupart des cas de répétition.

Choisissez un modèle de routage pour chaque environnement d'application. Pour la production, vous pouvez omettredefaultChannelet laisser Capgo Cloud contrôler la valeur par défaut. Pour une build de test, vous pouvez définir un canal explicite. La configuration dangereuse est une combinaison d'overrides locaux anciens, d'une configuration native obsolète et d'une nouvelle valeur par défaut de Cloud qui n'est pas vérifiée.

Inséreznpx cap syncà la fin du chemin de build après les modifications de configuration. Faites échouer la build si l'étape de synchronisation échoue. La commande est simple, mais la sauter peut faire cuire hier le canal dans le binôme natif d'aujourd'hui.

Ajoutez un test de fumée après le déploiement. L'appareil de test doit lancer l'application, appelergetChannel()Vérifiez le bundle attendu et enregistrez le résultat. La vérification est souvent le pas manquant dans les workflows OTA. Un téléchargement seul prouve très peu.

Conservez le canal local code sous un drapeau de fonctionnalité clair. Si un assistant de test appellesetChannel(), make sure production builds cannot include it by accident. Remember that the local cache may not appear as a dashboard override, so the UI cannot catch every problem.

Use a release checklist like this:

1. Confirmez l'ID de l'application et la version native.
2. Envoyez le bundle vers ce canal.
3. Confirmez que le bundle est actif.
4. Exécutez le test de fumée du dispositif.
5. Vérifiez le canal retourné avec
6. Observez l'adoption avant d'étendre la mise à jour.getChannel().
7. Suivez l'adoption avant d'élargir le déploiement.

Conservez la protection de reversion activée pour les mises à jour de production. Un schéma de défaillance courant est de déployer sans un canal clair ou un plan de reversion. Cela laisse l'équipe avec moins de moyens sûrs pour arrêter un bundle mauvais.

Capgo utilise une souscription par organisation, avec une période d'essai de 14 jours. Considérez cette période d'essai comme une chance de tester votre flux de mise en production sur des builds d'applications réelles, et non juste pour inspecter un tableau de bord. Essayez une mise en production étalée, un test de retrait, et une vérification automatique du canal.

La sécurité doit figurer dans le même checklist. Protégez les jetons CI/CD. Limitez les personnes qui peuvent modifier le canal par défaut Cloud. Gardez les informations de déploiement de production hors des scripts locaux. Un changement non autorisé du canal peut ressembler à un appareil obsolète jusqu'à ce que vous ayez examiné la traçabilité des audits.

Pour les équipes qui aiment livrer souvent, gardez le processus ennuyeux. Une commande pour déployer. Un appareil de test connu. Une règle de canal claire. Suivez, adoptez, revenez en arrière.

Rappel clé : Empêchez les routages obsolètes en synchronisant la configuration, en évitant les modifications locales cachées, en testant le canal résolu et en gardant le retrait prêt.

FAQ

Pourquoi le canal par défaut Cloud de Capgo ne met-il pas à jour les appareils existants ?

Les appareils existants peuvent conserver leur ancien canal jusqu'à leur prochaine vérification de mise à jour. Un canal local, un surcroît de tableau de bord ou une affectation forcée peuvent également prioritiser le canal par défaut Cloud. Confirmez le canal résolu de l'appareil avecgetChannel()Réinitialisez tout affectation plus forte, puis amenez l'application à l'avant-plan.

Le changement du canal par défaut Cloud de Capgo change-t-il tous les applications installées ?

No, le changement de la valeur par défaut Cloud n'écrit pas instantanément tous les canaux installés des applications. Les nouveaux appareils peuvent utiliser la nouvelle valeur par défaut dès à présent. Les installations existantes doivent se connecter avant de pouvoir passer à la nouvelle valeur, et elles ne passeront pas à la nouvelle valeur si une règle de canal plus forte ou une mise en œuvre locale s'applique.

Qu'est-ce que npx cap sync fait lors d'un changement de canal Capgo ?

npx cap synccopie la configuration mise à jour Capacitor dans les projets natifs. Si vous changezdefaultChannelmais ignorez la synchronisation, la prochaine construction native peut toujours contenir la valeur par défaut de canal ancienne. Exécutez la commande depuis la racine du projet, puis construisez et installez une version de test fraîche.

La commande setChannel crée-t-elle un décalage d'appareil dans Capgo ?

Non,setChannel()change le canal stocké localement par l'application. Elle ne crée pas un décalage d'appareil côté serveur, donc le tableau de bord Capgo peut ne pas afficher l'appareil comme décalé. Effacez l'affectation locale lorsque l'appareil doit revenir à la configuration par défaut, puis vérifiez le résultat avecgetChannel().

Peut Capgo mettre à jour les code natifs par le biais d'un bundle OTA ?

Non, les mises à jour OTA Capgo s'appliquent aux couches web code telles que JavaScript, CSS et les ressources. Un plugin natif, une autorisation ou une modification de API native nécessite une nouvelle construction de magasin. Si le bundle s'attend à des code natifs que l'application installée manque, la mise à jour peut être rejetée même si le canal est correct.

Conclusion

Démarrez avec le canal résolu, pas la valeur par défaut du tableau de bord. Vérifiez les affectations, exécuteznpx cap sync, vérifiez le bundle contre le runtime natif, et inspectez les journaux de l'appareil avant de changer les règles de déploiement. Ensuite, ajoutez un petit test post-déploiement dans Capgo qui appellegetChannel()et confirme le bundle attendu.