Réparer le canal par défaut de Capgo qui ne met pas à jour les appareils

__CAPGO_KEEP_0__ Réparer le canal par défaut de Capgo qui ne met pas à jour les appareils routes immédiatement les appareils neufs. Les installations existantes peuvent rester sur leur ancien canal jusqu'à ce qu'elles se reconnectent, ce qui explique de nombreux cas où un Capgo canal par défaut cloud n'actualise pas les appareils.

Passer par les vérifications dans l'ordre. Confirmer l'affectation de l'appareil en premier, puis inspecter la construction de l'application, l'état de synchronisation, les règles de déploiement, les journaux et les paramètres de retrait.

Sommaire

• Étape 1 : Confirmer que l'appareil est affecté au canal par défaut.
• Étape 2 : Vérifier l'application, le runtime natif et la compatibilité de mise à jour.
• Étape 3 : Vérifier que la mise en production a bien atteint le canal par défaut.
• Étape 4 : Forcer une synchronisation fraîche et inspecter les journaux côté appareil.
• Étape 5 : Examiner les règles de déploiement, les portes de version et la reprise automatique.
• Étape 6 : Utiliser les analyses en temps réel pour trouver le point de failure exact.
• Étape 7 : Prévenir le canal par défaut de devenir obsolète.
• FAQ
• Conclusion

Étape 1 : Confirmer que le dispositif est affecté à la canal par défaut

Le but est de déterminer quelle règle décide actuellement le canal du dispositif. Un canal par défaut Cloud n'a d'effet que lorsque l'assignation la plus forte n'a pas déjà revendiqué le dispositif.

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

La sélection du canal suit un ordre. Un canal forcé a la priorité avant tout. Un canal de tableau de bord ou API vient ensuite. Un canal local défini par l'application suit ensuite. Ensuite, Capgo vérifie les paramètres de l'application native. Le canal par défaut Cloud est le recours.defaultChannelCet ordre signifie que le dispositif peut ignorer un canal par défaut Cloud modifié sans erreur de tableau de bord. Par exemple, une version de test peut toujours avoir un canal local d'une version de test antérieure. L'application utilise ce valeur locale jusqu'à ce que vous la supprimiez.

Utilisez le guide de débogage de l'__CAPGO_KEEP_0__ mise à jour lorsque le canal résolu est vide ou inattendu. Il couvre le cas où l'application n'a pas de canal par défaut utilisable et le dispositif n'a pas d'override.

Ensuite, vérifiez votre configuration __CAPGO_KEEP_0__. Une configuration typique peut inclure un canal comme suit : Le champ est facultatif. Si vous le laissez vide, le dispositif peut hériter du canal par défaut Cloud. Cela peut fonctionner bien pour les versions de production car la routage du canal reste dans le Cloud Capgo. Si vous le spécifiez, assurez-vous que la valeur correspond au canal que vous déployez réellement. Étape 2 : Vérifiez votre configuration __CAPGO_KEEP_0__

Étape 3 : Vérifiez votre configuration Capacitor

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

Étape 4 : Vérifiez votre configuration Capgo

Recherchez maintenant les paramètres locaux dans l'application code. Un appel àsetChannel()modifie la cache local. Il ne crée pas un paramètre de substitution de périphérique côté serveur. Le tableau de bord peut donc ne pas afficher de substitution même si l'application continue d'utiliser le canal local.

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

Rappel clé : Un Cloud par défaut modifié ne peut pas remplacer une affectation de canal plus forte du périphérique, de l'application ou local.

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

L'objectif 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 délivrer une mise à jour à un runtime natif incompatible.

Commencez par l'ID de l'application. L'application installée sur le périphérique 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 périphérique vérifie l'application Capgo incorrecte.

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

Imaginez le runtime natif comme le cadre autour du web code. Si le nouveau bundle attend un runtime natif API que l'application installée ne possède pas, Capgo ne doit pas l'appliquer. Construisez 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édefaultChannelExécutez la commande de synchronisation depuis la racine du projet :

npx cap sync

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

Pour un test propre, construisez une nouvelle 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é, puis installez la nouvelle construction et vérifiez le canal à nouveau.

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

Vérifiez également la porte de version native du bundle. Un bundle peut exister dans le bon canal mais rester indisponible car sa version minimale d'application 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 mise en ligne la plus récente s'applique à chaque installation.

Si l'application passe ces vérifications, vous avez réduit la zone d'incertitude. La question suivante est de savoir si la mise à jour a atteint le canal ciblé.

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

L'objectif est de confirmer que le bundle existe dans le canal résolu par le dispositif. Le chargement d'un bundle dans un canal ne le rend pas disponible dans tous les canaux.

Ouvrez le canal dans Cloud Capgo. Vérifiez le bundle actif, 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 queproductioncontreprodLes noms de canal doivent correspondre exactement.

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

Vérifiez ensuite l'état du bundle. Une mise à jour de rédaction ou inactive peut être visible dans le tableau de bord mais inutilisable par les appareils. Si le canal a une mise à jour en roue libre, le dispositif affecté peut ne pas répondre à sa règle de roue libre.

Utilisez un appareil de test connu. Donnez-lui un rôle clair. Par exemple, fixez un appareil à un canal de test et laissez un autre appareil sur le canal par défaut de Cloud. Chargez une modification sans risque, puis comparez leurs enregistrements de vérification. Cela élimine les suppositions de la mise au point.

Le moteur 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'actifs sans attendre une nouvelle évaluation de la boutique. Cette vitesse dépend de la mise en production active dans le canal exact que le dispositif vérifie.

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

Vérifiez maintenant le résultat à l'intérieur de l'application. AppelezgetChannel()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 une pause si l'application ne vérifie que lors du lancement ou en mode avant-plan. N'essayez pas de tester en ouvrant une page qui ne démarre jamais l'actualiseur. Placez la vérification dans un chemin de démarrage connu pour une version de test courte, puis supprimez les logs supplémentaires avant la mise en production.

Si le canal retourné est correct mais aucun bundle 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'attribution qui l'emporte sur les moments par défaut de Cloud.

Étape 4 : Forcer une synchronisation fraîche et inspecter les journaux du côté du dispositif

L'objectif est de séparer un état local périmé d'un problème de livraison côté serveur. Une vérification fraîche 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 corporatifs, les règles VPN, les portails captifs ou une session expirée peuvent bloquer la demande d'actualisation.

Ensuite, amenez l'application en avant-plan. Attendez que le contrôle d'actualisation 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 « mise à jour échouée ». Par exemple, une chaîne manquante pointe vers la mise en route. Un rejet de compatibilité pointe vers le runtime natif ou la passerelle 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étable, enregistrez ces valeurs dans une ligne de journal :

• ID de l'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 est utile lorsque l'appareil 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 de l'appareil 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 intentionnellement retenu ou inversé la mise à jour de la bundle. Une mise à jour manquante est parfois une règle de sécurité qui fonctionne comme conçu.

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

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

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

Ne supprimez pas un bundle suspect avant d'avoir examiné 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 en premier. Observez l'adoption et les signaux d'erreur. Une fois que la mise à jour se comporte comme prévu, avancez la mise à jour. Cela empêche une mauvaise modification de la couche web de parvenir à tous les appareils actifs en même temps.

Ne rétablissez que les code que les mises à jour OTA peuvent modifier. Si l'échec provient d'un plugin natif manquant ou d'une API natif incompatible, vous avez besoin d'une nouvelle build de magasin. Envoyer un bundle JavaScript plus ancien ne ajoutera pas la pièce native que l'application manque.

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

• Ce appareil répond-il à la condition de version de l'application ?
• L'appareil se trouve-t-il dans le groupe de déploiement ?
• Un contrôle de santé ou une action manuelle a-t-il fait revenir l'appareil à une version de bundle plus ancienne ?

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

Si vous avez besoin de vérifications basées sur API, le La documentation publique API de Capgo décrit les ressources pour les appareils, les canaux et les ensembles. Utilisez-la pour comparer la vue du serveur avec ce que l'application signale. Cette comparaison peut révéler un filtre de tableau de bord périmé ou une affectation d'appareil créée par l'automatisation.

Un retrait est un garde-fou, et non un substitut pour les tests. Gardez un ensemble de bundle connu disponible dans chaque canal de production.

Étape 6 : Utilisez les Analyses en temps réel pour trouver le point de failure exact

L'objectif est d'arrêter de traiter « non mis à jour » comme un seul échec. Les analyses peuvent montrer si l'appareil n'a jamais vérifié, n'a trouvé aucun ensemble éligible, a échoué pendant le téléchargement ou a retourné plus tard.

Commencez par le groupe d'appareils affectés. Filtrez par version de l'application, plateforme, canal et version de l'ensemble. 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 appareils 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 de retrait. Une augmentation lente peut simplement signifier que les appareils n'ont pas encore ouvert l'application.

Utilisez les horodatages avec soin. Le temps des événements du tableau de bord peut différer de l'heure locale de l'utilisateur. Correspondre l'événement de mise à jour avec la dernière vérification du périphérique. Cela aide lorsque le testeur dit que la mise à jour a échoué avant que l'application n'ait effectivement 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 la routage. Ensuite, gardez la routage constant pendant que vous testez un nouveau bundle. Si vous modifiez les deux, les données ne peuvent pas vous dire laquelle des modifications a résolu le problème.

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

• L'identifiant du périphérique ou l'étiquette de test interne
• Le canal résolu
• La version de l'application native
• Le bundle attendu et le bundle installé
• L'heure de la dernière vérification
• L'événement de rejet ou de reversion

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. Un job de déploiement peut télécharger un bundle, tandis qu'une étape de surveillance vérifie que les périphériques de test signalent le canal et le bundle attendus. Cela transforme une plainte manuelle en porte de mise en production.

Conservez les données d'analyse liées aux enregistrements de mise en production. É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 laquelle de code a effectivement déplacé.

Si seuls les périphériques existants échouent après un changement de canal par défaut, attendez leur prochaine vérification avant de modifier d'autres paramètres. Un nouvel install est un bon contrôle. Il vous dit si la route par défaut fonctionne pour les périphériques qui n'ont pas d'état local ancien.

Étape 7 : Empêchez le canal par défaut de devenir obsolète

Le but est de rendre visible le dérive de canal avant qu'il n'affecte les utilisateurs. Un petit checklist de mise à jour 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 le canal 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'un nouveau canal par défaut que personne ne vérifie.

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

Ajoutez un test de fumée après le déploiement. Le dispositif de test doit lancer l'application, appelergetChannel(), vérifier le bundle attendu et enregistrer 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 derrière un drapeau de fonctionnalité clair. Si un assistant de test appellesetChannel(), assurez-vous que les builds de production ne peuvent pas l'inclure par accident. Rappelez-vous que la cache local ne peut pas apparaître comme un surcouche de tableau de bord, donc l'interface utilisateur ne peut pas capturer tous les problèmes.

Utilisez un checklist de mise à jour comme celui-ci :

1. Confirmez l'ID d'application et la version native.
2. Choisissez le canal cible.
3. Envoyez le bundle vers ce canal.
4. Confirmez que le bundle est actif.
5. Lancez le test de fumée du dispositif.
6. Vérifiez le canal retourné avecgetChannel().
7. Regardez l'adoption avant d'étendre la mise à jour.

Conservez la protection de rollback pour les versions de production. Un schéma de défaillance courant est de déployer sans un canal clair ou un plan de rollback. 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 gratuite de 14 jours. Traitez l'essai comme une chance de tester votre flux de mise à jour sur des builds d'applications réelles, et non juste pour inspecter un tableau de bord. Essayez une mise à jour étapée, un test de rollback 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 Cloud Default. 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 consultiez la traçabilité des audits.

Pour les équipes qui déposent 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.

Prise de conscience clé : Empêchez les itinéraires obsolètes en synchronisant la configuration, en évitant les modifications locales cachées, en testant le canal résolu et en gardant le rollback prêt.

FAQ

Why is the Capgo cloud default channel not updating existing devices?

Les appareils existants peuvent conserver leur ancien canal jusqu'à leur prochaine vérification d'actualisation. Une canal local, un surclassement du 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 avec getChannel()Supprimez tout surclassement plus fort, puis amenez l'application à l'avant-plan.

Does changing the Capgo Cloud Default change every installed app?

Non, la modification du canal par défaut ne réécrit pas instantanément le canal de chaque application installée. Les nouveaux appareils peuvent utiliser le nouveau canal par défaut dès à présent. Les installations existantes doivent vérifier avant de pouvoir passer à l'acte, et elles ne passeront pas à l'acte si une règle de canal plus forte ou un surclassement local s'applique.

Qu'est-ce que npx cap sync fait lors d'une modification du canal Capgo ?

npx cap synccopie la configuration mise à jour Capacitor dans les projets natifs. Si vous modifiez defaultChannelmais que vous passez sous silence la synchronisation, la prochaine construction native peut toujours contenir la configuration de canal ancienne. Exécutez la commande depuis la racine du projet, puis construisez et installez une version de test fraîche.

Crée-t-il setChannel un surclassement d'appareil dans Capgo ?

Non,setChannel()changes the channel stored locally by the app. It does not create a backend Device Override, so the Capgo dashboard may not show the device as overridden. Clear the local assignment when the device should return to default routing, then verify the result withgetChannel().

Can Capgo update native code through an OTA bundle?

Non, les mises à jour OTA de Capgo s'appliquent aux couches web code telles que JavaScript, CSS et les actifs. Un plugin natif, une permission ou un changement de API natif nécessite une nouvelle mise en 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

Commencez par le canal résolu, pas le canal 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 du périphérique avant de modifier les règles de déploiement. Ensuite, ajoutez un petit test post-déploiement dans Capgo qui appellegetChannel()et confirme le bundle attendu.