Un seuil d’essais trop bas peut mettre en pause un déploiement OTA sain. Un seuil trop élevé peut laisser un mauvais bundle atteindre trop d’appareils. Le Capgo pause automatique après tentatives minimales détermine quand Capgo dispose de suffisamment de données d’installation et d’échec pour mettre un canal en pause. Suivez les étapes ci-dessous pour le configurer avec soin, le tester et l’intégrer à votre processus de release.
Table des matières
- Étape 1 : Comprendre ce que contrôle le minimum de tentatives
- Étape 2 : trouver le réglage Auto-Pause dans Capgo
- Étape 3 : Choisir une valeur sûre pour le minimum d'essais
- Étape 4 : testez l'auto-pause avec un déploiement par canal
- Étape 5 : surveillez les tentatives, l'analytics et le rollback automatique
- Étape 6 : Automatisez le paramètre dans la CI/CD
- FAQ
- Conclusion
Étape 1 : Comprendre ce que contrôle le minimum de tentatives
Le pause automatique après tentatives minimales Cette valeur définit le nombre minimal d'échantillons dont Capgo a besoin avant que ses règles de pause puissent s'appliquer. C'est un seuil, pas une limite d'échecs. Ce paramètre demande à Capgo d'attendre qu'il y ait assez de tentatives de mise à jour avant de juger le déploiement.
Une tentative peut correspondre à un appareil qui essaie d'installer un bundle. Elle peut réussir ou échouer. Le résultat exact dépend du chemin de mise à jour, de l'état de l'application et de la configuration de l'updater. C'est pourquoi il faut lire cette valeur en tenant compte de la taille de votre déploiement.
La référence au canal de Capgo décritauto-pause-min-attemptsen tant que nombre minimal de tentatives d’installation et d’échec avant que la pause automatique ne prenne effet. Le champ est représenté sous forme de chaîne dans la référence CLI, conservez donc la valeur au format attendu par la commande ou l’API que vous utilisez. Vous pouvez consulter les champs CLI du canal Capgo avant de modifier un canal actif.
Considérez ce paramètre comme une règle de preuve minimale. Une valeur de 1 peut réagir après la première tentative enregistrée. Cela peut être utile lors d’un test interne très restreint, mais cela peut aussi réagir à une simple session réseau défaillante. Une valeur plus élevée laisse plus de temps au déploiement progressif pour collecter un échantillon utile.
Distinguer les tentatives des utilisateurs
Les tentatives ne sont pas équivalentes à des personnes uniques. Un même appareil peut réessayer une mise à jour. Un utilisateur peut exécuter l’application sur plusieurs appareils. Votre vue d’analyse peut également regrouper les événements différemment de vos propres métriques produit.
Avant de choisir une valeur, notez ce que le seuil doit protéger. Si l’objectif est de détecter tôt un bundle JavaScript défectueux, un canal de test contrôlé peut utiliser une valeur plus basse. Si l’objectif est de protéger une release de production large, il faut assez de tentatives pour éviter des décisions basées sur un seul appareil ou une panne brève.
- Utilisez un seuil faible pour un canal de test privé.
- Utilisez un seuil plus élevé lorsque le canal comporte des réseaux et des types d’appareils variés.
- Augmentez le seuil si des pannes brèves ont provoqué des pauses fausses.
- Réduisez-l’uniquement si le coût d’une détection tardive dépasse celui d’une pause fausse.
L’auto-pause doit arrêter un déploiement progressif. Elle ne doit pas remplacer la revue du bundle, les tests sur appareil ou un plan de rollback clair. Considérez le seuil comme un contrôle parmi d’autres dans votre processus de release.
À retenir : Minimum attempts définit la quantité de preuves de rollout dont Capgo a besoin avant que sa politique d’auto-pause puisse agir.
Étape 2 : trouver le réglage Auto-Pause dans Capgo
Pour définir le Capgo Valeur minimale de tentatives avant auto-pause : commencez par identifier le canal qui distribue le bundle. L’auto-pause relève du contrôle du déploiement progressif, donc modifier la configuration globale du metteur à jour de l’application ne modifie pas nécessairement la politique du canal attendue.
Commencez par le dashboard Capgo ou utilisez la commande de canal et le chemin API que votre équipe utilise déjà. Vérifiez le nom du canal avant toute modification. Un canal de test et un canal de production peuvent avoir des noms similaires, et une valeur correcte sur le mauvais canal reste un incident de release en puissance.
Cherchez les champs d’auto-pause dans les paramètres du canal. Les champs associés peuvent inclure la valeur minimale de tentatives et un réglage de confiance. Gardez ces champs ensemble lors de la revue de vos modifications. Un échantillon minimal indique quand Capgo peut évaluer le déploiement progressif. Une valeur de confiance peut influencer la force du signal requise avant qu’une pause ne se produise.
Définissez la valeur via le chemin que vous pouvez auditer
Utilisez le dashboard pour un changement rapide et contrôlé si votre équipe enregistre les modifications du dashboard. Utilisez CLI lorsque le réglage appartient à un script de release. Utilisez l’API public lorsqu’un service gère la politique du canal dans le cadre d’un système de déploiement plus large.
Quel que soit le chemin choisi, capturez d’abord l’ancienne valeur. Enregistrez le nom du canal, la version du bundle, l’état du déploiement progressif et la nouvelle valeur dans le même enregistrement de changement. Cela vous donnera une réponse claire si le canal se met en pause plus tard.
Pour les workflows pilotés par API, Capgo expose les ressources de canal via son API public. Le documentation du canal Capgo API est l’endroit idéal pour vérifier les noms de champs et la structure de la requête plutôt que de deviner à partir d’un script local.
Lorsque vous modifiez la valeur, saisissez un nombre entier, comme l’exige le champ. N’ajoutez pas de signe de pourcentage. N’utilisez pas de décimale. Si votre outil stocke la configuration en JSON, respectez exactement l’orthographe de la clé et conservez le format de chaîne indiqué dans la référence actuelle de Capgo.
Confirmer la modification
Relisez le canal après l’avoir enregistré. Ne supposez pas qu’une commande réussie signifie que le champ prévu a été modifié. Vérifiez les données du canal renvoyées ou la valeur dans le dashboard.
Posez-vous ensuite trois questions :
- Le paramètre a-t-il bien changé sur le canal prévu ?
- Le canal pointe-t-il toujours vers le bundle prévu ?
- Le déploiement progressif est-il actif, en pause ou terminé ?
Si la valeur n'apparaît pas, arrêtez-vous là. Vérifiez les permissions, l'orthographe du champ et l'identifiant du canal. Un script de déploiement qui signale un succès sans vérifier l'état enregistré inspire peu confiance.
Étape 3 : Choisir une valeur sûre pour le minimum d'essais
Choisissez la valeur minimale de tentatives pour la pause automatique Capgo en fonction de la taille et du risque du déploiement progressif. Il n'existe pas de chiffre sûr pour toutes les apps. Le bon seuil donne à la politique assez de preuves tout en détectant tôt une mauvaise mise à jour.
Commencez par le groupe le plus restreint capable de vous fournir des informations utiles. Un canal privé peut contenir des appareils internes avec des versions d'app connues. Un canal de production peut inclure des appareils plus anciens, des connexions instables et des utilisateurs qui n'ouvrent l'app qu'une fois tous les deux ou trois jours. Ces groupes ne doivent pas partager le même seuil par défaut.
Utilisez une règle de décision simple
Demandez-vous combien de tentatives sont nécessaires pour qu'une tendance aux échecs soit significative. Si votre canal de test ne compte que quelques appareils, un seuil élevé pourrait ne jamais être atteint durant la fenêtre de test. Si votre canal de production reçoit de nombreuses tentatives en quelques minutes, un seuil très bas pourrait mettre la release en pause après un problème réseau passager.
Définissez une valeur plus basse quand :
- Le canal est privé.
- Le bundle modifie une fonctionnalité à haut risque.
- Vous avez besoin d'un feedback rapide lors d'un test progressif.
- Votre équipe peut inspecter chaque échec peu après la release.
Définissez une valeur plus haute quand :
- Le canal sert un large éventail d’appareils.
- Les utilisateurs se connectent via des réseaux instables.
- L’application est ouverte peu de fois par jour.
- Une courte interruption pourrait générer de nombreuses fausses erreurs.
N'utilisez pas le seuil pour masquer un problème connu. Si un bundle échoue sur un plugin natif requis, mettez la release en pause vous-même et corrigez la cause. Un réglage de tentatives minimales ne peut pas rendre un bundle incompatible sûr.
Associez le seuil à la taille du déploiement
Supposons que vous déployiez d'abord sur un petit canal interne. Vous pourriez choisir un seuil permettant à l'équipe de voir plusieurs résultats d'installation avant que la pause automatique ne s'active. Une fois que le bundle passe cette étape, déplacez-le vers un canal plus large avec un seuil reflétant l'échantillon plus important.
Cette approche garde le premier signal rapide sans demander à la politique de production de réagir à un échantillon minuscule. Elle vous donne aussi un endroit clair pour ajuster le réglage. Modifiez le seuil avec le canal, pas après l'échec du déploiement progressif.
Suivez la valeur à côté de l'enregistrement de la release. Notez pourquoi vous l'avez choisie, ce qui vous amènerait à la modifier, et qui peut approuver cette modification. C'est important lorsqu'un membre de l'équipe voit un canal en pause pendant un incident et a besoin de contexte rapidement.
Conseil de pro : Commencez par un canal contrôlé, enregistrez son volume de tentatives, puis ajustez le seuil de production en fonction du comportement observé du déploiement progressif plutôt qu'à l'aveugle.
Étape 4 : testez l'auto-pause avec un déploiement par canal
Testez l'auto-pause sur un canal avant d'en dépendre en production. Un canal vous donne un périmètre pour le test. Vous pouvez envoyer un bundle à un groupe connu, observer la hausse des tentatives et confirmer ce qui se passe lorsque la politique atteint son seuil.
Créez d'abord un bundle de test que vous pouvez identifier sans le confondre avec une release active. Préservez la modification code. Le test doit valider les contrôles de release, pas créer un second problème applicatif.
Ensuite, assignez un petit groupe d'appareils de test au canal. Vérifiez que chaque appareil a la version native attendue de l'app. Les code OTA ne peuvent pas corriger tous les écarts natifs ; un appareil qui exécute le mauvais binaire peut fausser les résultats du test.
Publiez le bundle sur le canal. Utilisez une seule commande de votre flux de déploiement Capgo habituel si possible, mais conservez les IDs du bundle et du canal dans les logs de release. Ne vous fiez pas à l'historique de défilement du terminal pendant un incident.
Testez le scénario de pause
Vous avez besoin d'un moyen sûr de générer une tentative en échec. Utilisez un bundle réservé aux tests ou une condition d'échec contrôlée validée par votre équipe. Ne corrompez jamais un bundle de production juste pour voir si l'auto-pause fonctionne.
Surveillez la séquence suivante :
- Le canal pointe vers le bundle de test.
- Les appareils reçoivent l'instruction de mise à jour.
- Les tentatives apparaissent dans la vue analytics.
- Le nombre minimum de tentatives est atteint.
- Le signal d'échec met le canal en pause si les conditions de la politique sont réunies.
La cinquième étape est importante. Atteindre la valeur minimale de tentatives peut rendre l’auto-pause éligible. Cela ne signifie pas que chaque déploiement progressif est mis en pause à ce nombre exact. D'autres champs de politique et les résultats observés peuvent influencer le résultat.
Testez aussi la récupération
Après la pause, vérifiez ce que reçoivent les utilisateurs. Assurez-vous que le bundle en échec reste sélectionné, que les nouveaux appareils cessent de le recevoir et que le bundle précédent, sûr, est disponible pour un rollback. La réponse dépend de votre configuration d’updater et de canal, donc validez via les logs de l’app plutôt que de supposer.
Reprenez ensuite uniquement avec un bundle connu bon, après qu’une personne a examiné l’échec. Si l’échec provient d’un mauvais build, créez un nouveau bundle. Ne repoussez pas simplement le même artefact en espérant que la prochaine tentative se comporte différemment.
Documentez le résultat du test. Incluez le seuil, le nombre d’appareils, la condition d’échec, la durée de la pause et l’action de récupération. Cela transforme un test ponctuel en vérification de release réutilisable.
Étape 5 : surveillez les tentatives, l'analytics et le rollback automatique
La surveillance vous indique si la règle de pause automatique minimale de tentatives de Capgo observe un déploiement progressif sain ou un déploiement cassé. Surveillez le nombre de tentatives à côté du comportement d’échec. Un comptage sans contexte peut vous amener à mettre en pause trop tôt ou à manquer un problème qui s’aggrave.
Use Capgo Observe to inspect update activity and rollout status. The documentation de Capgo Observe décrit la zone utilisée pour afficher les informations de mise à jour et configurer le comportement de pause automatique. Gardez le dashboard ouvert pendant la première partie d’une release, surtout lorsque le bundle modifie le démarrage de code ou un flux central de l’app.
Analysez les signaux ensemble
Regardez d'abord le total des tentatives. Vérifiez ensuite le nombre d'échecs et la répartition dans le temps. Un flux régulier d'installations réussies ne ressemble pas à une rafale d'échecs après l'activation d'un bundle.
Vérifiez les détails de l'appareil et de la version de l'app quand ils sont disponibles. Si les échecs se concentrent sur une seule version native, le bundle OTA peut nécessiter un binaire plus récent. S'ils apparaissent sur toutes les versions, inspectez le bundle lui-même ou le chemin du service de mise à jour.
Les pannes réseau peuvent créer du bruit. Une courte coupure peut produire des tentatives échouées sans défaut de code. C'est pourquoi le seuil doit s'appuyer sur une politique de confiance et un processus de revue humaine. L'auto-pause peut stopper l'exposition, mais elle ne peut pas expliquer chaque échec.
Comprenez ce que le rollback implique dans votre flux
Un rollback ramène les utilisateurs affectés vers une release connue comme fiable ou empêche la mauvaise release d'atteindre d'autres appareils. Il ne répare pas un binaire natif auquel il manque une capacité requise. Il ne peut pas non plus annuler une migration de données qu'un bundle OTA a déjà exécutée.
Avant la mise en production, confirmez la procédure de rollback avec un canal de test. Vérifiez quel bundle est considéré comme sûr. Testez le comportement lorsqu'un appareil est hors ligne pendant la pause. Enfin, rédigez les étapes de récupération pour qu'elles soient accessibles à l'ingénieur d'astreinte.
de Capgo documentation de rollback peut vous aider à associer les contrôles de rollback disponibles à votre plan de canaux. Utilisez le comportement documenté comme référence, car le résultat peut dépendre de la version de l'updater et de la configuration de la release.
En cas d'incident, commencez par une pause si le schéma de défaillance est clair. Inspectez ensuite les logs et les changements de bundle. Arrêter l'exposition pendant quelques minutes est généralement plus simple à gérer que de laisser une release défectueuse continuer à se propager.
Étape 6 : Automatisez le paramètre dans la CI/CD
Placez la valeur Capgo auto pause minimum attempts dans votre workflow de release lorsque le paramètre change selon le canal. L'automatisation élimine les dérives manuelles. Elle rend aussi le seuil choisi visible lors de la revue code.
Séparez la politique des canaux des secrets. Le nom du canal, l'étape de déploiement progressif et la valeur des tentatives minimales peuvent figurer dans une configuration versionnée. Les tokens API doivent rester dans votre gestionnaire de secrets CI/CD. Ne committez jamais un token dans un dépôt simplement parce que le paramètre du canal s'y trouve déjà.
Un job de release doit suivre un ordre précis :
- Compiler le bundle web.
- Exécuter les tests et vérifier la compatibilité native.
- Envoyer le bundle.
- Définir ou confirmer le canal cible.
- Appliquer la valeur d'essais minimum.
- Vérifier l'état du canal enregistré.
- Publier ou avancer le déploiement progressif.
Utilisez un mode dry-run ou une étape de revue si votre système de déploiement le permet. La revue doit afficher l'identifiant du bundle, le canal, le seuil et l'action de déploiement avant l'exécution de l'étape de production.
Intégrez la vérification dans votre workflow
Une fois la commande API ou CLI terminée, récupérez à nouveau l'état du canal. Faites échouer le job si la valeur retournée ne correspond pas à la configuration attendue. Cela permet de détecter les ID de canal erronés, les champs rejetés et les mises à jour partielles.
Les variables d'environnement sont un moyen courant de transmettre les paramètres de release à un job CI. Le job peut lire un nom de canal ou un seuil sans placer de secrets dans les fichiers sources. Gardez des noms de variables clairs et validez-les avant le déploiement.
Par exemple, votre workflow peut exiger :
CAPGO_CHANNELpour le canal cible.CAPGO_MIN_ATTEMPTSpour le seuil approuvé.CAPGO_BUNDLE_IDpour le bundle envoyé.
Ces noms sont des conventions de workflow, pas des noms de champs Capgo. Associez-les aux champs CLI ou API exacts, à un seul endroit. Les futurs changements seront ainsi plus faciles à relire.
Pour un contrôle de sécurité plus poussé, consultez les recommandations de Capgo sur la sécurisation des mises à jour OTA dans les pipelines CI/CD. La bonne habitude est simple : limitez l'accès aux tokens, tracez la décision de release et vérifiez le résultat après chaque changement.
Conservez un historique des changements
Stockez le seuil avec l'ID du commit ou de la release. Indiquez la raison du changement. Si un déploiement progressif se met en pause de façon inattendue, vous pouvez comparer la politique avec le bundle et l'heure du déploiement.
Capgo est facturé sous forme d'abonnement par organisation, avec un essai gratuit de 14 jours plutôt qu'un achat unique. Ce modèle convient aux équipes qui souhaitent tester le workflow de release avant de l'intégrer à leur processus de livraison habituel. Gardez l'essai ciblé : configurez un canal, lancez un test de pause et vérifiez un scénario de rollback.
Une seule commande suffit pour publier la mise à jour. Le workflow le plus sûr est celui qui vérifie aussi le canal, suit l'adoption et permet un rollback.
FAQ
Que signifie le paramètre auto pause minimum attempts de Capgo ?
Le paramètre auto pause minimum attempts de Capgo définit le nombre minimum d'installations et d'échecs requis avant que la politique d'auto-pause puisse s'appliquer. C'est un seuil de taille d'échantillon, pas un pourcentage d'installations échouées. Une valeur basse réagit plus vite mais repose sur moins de données. Une valeur plus élevée laisse plus de temps au canal pour collecter des résultats.
Où configurer le paramètre auto pause minimum attempts dans Capgo ?
Vous définissez la valeur sur le canal qui distribue le bundle OTA. Utilisez le dashboard Capgo, CLI, ou l'API publique API, puis relisez le canal pour confirmer le champ enregistré. Vérifiez d'abord le nom du canal. Modifier un canal de test alors que la production est active ne changera pas le déploiement en production.
Quelle valeur minimale d'essais choisir sans risque ?
Une valeur sûre dépend de la taille du canal, du parc d'appareils, de la qualité du réseau et du risque lié à la release. Utilisez un seuil plus bas pour un canal de test contrôlé. Utilisez un seuil plus élevé pour un déploiement progressif à grande échelle en production. Commencez par un groupe connu, surveillez le volume d'essais et ajustez selon le comportement observé.
Atteindre la valeur minimale d'essais met-il toujours une release en pause ?
Non. Atteindre la valeur minimale d'essais Capgo rend le déploiement éligible à l'auto-pause, mais d'autres conditions de politique entrent toujours en jeu. Les signaux d'échec, les réglages de confiance, l'état du canal et le flux de l'updater peuvent affecter le résultat. Testez l'ensemble du parcours de pause avec un bundle sûr avant de vous y fier en production.
L'auto-pause peut-elle remplacer un plan de rollback ?
Non. L'auto-pause arrête ou limite l'exposition supplémentaire, tandis que le rollback ramène les utilisateurs vers un bundle connu comme stable quand ce chemin est disponible. Testez les deux mécanismes. N'oubliez pas non plus qu'un rollback OTA ne peut pas ajouter une capacité native que l'application installée ne possède pas.
Conclusion
Définissez la valeur minimale de tentatives par canal, et non par habitude. Commencez par un petit déploiement progressif de test, vérifiez les mécanismes de pause et de rollback, puis automatisez le paramètre validé dans votre CI/CD. Si vous voulez tester le workflow, essayez Capgo avec un canal et un bundle contrôlé avant d'élargir le déploiement.
