Comment configurer l'auto pause de tentatives de Capgo

Une faible limite d'essais peut suspendre un déploiement OTA sain. Une limite élevée peut permettre à un paquet malveillant de parvenir à trop de dispositifs. Le Capgo le paramètre __CAPGO_KEEP_0__ pause automatique minimum tentatives setting controls when Capgo has enough install and failure data to pause a channel. Use the steps below to set it with care, test it, and connect it to your release flow.

Table des matières

• Étape 1 : Comprenez ce que contrôle les tentatives minimum
• Étape 2 : Trouvez la mise en pause automatique dans Capgo
• Étape 3 : Choisissez une valeur de tentatives minimum sûre
• Étape 4 : Tester l'arrêt automatique avec un déploiement basé sur un canal
• Étape 5 : Surveiller les tentatives, les analyses et le redémarrage automatique
• Étape 6 : Automatiser la mise en œuvre dans CI/CD
• FAQ
• Conclusion

Étape 1 : Comprendre ce que contrôle les tentatives minimales

Le pause automatique minimum tentatives value sets the smallest sample Capgo needs before its pause rules can act. It is a gate, not a failure limit. The setting tells Capgo to wait until enough update attempts exist before judging the rollout.

An attempt can include a device trying to install a bundle. The attempt may succeed or fail. The exact outcome depends on the update path, the app state, and the updater configuration. That is why the value should be read with your rollout size in mind.

Capgo’s référence de canal décritauto-pause-min-attemptsas the minimum number of install plus fail attempts before auto-pause can take effect. The field is represented as a string in the CLI reference, so keep the value in the format expected by the command or API you use. You can review the Capgo canal CLI champs avant de modifier un canal en direct.

Pensez à cette configuration comme à une règle de preuve minimale. Une valeur de 1 peut réagir après la première tentative enregistrée. Cela peut aider pendant une petite test interne, mais cela peut également réagir à une session de réseau mauvaise. Une valeur plus élevée donne à la mise à jour plus de temps pour collecter un échantillon utile.

Distinguer les essais des utilisateurs

Les essais ne sont pas les mêmes que les personnes uniques. Un appareil peut réessayer une mise à jour. Un seul utilisateur peut exécuter l'application sur plusieurs appareils. Votre vue d'analyse peut également grouper les événements d'une manière qui diffère de vos propres métriques de produit.

Avant de choisir un nombre, notez ce que vous voulez que le seuil protège. Si l'objectif est de capturer un bundle JavaScript cassé tôt, une petite chaîne contrôlée peut utiliser une valeur plus basse. Si l'objectif est de protéger une large mise en production, vous avez besoin d'assez d'essais pour éviter les décisions basées sur un appareil ou un court arrêt.

• Utilisez un seuil faible pour un canal de test privé.
• Utilisez un seuil plus élevé lorsque le canal a des réseaux et des types d'appareils mixtes.
• Augmentez le seuil si les arrêts courts ont causé des pauses fausses.
• Réduisez-l’uniquement lorsque le coût de la détection tardive est supérieur au coût d'une pause fausse.

La mise en pause automatique doit arrêter une mise à jour. Elle ne doit pas remplacer l'examen du bundle, les tests d'appareil ou un plan de retrait clair. Traitez le seuil comme un contrôl’à l'intérieur de votre processus de mise en production.

Prise de conscience clé : Les essais minimux contrôlent la quantité d'évidence de déploiement que Capgo doit avoir avant que sa politique d'arrêt automatique puisse agir.

Étape 2 : Trouvez la configuration d'arrêt automatique dans Capgo

Pour configurer la Capgo Pour configurer la valeur de minimum tentatives d'arrêt automatique, commencez par trouver le canal qui distribue le bundle. L'arrêt automatique appartient au contrôle de déploiement, donc modifier la configuration de l'actualiseur d'applications peut ne pas modifier la politique du canal que vous attendez.

Commencez par l'interface de dashboard de Capgo ou utilisez la commande de canal et le chemin API que votre équipe utilise déjà. Vérifiez le nom du canal avant de modifier quoi que ce soit. Un canal de test et un canal de production peuvent avoir des noms similaires, et une valeur correcte sur le mauvais canal est toujours un incident de déploiement en attente.

Recherchez les champs d'arrêt automatique dans les paramètres du canal. Les champs liés peuvent inclure la valeur de minimum tentatives et un paramètre de confiance. Gardez ces champs ensemble dans votre revue de changement. Une valeur d'échantillon minimum indique quand Capgo peut juger le déploiement. Un paramètre de confiance peut affecter la force du signal avant qu'un arrêt se produise.

Définissez la valeur à travers le chemin que vous pouvez auditor.

Utilisez l'interface de dashboard lorsque vous avez besoin d'une modification contrôlée rapide et que votre équipe enregistre les modifications de dashboard. Utilisez CLI lorsque la configuration appartient à un script de déploiement. Utilisez l’API public lorsque le service gère la politique du canal comme partie d'un système de déploiement plus large.

Quelle que soit la voie que vous choisissez, capturez d'abord la valeur ancienne. Enregistrez le nom du canal, la version du bundle, l'état de déploiement et la nouvelle valeur dans le même enregistrement de modification. Cela vous donne une réponse claire si le canal s'arrête plus tard.

Pour les workflows API-drivés, Capgo expose les ressources du canal à travers son API public. La documentation du canal Capgo API est le bon endroit pour vérifier les noms de champs et la forme de la demande au lieu de deviner à partir d'un script local.

Lorsque vous modifiez la valeur, entrez un nombre entier complet car le champ s'y attend. N'ajoutez pas de signe de pourcentage. N'utilisez pas de décimal. Si votre outil de gestion des configurations stocke les configurations sous forme de JSON, gardez l'orthographe exacte de la clé et préservez la forme de chaîne affichée dans la référence Capgo actuelle.

Confirmez la modification

Lisez à nouveau le canal après l'avoir enregistré. N'assumez pas que la commande réussie signifie que le champ ciblé a changé. Vérifiez les données de canal renvoyées ou la valeur du tableau de bord.

Posez ensuite trois questions :

• Le paramètre a-t-il changé sur le canal ciblé ?
• Le canal pointe-t-il toujours vers la version de bundle ciblée ?
• Est-ce que le déploiement est actif, arrêté ou terminé ?

Si la valeur ne s'affiche 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 sauvegardé est difficile à faire confiance.

Étape 3 : Choisissez une valeur minimale d'essais sûre

Choisissez la valeur minimale d'arrêt automatique Capgo en fonction de la taille et du risque de la mise en production. Il n'y a pas de nombre sûr pour chaque application. Le bon seuil donne à la politique suffisamment d'évidence tout en détectant une mise à jour défectueuse tôt.

Démarrez avec le groupe le plus petit qui vous donne quelque chose d'utile. Un canal privé peut contenir des appareils internes avec des versions d'applications connues. Un canal de production peut inclure des appareils plus anciens, des connexions faibles et des utilisateurs qui ouvrent l'application seulement 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 vous avez besoin avant que le modèle de failure signifie quelque chose. Si votre canal de test n'a que quelques appareils, un seuil élevé peut ne jamais être atteint pendant la fenêtre de test. Si votre canal de production reçoit de nombreuses tentatives en quelques minutes, un seuil très bas peut arrêter la mise en production après un court problème de réseau.

Fixez une valeur plus basse lorsque :

• Le canal est privé.
• Le paquet modifie une fonctionnalité à haut risque.
• Vous avez besoin de feedback rapide pendant un test étalé.
• Votre équipe peut inspecter chaque échec bientôt après la mise en production.

Fixez une valeur plus élevée lorsque :

• Le canal sert une gamme de dispositifs large.
• Les utilisateurs se connectent via des réseaux instables.
• The app has low daily open frequency.
• Une courte panne peut créer de nombreuses erreurs de faillite.

Ne pas utiliser le seuil pour cacher un problème connu. Si un bundle échoue sur un plugin natif requis, mettez-vous en pause vous-même et corrigez la cause. Un paramètre d'essai minimum ne peut pas rendre un bundle incompatibles sécurisé.

Associez le seuil avec la taille de déploiement

Supposons que vous publiiez dans un petit canal interne en premier. Vous pourriez choisir un seuil qui permet à l'équipe de voir plusieurs résultats d'installation avant que l'auto-mise en pause puisse agir. Une fois que le bundle a franchi cette étape, déplacez-le vers un canal plus large avec un seuil qui reflète l'échantillon plus important.

Cette approche garde le premier signal rapide sans demander à la politique de production de réagir à un échantillon minuscule. Cela vous donne également un endroit clair pour ajuster le paramètre. Modifiez le seuil en fonction du canal, et non après que la mise à jour ait déjà échoué.

Suivez la valeur à côté du registre de la mise à jour. Notez pourquoi vous l'avez choisi, ce qui ferait que vous le changiez, et qui peut approuver ce changement. Cela est important lorsque l'un des membres de l'équipe voit un canal en pause pendant une incidente et a besoin de contexte rapidement.

Conseil Pro : Commencez par un canal contrôlé, enregistrez son volume d'essais, puis ajustez le seuil de production à partir du comportement de déploiement observé plutôt que par conjecture.

Étape 4 : Testez l'arrêt automatique avec un déploiement basé sur un canal

Testez l'arrêt automatique sur un canal avant de vous y fier en production. Un canal vous donne une limite pour le test. Vous pouvez envoyer un bundle à un groupe connu, observer les tentatives augmenter, et confirmer ce qui se passe lorsque la politique atteint son seuil.

Premièrement, créez un bundle de test que vous pouvez identifier sans le confondre avec une mise en production. Gardez le code changement en sécurité. Le test doit prouver que les contrôles de la mise en production fonctionnent, et non créer un problème de deuxième application.

Ensuite, affectez un petit groupe de dispositifs de test au canal. Vérifiez que chaque appareil a la version native d'application attendue. L'OTA code ne peut pas corriger tous les déséquilibres natifs, donc un appareil exécutant le mauvais binaire peut rendre le test difficile à lire.

Publiez le bundle sur le canal. Utilisez une commande dans votre flux de déploiement normal Capgo lorsque possible, mais gardez les IDs du bundle et du canal dans le journal de la mise en production. N'ayez pas confiance dans le tampon de lecture de terminal pendant une incident.

Testez la voie d'arrêt.

Vous avez besoin d'une façon sûre de produire une tentative échouée. Utilisez un bundle de test uniquement ou une condition de failure contrôlée approuvée par votre équipe. N'endommagez jamais un bundle de production juste pour voir si l'arrêt automatique fonctionne.

Observez la séquence suivante :

1. Le canal pointe vers le bundle de test.
2. Les appareils reçoivent l'instruction d'actualisation.
3. Les tentatives apparaissent dans la vue d'analyse.
4. Le nombre minimal de tentatives est atteint.
5. Le signal de failure cause le canal à s'arrêter, si les conditions de la politique sont remplies.

L'étape cinquième est importante. Le franchissement de la valeur des tentatives minimales peut rendre l'auto-arrêt éligible. Cela ne signifie pas que chaque déploiement s'arrête à ce comptage exact. D'autres champs de politique et les résultats observés peuvent affecter le résultat.

Testez également la récupération

Après l'arrêt, confirmez ce que les utilisateurs reçoivent. Vérifiez si le bundle échoué reste sélectionné, si de nouveaux appareils cessent de le recevoir et si le bundle précédent sûr est disponible pour le rollback. La réponse dépend de votre configuration de mise à jour et de canal, vérifiez donc plutôt que d'assumer.

Reprenez ensuite avec un bundle connu pour être bon uniquement après que quelqu'un ait examiné la défaillance. Si la défaillance venait d'une mauvaise construction, créez un nouveau bundle. N'envoyez pas simplement le même artefact à nouveau et espérez que la prochaine tentative se comporte différemment.

Documentez le résultat du test. Incluez le seuil, le nombre de dispositifs, la condition de défaillance, la durée de l'arrêt et l'action de récupération. Cela transforme un test unique en vérification de mise en production répétitive.

Étape 5 : Surveiller les tentatives, les analyses et le redémarrage automatique

Monitoring tells you whether the Capgo auto pause minimum attempts rule is seeing a healthy rollout or a broken one. Watch the attempt count beside failure behavior. A count without context can lead you to pause too early or miss a growing issue.

Utilisez Capgo Observe pour inspecter l'activité de mise à jour et l'état de déploiement. Capgo Observez la documentation explique la zone utilisée pour afficher les informations d'actualisation et configurer le comportement d'arrêt automatique. Gardez l'interface de dashboard ouverte pendant la première partie d'une mise à jour, surtout lorsque le bundle change la code ou un flux d'application de base.

Lisez les signaux ensemble

Regardez d'abord le total des tentatives. Ensuite, vérifiez le nombre de failures et le modèle de temps. Un flux continu de réussites d'installation ressemble différemment à une explosion de failures après qu'un bundle devient actif.

Vérifiez les détails du dispositif et de la version de l'application lorsque disponibles. Si les failures se concentrent sur une version native, le bundle OTA peut nécessiter un code binaire plus récent. Si les failures apparaissent sur toutes les versions, inspectez le bundle lui-même ou le chemin de service d'actualisation.

Les pannes de réseau peuvent créer du bruit. Une courte panne peut produire des tentatives échouées sans un code défaut. C'est pourquoi le seuil devrait fonctionner avec une politique de confiance et un processus de revue humain. L'arrêt automatique peut arrêter l'exposition, mais il ne peut pas expliquer chaque failure.

Sachez ce que signifie l'annulation dans votre flux

Une annulation déplace les utilisateurs affectés vers une mise à jour connue comme bonne ou arrête la mauvaise mise à jour de parvenir à plus de dispositifs. Elle ne répare pas un code binaire natif qui manque d'une capacité requise. Elle ne peut pas non plus annuler une migration de données que le bundle OTA a déjà exécuté.

Avant d'utiliser en production, confirmez le chemin de roulage avec un canal de test. Vérifiez quel bundle est considéré comme sûr. Vérifiez ce qui se passe lorsque le dispositif est hors ligne pendant la pause. Écrivez ensuite les étapes de récupération où l'ingénieur de secours peut les trouver.

Capgo’s la documentation de roulage peut vous aider à mapper les contrôles de roulage disponibles à votre plan de canal. Utilisez le comportement documenté comme référence, puisque le résultat peut dépendre de la version de l'actualiseur et de la configuration de publication.

Lors d'une incident, pausez d'abord si le modèle de failure est clair. Ensuite, inspectez les journaux et les modifications de bundle. Quelques minutes passées à arrêter l'exposition sont généralement plus faciles à gérer que de laisser une publication connue pour être mauvaise continuer à se propager.

Étape 6 : Automatiser la mise en place dans CI/CD

Put the Capgo auto pause minimum attempts value in your release workflow when the setting changes with each channel. Automation removes manual drift. It also makes the chosen threshold visible in code review.

Keep channel policy separate from secrets. The channel name, rollout stage, and minimum attempts value can live in versioned configuration. API tokens must stay in your CI/CD secret store. Never commit a token to a repository just because the channel setting is already there.

Une tâche de publication devrait suivre un ordre clair :

1. Construirez le bundle web.
2. Une tâche de publication doit suivre un ordre clair :
3. Construirez le bundle web.
4. Configurez ou confirmez le canal cible.
5. Appliquez la valeur d'essais minimale.
6. Vérifiez l'état du canal sauvegardé.
7. Publiez ou avancez la mise à jour.

Utilisez une étape de simulation ou de revue si votre système de déploiement le supporte. La revue devrait afficher l'identifiant du bundle, le canal, le seuil et l'action de mise à jour avant que l'étape de production ne soit exécutée.

Faites de la vérification une partie du travail.

Après l'exécution de la commande API ou CLI, récupérez à nouveau l'état du canal. Faites fail le travail si la valeur retournée ne correspond pas à la configuration attendue. Cela permet de capturer les IDs de canal incorrects, les champs rejetés et les mises à jour partielles.

Les variables d'environnement sont une façon courante de passer les paramètres de mise en production dans un travail CI. Le travail peut lire un nom de canal ou un seuil sans placer les secrets dans les fichiers source. Gardez les noms de variables clairs et les validez avant le déploiement.

Par exemple, votre workflow pourrait exiger :

• CAPGO_CHANNELpour le canal cible.
• CAPGO_MIN_ATTEMPTSpour le seuil approuvé.
• CAPGO_BUNDLE_IDpour le bundle téléchargé.

Ces noms sont des conventions de workflow et non des noms de champs Capgo. Cartez-les sur les champs exacts CLI ou API dans un seul endroit. Cela facilite les futures modifications.

Pour une vérification de sécurité plus approfondie, consultez les conseils de Capgo sur la sécurisation des mises à jour OTA dans les pipelines CI/CD. L'habitude importante est simple : limitez l'accès aux jetons, enregistrez la décision de mise à jour et vérifiez le résultat après chaque modification.

Conservation d'un registre de modification

Enregistrez le seuil avec l'ID de commit ou de mise à jour. Ajoutez la raison de la modification. Si une mise à jour est interrompue inopinément, vous pouvez comparer la politique avec le bundle et l'heure de déploiement.

Capgo est facturé comme une souscription par organisation, avec une période d'essai de 14 jours plutôt qu'une vente en ligne unique. Ce modèle convient aux équipes qui souhaitent tester le flux de mise à jour avant de l'intégrer à leur processus de livraison régulier. Concentrez-vous sur l'essai : configurez un canal, exécutez une test de pause et vérifiez un chemin de reversion.

Une commande peut publier la mise à jour. Le workflow plus sûr est celui qui vérifie également le canal, suit l'adoption et laisse un chemin de reversion.

FAQ

Qu'est-ce que Capgo auto pause minimum attempts signifie ?

Capgo auto pause minimum attempts détermine le nombre minimum d'installations et d'échecs nécessaires avant que la politique de pause automatique puisse agir. Il s'agit d'une barrière d'échantillon, et non d'un pourcentage d'installations échouées. Une valeur faible réagit plus tôt mais peut se baser sur moins d'éléments de preuve. Une valeur plus élevée donne au canal plus de temps pour collecter les résultats.

Où configurez-vous les essais de pause automatique minimum dans Capgo ?

Vous définissez la valeur sur le canal qui distribue le bundle OTA. Utilisez le tableau de bord Capgo, CLI, ou public API, puis lisez à nouveau le canal pour confirmer le champ enregistré. Vérifiez le nom du canal en premier lieu. La modification d'un canal de test lorsqu'il est actif en production ne changera pas la mise en production.

Quel est la valeur minimale d'essais sûre ?

Une valeur sûre dépend de la taille du canal, du mélange de dispositifs, de la qualité du réseau et du risque de mise en production. Utilisez une plus petite limite pour un canal de test contrôlé. Utilisez une plus grande limite pour une mise en production large. Commencez par un groupe connu, observez son volume d'essais et ajustez en fonction du comportement observé.

La valeur minimale d'essais atteint-elle toujours un arrêt de la mise en production ?

Non. L'atteinte de la valeur minimale d'essais Capgo rend la mise en production éligible à l'arrêt automatique, mais d'autres conditions de politique sont encore pertinentes. Les signaux de défaillance, les paramètres de confiance, l'état du canal et le flux de mise à jour peuvent affecter le résultat. Testez la voie complète d'arrêt avec un bundle sûr avant de vous fier à elle en production.

L'arrêt automatique peut-il remplacer un plan de retrait ?

Non. L'arrêt automatique arrête ou limite davantage l'exposition, tandis que le retrait vers le haut amène les utilisateurs vers un bundle connu lorsqu'il est disponible. Testez les deux contrôles. N'oubliez pas également que le retrait OTA ne peut pas ajouter une capacité native qui n'est pas présente dans l'application installée.

Conclusion

Fixez la valeur minimale d'essais par canal, et non par habitude. Commencez par une petite mise en production de test, vérifiez les chemins d'arrêt et de reprise, puis automatisez la mise en œuvre approuvée dans CI/CD. Si vous souhaitez tester le flux de travail, essayez Capgo avec un canal et un bundle contrôlé avant de l'élargir à la mise en production.