Canal par défaut Capgo : appareils non mis à jour

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

Faites les vérifications dans l'ordre. Confirmez d'abord l'attribution de l'appareil, puis examinez le build de l'app, l'état de synchronisation, les règles de déploiement progressif, les logs et les paramètres de rollback.

Table des matières

• Étape 1 : Confirmez que l'appareil est assigné au canal par défaut
• Étape 2 : Vérifiez la compatibilité app, runtime natif et mise à jour
• Étape 3 : Vérifiez que le déploiement a bien atteint le canal par défaut
• Étape 4 : Forcer une synchronisation complète et inspecter les logs côté appareil
• Étape 5 : Réviser les règles de déploiement, les seuils de version et le rollback automatique
• Étape 6 : Utilisez l'analyse en temps réel pour identifier le point de défaillance exact
• Étape 7 : empêcher le canal par défaut de devenir obsolète
• FAQ
• Conclusion

Étape 1 : Confirmez que l'appareil est assigné au canal par défaut

L'objectif est de déterminer quelle règle définit actuellement le canal de l'appareil. Un Cloud Default ne s'applique que si aucune affectation plus prioritaire n'a déjà été appliquée à l'appareil.

Ouvrez le dashboard Capgo et examinez l'appareil concerné. Vérifiez son canal actuel, son app ID, sa version et l'heure du dernier check-in. Comparez ces valeurs à celles d'un appareil ayant reçu la mise à jour attendue. Cette comparaison permet souvent d'identifier rapidement le problème.

La sélection du canal suit un ordre de priorité. Un canal forcé est prioritaire. Vient ensuite un override d'appareil défini dans le dashboard ou via API. Puis vient un canal local défini par l'app. Enfin, les vérifications CapgodefaultChanneldans la config de l'app native. Le Cloud Default sert de fallback.

Cela signifie qu'un appareil peut ignorer un Cloud Default modifié sans erreur dans le dashboard. Par exemple, un build de test peut encore avoir un canal local issu d'un test précédent. L'app continue d'utiliser cette valeur locale jusqu'à ce que vous la supprimiez.

Utilisez le Guide de débogage de l'updater Capgo lorsque le canal résolu est vide ou inattendu. Cela couvre le cas où l'app n'a pas de valeur par défaut utilisable et où l'appareil n'a pas d'override.

Ensuite, vérifiez votre configuration Capacitor. Une configuration typique peut inclure un canal comme celui-ci :

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

Ce champ est facultatif. Si vous ne le renseignez pas, l'appareil peut hériter du Cloud Default. Cela peut très bien fonctionner pour les builds de production car le routage des canaux reste dans le Cloud Capgo. Si vous l'incluez, assurez-vous que la valeur correspond au canal sur lequel vous déployez réellement.

Recherchez maintenant les overrides locaux dans le code de l'application. Un appel àsetChannel()modifie le cache local. Cela ne crée pas de Device Override côté backend. Le dashboard peut donc n'afficher aucun override alors que l'app continue d'utiliser le canal local.

Supprimez cette valeur locale lorsque l'appareil doit revenir au routage normal. Utilisez la méthode du plugin qui supprime l'assignation de canal de l'appareil, ou supprimez le code qui définit le canal et réinstallez l'app pour un test propre.

À retenir : Un changement du canal Cloud par défaut ne peut pas remplacer une affectation plus spécifique sur l'appareil, l'app ou le canal local.

Étape 2 : Vérifiez la compatibilité app, runtime natif et mise à jour

L’objectif est de prouver que l’application installée peut accepter le bundle que vous avez envoyé. 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 l’appareil doit utiliser la même identité d’application que le projet où vous avez envoyé le bundle. Un écart peut ressembler à un problème de canal, car l’appareil vérifie la mauvaise application Capgo.

Ensuite, comparez la version du runtime natif avec les règles de compatibilité du bundle. Les live updates Capgo peuvent modifier le JavaScript, le CSS et les ressources web. Elles ne peuvent pas ajouter un plugin natif ni modifier le code du projet natif après la publication de l’application. Les modifications natives nécessitent toujours un nouveau build store.

Voyez le runtime natif comme le cadre autour du web code. Si le nouveau bundle attend un API natif absent de l'application installée, Capgo ne doit pas l'appliquer. Compilez et envoyez une version native compatible avant de tester ce bundle.

Inspectez la version et la plateforme de l'application installée. Testez d'abord un bundle Android sur Android. Testez un bundle iOS sur iOS. Vérifiez aussi que le bundle cible la bonne version de l'application lorsque votre canal utilise des restrictions 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. Modifiercapacitor.configsans synchroniser laisse l'application native sur son ancien réglage de canal. Un nouveau build depuis ce projet natif obsolète continuera de reproduire le même résultat.

Pour un test propre, compilez une nouvelle application après la synchronisation. Ne vous fiez pas à un ancien binaire installé sur votre téléphone. Désinstallez-la lorsque vous devez supprimer l'état de canal local en cache, puis installez le nouveau build et vérifiez à nouveau le canal.

Le Capgo update behavior documentation explique quand l'updater vérifie la présence d'un bundle. Tenez compte de ce timing lors de vos tests. Lancez l'application ou ramenez-l’au premier plan, puis laissez la vérification se terminer avant de conclure à un échec de la mise à jour.

Vérifiez aussi la restriction 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 à l'appareil. Lisez les détails de la release dans le dashboard au lieu de supposer que le dernier upload s'applique à toutes les installations.

Si l’application passe ces vérifications, vous avez circonscrit le problème. La question suivante est de savoir si la release a bien atteint le canal prévu.

Étape 3 : Vérifiez que le déploiement a bien atteint le canal par défaut

L’objectif est de confirmer que le bundle existe dans le canal que l’appareil résout. Envoyer un bundle dans un canal ne le rend pas disponible dans tous les canaux.

Ouvrez le canal dans Capgo Cloud. 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’app. Attention aux petites différences telles queproductionvsprod. Channel names must match exactly.

Si vous déployez via CI/CD, inspectez la sortie de la commande du job qui a effectué l'upload du bundle. Confirmez l'ID de l'app et le canal transmis à CLI. Un pipeline peut se terminer par un upload réussi tout en ciblant par erreur un canal de staging.

Vérifiez ensuite le statut du bundle. Une release en brouillon ou inactive peut être visible dans le dashboard mais indisponible pour les appareils. Si le canal a un déploiement progressif, l'appareil concerné ne respecte peut-être pas la règle de ce déploiement.

Utilisez un appareil de test connu. Attribuez-lui un rôle précis. Par exemple, épinglez un appareil à un canal de test et laissez un autre sur le Cloud Default. Envoyez un changement sans risque, puis comparez leurs enregistrements de check-in. Cela élimine toute incertitude lors du test.

Le moteur de live update OTA de Capgo est conçu pour les changements de la couche web. Il peut déployer un bundle JS, du CSS ou une mise à jour d'asset sans attendre une nouvelle revue des stores. Cette rapidité dépend de l'activation de la release dans le canal exact consulté par l'appareil.

Si vous avez modifié le Cloud Default il y a quelques instants, gardez à l'esprit le timing de l'appareil. Les nouvelles installations utilisent la nouvelle route immédiatement. Les appareils existants basculent généralement lors de leur prochaine vérification de mise à jour. Fermer et rouvrir l'app peut aider à déclencher cette vérification, mais cela ne peut pas outrepasser un canal épinglé.

Vérifiez maintenant le résultat dans l'app. AppelezgetChannel()une fois l'updater démarré. Loggez le canal retourné à côté de la version de l'app et de la version du bundle. C'est plus utile que de vérifier uniquement le dashboard, car cela montre ce que l'appareil croit.

Attendez un délai si l’app ne vérifie qu’au lancement ou au premier plan. Ne testez pas en ouvrant un écran qui ne démarre jamais le module de mise à jour. Placez la vérification dans un chemin de démarrage connu pour un build de test court, puis supprimez les logs supplémentaires avant la release.

Si le canal retourné est correct mais qu’aucun bundle n’arrive, passez aux règles de compatibilité et de déploiement progressif. Si le canal retourné est incorrect, revenez à l’étape 1 et supprimez l’attribution qui prime sur le Cloud Default.

Étape 4 : Forcer une synchronisation complète et inspecter les logs côté appareil

L’objectif est de distinguer un état local obsolète d’un problème de livraison côté serveur. Une nouvelle vérification vous fournit de nouvelles preuves.

Tout d'abord, assurez-vous que l'appareil a accès au réseau. Une session applicative réussie ne prouve pas que l'updater peut atteindre son endpoint. Les filtres d'entreprise, les règles VPN, les portails captifs ou une session expirée peuvent bloquer la requête de mise à jour.

Ensuite, ramenez l'application au premier plan. Attendez que la vérification de l'updater se termine. Si votre application expose un événement de statut de mise à jour, loguez cet événement avec le canal actuel. Évitez de loguer uniquement « update started ». 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 logs de l'appareil de Capgo pour identifier la première étape en échec. La première erreur est généralement plus utile que le message final « update failed ». Par exemple, un canal manquant indique un problème de routage. Un rejet de compatibilité pointe vers le runtime natif ou le contrôle de version. Une erreur de téléchargement indique un problème d'accès réseau ou de requête du bundle.

Une réinstallation est un test utile, mais elle modifie les preuves. Elle peut effacer l’état local du canal. Utilisez-l’après avoir capturé le canal actuel et les logs, pas avant.

Pour une vérification reproductible, enregistrez ces valeurs dans une seule ligne de log :

• ID de l’app et version native de l’app
• Canal résolu à partir degetChannel()
• Dernière vérification de l’updater
• Version du bundle trouvée par le serveur
• Résultat de l’installation ou du rejet

Cet enregistrement est utile quand l’appareil appartient à un testeur qui n’arrive pas à reproduire le problème à la demande. Il donne aussi à votre équipe CI un signal clair pour les smoke tests automatisés.

Utilisez le dépôt source officiel de l’updater Capgo Capacitor lorsque vous devez inspecter le comportement du plugin API. Faites notamment attention à la différence entre un changement de canal local et une affectation d’appareil depuis le dashboard.

Conseil de pro : Relevez le canal résolu avant de le réinitialiser. Sinon, vous risquez de corriger l’état et de perdre l’indice qui expliquait l’échec.

Étape 5 : Réviser les règles de déploiement, les seuils de version et le rollback automatique

L’objectif est de vérifier si Capgo a volontairement retenu ou annulé le bundle. Une mise à jour manquante est parfois une règle de sécurité qui fonctionne comme prévu.

Ouvrez les paramètres du canal et examinez chaque règle associée à la release. Recherchez les versions minimales de l’app, les paramètres de déploiement progressif par pourcentage, les filtres d’appareils et les conditions liées à la release. Un appareil hors de la règle restera sur son bundle actuel, même si le canal est correct.

Vérifiez aussi le format des versions. Capgo utilise le versionnage sémantique pour comparer les releases. Une condition de version qui semble correcte à première vue peut se comporter différemment si l'app ou le bundle utilise un format inattendu. Gardez un format cohérent entre les builds natifs et les releases OTA.

Examinez ensuite le comportement du rollback. Un rollback automatique peut ramener un appareil à un bundle précédent après l'échec d'un health check. Le dashboard peut afficher l'ancien code actif, alors que la release attendue reste présente mais indisponible.

Ne supprimez pas un bundle suspect avant d'avoir examiné ses événements. La suppression efface des preuves utiles. Notez d'abord la version du bundle, le canal, l'état du déploiement progressif et la raison du rollback. Décidez ensuite de mettre la release en pause ou de publier une version que vous savez fonctionnelle.

Utilisez un canal de déploiement progressif pour les changements à risque. Envoyez d'abord le bundle à un petit groupe de test. Surveillez l'adoption et les signaux d'erreur. Une fois que la release se comporte comme prévu, poursuivez le déploiement progressif. Cela évite qu'un changement défectueux de la couche web atteigne tous les appareils actifs d'un coup.

Le rollback ne répare que les code que l'OTA peut modifier. Si l'échec vient d'un plugin natif manquant ou d'un API natif incompatible, il vous faut un nouveau build pour les stores. Envoyer un bundle JavaScript plus ancien n'ajoutera pas la partie native qui manque à l'app.

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

• Cet appareil remplit-il la condition de version de l'app ?
• Is the device inside the rollout group?
• Un health check ou une action manuelle l'a-t-il ramené à un bundle plus ancien ?

Capgo est utile ici, car le même modèle de canal peut porter une release progressive, prendre en charge un rollback et afficher l’activité des mises à jour dans un seul workflow. Gardez l’ensemble de règles minimal. Une politique courte est plus facile à auditer qu’une pile d’exceptions créées pendant un incident.

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

Un rollback est un garde-fou, pas un substitut aux tests. Gardez un bundle de référence disponible dans chaque canal de production.

Étape 6 : Utilisez l'analyse en temps réel pour identifier le point de défaillance exact

L’objectif est de cesser de traiter « non mis à jour » comme un seul type d’échec. Les analytics peuvent montrer si l’appareil ne s’est jamais signalé, n’a trouvé aucun bundle éligible, a échoué pendant le téléchargement ou a effectué un rollback plus tard.

Commencez par le groupe d’appareils affectés. Filtrez par version de l’application, plateforme, canal et version du bundle. Cherchez une tendance. Si seul un ancien build de l’application échoue, le problème peut être un contrôle de compatibilité native. Si tous les appareils d’un canal échouent, inspectez le canal ou le déploiement.

Comparez l’adoption dans le temps. Une ligne plate après la release suggère un problème de routage ou d’éligibilité. Une hausse suivie d’une baisse suggère des erreurs d’installation ou un rollback. Une hausse lente peut simplement signifier que les appareils n’ont pas encore ouvert l’application.

Utilisez les horodatages avec précaution. L’heure des événements dans le dashboard peut différer de l’heure locale de l’utilisateur. Associez l’événement de mise à jour à la dernière vérification de l’appareil. Cela aide lorsqu’un testeur signale un échec de mise à jour avant que l’app n’ait réellement effectué sa vérification.

Les analytics vous aident aussi à tester un changement de canal en toute sécurité. Ne modifiez qu'une variable à la fois. Gardez le bundle inchangé pendant que vous testez le routage. Ensuite, gardez le routage inchangé pendant que vous testez un nouveau bundle. Si vous modifiez les deux, les données ne pourront pas vous dire quel changement a résolu le problème.

En cas d'incident, conservez quelques éléments de preuve :

• L'identifiant de l'appareil ou le label de test interne
• Le canal résolu
• Version de l'app native
• Le bundle attendu et le bundle installé
• L'heure du dernier check-in
• L'événement de rollback ou de rejet

La vue en temps réel de Capgo est particulièrement utile lorsque votre processus de release envoie des mises à jour via la CI/CD. Un job de déploiement peut envoyer un bundle, tandis qu'une étape de monitoring vérifie que les appareils de test rapportent bien le canal et le bundle prévus. Cela transforme une plainte manuelle en un véritable gate de release.

Liez les données d'analytics aux enregistrements de vos releases. Inscrivez la référence du commit ou du build dans vos notes de déploiement. Lorsque deux bundles ont des labels de version similaires, la référence du build vous indique quel code a réellement été déployé.

Si seuls les appareils existants échouent après une modification du Cloud Default, attendez leur prochain check-in avant de changer d'autres paramètres. Une nouvelle installation est un bon témoin : elle vous indique si la route par défaut fonctionne pour les appareils sans ancien état local.

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

L'objectif est de rendre la dérive des canaux visible avant qu'elle n'affecte les utilisateurs. Une petite checklist de release peut éviter la plupart des cas récurrents.

Choisissez un seul modèle de routage pour chaque environnement d'application. Pour la production, vous pouvez omettredefaultChannelet laisser Capgo Cloud gérer la valeur par défaut. Pour un build de test, vous pouvez définir un canal explicite. La configuration dangereuse, c'est un mélange d'anciens overrides locaux, d'une config native obsolète et d'un nouveau Cloud Default que personne ne vérifie.

Placeznpx cap syncdans le chemin de build après les changements de configuration. Faites échouer le build si l'étape de synchronisation échoue. La commande est simple, mais l'ignorer peut graver le canal d'hier dans le binaire natif d'aujourd'hui.

Ajoutez un smoke test après le déploiement. L'appareil de test doit lancer l'app, appelergetChannel(), vérifier la présence du bundle attendu et enregistrer le résultat. La vérification est souvent l'étape manquante dans les workflows OTA. Un upload seul ne prouve pas grand-chose.

Gardez le canal local code derrière un feature flag clair. Si un helper de test appellesetChannel(), assurez-vous que les builds de production ne puissent pas l'inclure par erreur. Gardez en tête que le cache local peut ne pas apparaître comme un override dans le dashboard : l'UI ne peut donc pas détecter tous les problèmes.

Utilisez une checklist de release comme celle-ci :

1. Confirmez l'ID de l'app et la version native.
2. Choisissez le canal cible.
3. Envoyez le bundle sur ce canal.
4. Confirmez que le bundle est actif.
5. Lancez le smoke test sur l’appareil.
6. Vérifiez le canal renvoyé avecgetChannel().
7. Surveillez l’adoption avant d’élargir le déploiement progressif.

Gardez la protection rollback activée pour les releases de production. Un scénario d’échec courant consiste à déployer sans canal ni plan de rollback clair. L’équipe dispose alors de moins d’options sûres pour arrêter un bundle défaillant.

Capgo fonctionne avec un abonnement par organisation, avec un essai gratuit de 14 jours. Utilisez l’essai pour tester votre workflow de release sur de vrais builds d’app, pas seulement pour consulter un dashboard. Essayez un déploiement progressif, un test de rollback et une vérification automatisée du canal.

La sécurité fait partie de la même checklist. Protégez les tokens CI/CD. Limitez les personnes qui peuvent modifier le Cloud Default. Gardez les identifiants de déploiement de production hors des scripts locaux. Une modification non autorisée du canal peut ressembler à un appareil obsolète jusqu’à ce que vous consultiez le journal d’audit.

Pour les équipes qui livrent souvent, gardez le processus simple. Une commande pour déployer. Un appareil de test connu. Une règle de canal claire. Suivre, adopter, faire un rollback.

À retenir : Évitez le routage obsolète en synchronisant la config, en évitant les overrides locaux cachés, en testant le canal résolu et en gardant un rollback prêt.

FAQ

Pourquoi le canal par défaut cloud 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, une surcharge via le dashboard ou une affectation forcée peut également prendre le pas sur le Cloud Default. Vérifiez le canal résolu de l’appareil avecgetChannel(), supprimez toute affectation plus forte, puis ramenez l’application au premier plan.

Est-ce que changer le Cloud Default de Capgo modifie toutes les applications installées ?

Non, modifier le Cloud Default ne réécrit pas instantanément le canal de toutes les applications installées. Les nouveaux appareils peuvent utiliser le nouveau défaut immédiatement. Les installations existantes doivent se connecter avant de pouvoir basculer, et elles ne basculeront pas si une règle de canal plus forte ou une surcharge locale s’applique.

Que fait npx cap sync lors d'un changement de canal Capgo ?

npx cap synccopie la configuration Capacitor mise à jour dans les projets natifs. Si vous modifiezdefaultChannelmais omettez la synchronisation, le prochain build natif peut toujours contenir l’ancien paramètre de canal. Exécutez la commande depuis la racine du projet, puis compilez et installez un binaire de test frais.

Est-ce que setChannel crée un override d'appareil dans Capgo ?

Non,setChannel()modifie le canal stocké localement par l’application. Il ne crée pas de Device Override côté backend, donc le dashboard Capgo peut ne pas afficher l’appareil comme surchargé. Effacez l’affectation locale lorsque l’appareil doit revenir au routage par défaut, puis vérifiez le résultat avecgetChannel().

Est-ce que Capgo peut mettre à jour le code natif via un bundle OTA ?

Non, les mises à jour OTA de Capgo s'appliquent à la couche web code comme le JavaScript, le CSS et les assets. Un plugin natif, une permission ou un changement de API natif nécessite un nouveau build pour les stores. Si le bundle attend des code natifs que l'application installée ne possède pas, la mise à jour peut être rejetée même si le canal est correct.

Conclusion

Commencez par le canal résolu, pas par le défaut du dashboard. Vérifiez les assignations, lanceznpx cap sync, vérifiez le bundle par rapport au runtime natif et inspectez les logs de l'appareil avant de modifier les règles de déploiement. Ajoutez ensuite un petit test post-déploiement dans Capgo qui appellegetChannel()et confirme le bundle attendu.