Comment définir les tentatives d'auto-pause de Capgo

Un seuil d'essais trop bas peut mettre en pause un déploiement progressif sain. Un seuil trop élevé peut laisser un mauvais bundle atteindre trop d'appareils. Le paramètre Capgo pauses automatiques après tentatives minimales contrôle le moment où 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 flux de release.

Table of Contents

• Étape 1 : Comprendre le contrôle du minimum attempts
• Étape 2 : Trouver le paramètre Auto-Pause dans Capgo
• Étape 3 : Choisir une valeur sûre pour les tentatives minimales
• Étape 4 : Tester l'auto-pause avec un déploiement par canal
• Étape 5 : Surveiller les tentatives, l'analyse et le rollback auto
• Étape 6 : Automatiser le paramètre dans votre CI/CD
• FAQ
• Conclusion

Étape 1 : Comprendre le rôle des tentatives minimales

Le auto-pause : nombre d'essais minimum cette valeur définit le plus petit échantillon Capgo nécessite avant que ses règles de pause ne s'appliquent. C'est un seuil de contrôle, pas une limite d'échec. Ce paramètre indique à Capgo d'attendre qu'un nombre suffisant de tentatives de mise à jour soit atteint avant de juger le déploiement.

Une tentative peut inclure un appareil essayant d'installer un bundle. La tentative peut réussir ou échouer. Le résultat exact dépend du chemin de mise à jour, de l'état de l'app et de la configuration de l'updater. C'est pourquoi cette valeur doit être choisie en fonction de la taille de votre déploiement.

La référence au canal de Capgo décritauto-pause-min-attemptscomme le nombre minimum de tentatives d'installation réussies ou échouées avant que l'auto-pause ne s'active. 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 API que vous utilisez. Vous pouvez examiner les champs CLI du canal Capgo avant de modifier un canal live.

Considérez ce paramètre comme une règle de preuve minimale. Une valeur de 1 peut déclencher une réaction dès la première tentative enregistrée. Cela peut aider lors d'un test interne très restreint, mais cela peut aussi réagir à une seule session réseau instable. 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 les mêmes que les personnes uniques. Un appareil peut retenter une mise à jour. Un seul utilisateur peut lancer l'application sur plusieurs appareils. Votre vue analytique peut également regrouper les événements d'une manière différente de vos propres métriques produit.

Avant de choisir un nombre, notez ce que vous voulez que le seuil protège. Si l'objectif est de détecter rapidement un bundle JS défectueux, un petit canal contrôlé peut utiliser une valeur plus basse. Si l'objectif est de protéger une release de production étendue, vous avez besoin d'assez de tentatives pour éviter des décisions basées sur un seul appareil ou une courte panne.

• Utilisez un seuil faible pour un canal de test privé.
• Utilisez un seuil plus élevé lorsque le canal comporte des types de réseaux et d'appareils variés.
• Augmentez le seuil si des interruptions brèves ont provoqué des pauses injustifiées.
• Ne le baissez que si le coût d'une détection tardive est supérieur au coût d'une pause erronée.

L'auto-pause doit stopper un déploiement progressif. Elle ne remplace pas la revue du bundle, les tests sur appareil ou un plan de rollback clair. Considérez ce seuil comme un contrôle parmi d'autres dans votre processus de release.

L'essentiel : Minimum attempts contrôle la quantité de preuves de rollout dont Capgo a besoin avant que sa politique d'auto-pause ne s'applique.

Étape 2 : Trouvez le paramètre d'auto-pause dans Capgo

Pour définir la Capgo valeur de l'auto-pause minimum attempts, commencez par identifier le canal qui distribue le bundle. L'auto-pause fait partie du contrôle du rollout ; modifier la config de l'updater au niveau de l'app peut ne pas changer la politique du canal comme vous l'espériez.

Commencez dans le dashboard Capgo ou utilisez la commande channel et le chemin API déjà utilisé par votre équipe. 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 minimum attempts et un réglage de confiance. Gardez ces champs ensemble lors de votre revue de changement. Un échantillon minimum définit quand Capgo peut juger le rollout. Une valeur de confiance peut influencer la force du signal nécessaire avant qu'une pause ne survienne.

Définissez la valeur via un chemin auditable

Utilisez le dashboard pour les changements rapides et contrôlés lorsque votre équipe enregistre les modifications via le dashboard. Utilisez CLI si le paramètre doit figurer dans 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 rollout et la nouvelle valeur dans le même enregistrement de modification. Cela vous permettra de comprendre clairement pourquoi un canal se met en pause plus tard.

Pour les workflows pilotés par API, Capgo expose les ressources du canal via son API public. Le documentation API du canal Capgo est l'endroit idéal pour vérifier les noms de champs et la structure des requêtes au lieu de deviner à partir d'un script local.

Lorsque vous modifiez la valeur, saisissez un nombre entier comme l'attend le champ. N'ajoutez pas de signe pourcentage. N'utilisez pas de décimale. Si votre outil stocke la configuration en JSON, conservez l'orthographe exacte de la clé et préservez le format string indiqué dans la référence Capgo actuelle.

Confirmer le changement

Relisez le canal après l'avoir enregistré. Ne supposez pas qu'une commande réussie signifie que le champ souhaité a été modifié. Vérifiez les données du canal retournées ou la valeur dans le dashboard.

Posez ensuite trois questions :

• Le paramètre a-t-il changé sur le canal prévu ?
• Le canal pointe-t-il toujours vers le bundle prévu ?
• Le rollout 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 indique un succès sans vérifier l'état sauvegardé est difficile à croire.

Étape 3 : Choisir une valeur sûre pour le minimum d'essais

Choisissez la valeur de Capgo pour le minimum d'essais de l'auto-pause en fonction de la taille et du risque du déploiement progressif. Il n'existe pas de chiffre universel pour toutes les apps. Le bon seuil permet à la politique de collecter assez de preuves tout en détectant rapidement une mauvaise mise à jour.

Commencez par le groupe le plus restreint capable de vous fournir des données 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 quelques jours. Ces groupes ne devraient pas partager le même seuil par défaut.

Utilisez une règle de décision simple

Demandez-vous combien d'essais sont nécessaires avant qu'un schéma d'échec ne devienne significatif. 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 simple problème réseau.

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 dessert une grande variété d'appareils.
• Les utilisateurs se connectent via des réseaux instables.
• The app has low daily open frequency.
• Une courte interruption pourrait générer de nombreux faux échecs.

N'utilisez pas le seuil pour masquer un problème connu. Si un bundle échoue à cause d'un plugin natif requis, mettez la release en pause manuellement et corrigez la cause. Un réglage de tentatives minimales ne rendra jamais un bundle incompatible sûr.

Pair the threshold with rollout size

Supposons que vous publiiez d'abord sur un petit canal interne. Vous pourriez choisir un seuil permettant à l'équipe de voir plusieurs résultats d'installation avant que l'auto-pause ne s'active. Une fois que le bundle a passé cette étape, transférez-le vers un canal plus large avec un seuil adapté à l'échantillon plus important.

Cette approche permet d'obtenir un premier signal rapide sans demander à la politique de production de réagir à un échantillon minuscule. Cela vous donne aussi un point de contrôle clair pour ajuster le réglage. Modifiez le seuil en fonction du canal, et non après l'échec du déploiement progressif.

Suivez cette valeur à côté de l'historique de la release. Notez pourquoi vous l'avez choisie, ce qui vous ferait la modifier et qui peut approuver ce changement. C'est crucial lorsqu'un membre de l'équipe voit un canal en pause lors d'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 plutôt que par conjecture.

Étape 4 : Testez l'auto-pause avec un déploiement progressif par canal

Testez l'auto-pause sur un canal avant de vous y fier en production. Un canal définit un périmètre pour le test. Vous pouvez envoyer un bundle à un groupe spécifique, observer la hausse des tentatives et confirmer le comportement lorsque la politique atteint son seuil.

D'abord, créez un bundle de test identifiable pour ne pas le confondre avec une release en direct. Préservez bien le changement code. Le test doit prouver que les contrôles de la release fonctionnent, sans créer un second problème applicatif.

Ensuite, assignez un petit groupe d'appareils de test au canal. Vérifiez que chaque appareil possède la version native attendue de l'app. Les code OTA ne peuvent pas corriger tous les écarts natifs ; un appareil utilisant le mauvais binaire peut fausser le test.

Publiez le bundle sur le canal. Utilisez une 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 comptez pas sur le défilement du terminal lors d'un incident.

Testez le processus de pause

Vous avez besoin d'un moyen sûr de générer une tentative échouée. Utilisez un bundle dédié aux tests ou une condition d'échec contrôlée et validée par votre équipe. Ne corrompez jamais un bundle de production juste pour vérifier si l'auto-pause fonctionne.

Surveillez la séquence suivante :

1. Le canal pointe vers le bundle de test.
2. Les appareils reçoivent l'instruction de mise à jour.
3. Les tentatives apparaissent dans la vue analytics.
4. Le nombre minimum de tentatives est atteint.
5. Le signal d'échec provoque la pause du canal, si les conditions de la politique sont remplies.

La cinquième étape est cruciale. Atteindre la valeur minimale d'essais peut rendre l'auto-pause éligible. Cela ne signifie pas que chaque déploiement progressif s'arrête exactement à ce nombre. D'autres paramètres de politique et les résultats observés peuvent influencer le résultat.

Testez également la récupération

Après la pause, confirmez ce que reçoivent les utilisateurs. Vérifiez si le bundle défectueux reste sélectionné, si les nouveaux appareils cessent de le recevoir et si le précédent bundle stable est disponible pour un rollback. La réponse dépend de votre configuration d'updater et de canal, vérifiez donc cela via les logs de l'app plutôt que de le supposer.

Ensuite, reprenez avec un bundle stable uniquement après qu'une personne a analysé l'échec. Si l'échec provient d'un mauvais build, créez un nouveau bundle. Ne vous contentez pas de renvoyer le même artefact en espérant que la prochaine tentative se passe différemment.

Documentez le résultat du test. Incluez le seuil, le nombre d'appareils, la condition d'échec, le temps de pause et l'action de récupération. Cela transforme un test ponctuel en un contrôle de release reproductible.

Étape 5 : Surveillez les essais, l'analytics et le rollback automatique

Le monitoring vous indique si la règle d'essais minimaux d'auto-pause de Capgo concerne un déploiement sain ou défectueux. Surveillez le nombre d'essais parallèlement au comportement d'échec. Un chiffre sans contexte peut vous amener à faire une pause trop tôt ou à manquer un problème croissant.

Utilisez Capgo Observe pour inspecter l'activité des mises à jour et le statut du déploiement. La documentation Capgo Observe décrit la zone qui sert à consulter les informations de mise à jour et à configurer le comportement d'auto-pause. Gardez le dashboard ouvert pendant la première phase d'une release, surtout quand le bundle modifie le code de démarrage ou un flux applicatif critique.

Croisez les signaux

Regardez d'abord le total des tentatives. Vérifiez ensuite le nombre d'échecs et leur répartition dans le temps. Un flux régulier d'installations réussies ne ressemble pas à une salve d'échecs après l'activation d'un bundle.

Vérifiez les détails de l'appareil et de la version de l'app lorsqu'ils sont disponibles. Si les échecs se concentrent sur une version native, le bundle OTA nécessite peut-être un binaire plus récent. S'ils touchent 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 interruption peut générer des tentatives échouées sans défaut code. C'est pourquoi le seuil doit s'appuyer sur une politique de confiance et un processus de revue humaine. L'auto-pause peut arrêter l'exposition, mais elle ne peut pas expliquer chaque échec.

Comprenez ce que signifie un rollback dans votre flux

Un rollback ramène les utilisateurs concernés vers une release connue comme stable ou empêche la mauvaise release d'atteindre davantage d'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 déjà exécutée par un bundle OTA.

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 d'un appareil hors ligne pendant la pause. Enfin, rédigez les étapes de récupération là où l'ingénieur d'astreinte pourra les trouver.

Les Capgo documentation sur le rollback peut vous aider à faire correspondre les contrôles de rollback disponibles avec votre plan de canal. 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.

Lors d'un incident, commencez par une pause si le schéma d'erreur est clair. Inspectez ensuite les logs et les changements de bundle. Passer quelques minutes à stopper l'exposition est généralement plus facile à gérer que de laisser une release défectueuse se propager.

Étape 6 : Automatiser le paramètre dans la CI/CD

Intégrez la valeur de Capgo auto pause minimum attempts dans votre workflow de release lorsque le paramètre varie selon le canal. L'automatisation élimine les dérives manuelles. Elle rend également 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 :

1. Compiler le bundle web.
2. Exécuter les tests et vérifier la compatibilité native.
3. Envoyer le bundle.
4. Définir ou confirmer le canal cible.
5. Appliquer le nombre minimum de tentatives.
6. Vérifier l'état enregistré du canal.
7. 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égrer la vérification au job

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 IDs 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 pourrait nécessiter :

• 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. Mappez-les aux champs CLI ou API exacts en un seul endroit. Cela facilitera la revue des futurs changements.

Pour un contrôle de sécurité approfondi, consultez les recommandations de Capgo sur la sécurisation des live updates dans les pipelines CI/CD. La bonne pratique est simple : limitez l'accès aux tokens, loguez 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. Ajoutez la raison du changement. Si un déploiement progressif s'arrête de manière inattendue, vous pourrez 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. Concentrez votre essai : configurez un canal, lancez un test de pause et vérifiez un chemin de rollback.

Une seule commande peut publier la mise à jour. Le workflow le plus sûr est celui qui vérifie également le canal, suit l'adoption et prévoit une option de rollback.

FAQ

Que signifie Capgo auto pause minimum attempts ?

Capgo auto pause minimum attempts définit le nombre minimum d'installations et d'échecs requis avant que la politique d'auto-pause ne s'applique. Il s'agit d'un seuil de taille d'échantillon, et non d'un pourcentage d'installations échouées. Une valeur basse réagit plus vite mais repose sur moins de données. Une valeur haute laisse plus de temps au canal pour collecter des résultats.

Où puis-je configurer l'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'accès public à 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 est la valeur de tentatives minimales sécurisée ?

Une valeur sûre dépend de la taille du canal, de la diversité des 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 en production. Commencez par un groupe connu, surveillez le volume de tentatives et ajustez en fonction du comportement observé.

Atteindre la valeur minimale de tentatives met-il toujours une release en pause ?

Non. Atteindre la valeur minimale de tentatives Capgo rend le déploiement éligible à l'auto-pause, mais d'autres conditions de la politique entrent toujours en compte. Les signaux d'échec, les paramètres de confiance, l'état du canal et le flux de l'updater peuvent affecter le résultat. Testez tout le processus 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, tandis que le rollback redirige les utilisateurs vers un bundle stable lorsque cette option est disponible. Testez les deux contrôles. 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 le nombre minimal de tentatives par canal, pas par habitude. Commencez par un petit déploiement de test, vérifiez les chemins de pause et de rollback, puis automatisez le paramètre validé dans la CI/CD. Pour tester le workflow, essayez Capgo avec un canal et un bundle contrôlé avant d'étendre le déploiement.