Un seuil d'essais bas peut suspendre une mise à jour OTA saine. Un seuil élevé peut laisser un bundle défectueux atteindre trop de dispositifs. Le Capgo 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.
Tableau de Contenu
- La mise en pause automatique minimum essais
- Étape 2 : Trouvez la configuration d'arrêt automatique dans Capgo
- La mise en pause automatique minimum tentatives
- La mise en pause automatique minimum essais
- La mise en pause automatique minimum tentatives
- La mise en pause automatique minimum essais
- FAQ
- Conclusion
Étape 1 : Comprendre ce que contrôle les tentatives minimales
L' 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.
La référence du canal de Capgo 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 canal Capgo champs CLI avant de changer un canal en direct.
Think of the setting as a minimum evidence rule. A value of 1 may react after the first recorded attempt. That can help during a very small internal test, but it can also react to one bad network session. A larger value gives the rollout more time to collect a useful sample.
Essais distincts des utilisateurs
Les tentatives 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 endommagé 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 de tentatives pour éviter les décisions basées sur un appareil ou un court arrêt.
- Utilisez un seuil faible pour une chaîne de test privée.
- Utilisez un seuil plus élevé lorsque la chaîne a des réseaux et des types d'appareils mixtes.
- Augmentez le seuil si les courts arrêts 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 pause automatique doit arrêter un déploiement. Elle ne doit pas remplacer la revue 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.
Prendre en compte clé : Les essais minimums déterminent le montant d'évidence de déploiement que Capgo doit avoir avant que sa politique d'arrêt automatique puisse agir.
Étape 2 : Trouvez la mise en pause automatique dans Capgo
Pour configurer la Capgo Trouvez d'abord le canal qui distribue le bundle. L'arrêt automatique appartient au contrôle de déploiement, donc la modification de la configuration de l'actualiseur de l'application peut ne pas modifier la politique du canal que vous attendez.
Commencez dans le tableau de bord 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 mise en production en attente.
Recherchez les champs d'arrêt automatique dans les paramètres du canal. Les champs liés peuvent inclure la valeur minimale d'essais et un paramètre de confiance. Gardez ces champs ensemble dans votre revue de changement. Une valeur d'échantillon minimale indique quand Capgo peut juger le déploiement. Une valeur 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.
Use the dashboard when you need a quick controlled change and your team records dashboard changes. Use the CLI when the setting belongs in a release script. Use the public API when a service manages channel policy as part of a wider deployment system.
Quel que soit le chemin que vous choisissez, capturez la valeur ancienne en premier. Enregistrez le nom du canal, la version du bundle, l'état de déploiement et la nouvelle valeur dans le même enregistrement de changement. 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 public API. Capgo canal API documentation 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 développement stocke la configuration sous forme de JSON, maintenez l'orthographe exacte de la clé et préservez la forme de chaîne affichée dans la référence actuelle Capgo.
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 du canal retournées ou la valeur de la console.
Posez ensuite trois questions :
- Le paramètre a-t-il changé sur le canal ciblé ?
- Le canal pointe-t-il toujours vers le bundle ciblé ?
- La mise à jour est-elle active, en pause ou terminée ?
S'il n'y a pas de valeur, arrêtez 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 d'essais minimum sûre
Choose the Capgo auto pause minimum attempts value from the size and risk of the rollout. There is no safe number for every app. The right threshold gives the policy enough evidence while still detecting a bad update early.
Commencez par le groupe le plus petit qui vous permet d'obtenir des informations utiles. 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 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 nombreux essais en quelques minutes, un seuil très bas peut suspendre la mise en production après un court problème de réseau.
Fixe une valeur plus basse lorsque :
- Fixez une valeur plus basse lorsque :
- Ce bundle modifie une fonctionnalité à risque élevé.
- Le paquet modifie une fonctionnalité à haut risque.
- Vous avez besoin de feedback rapide pendant un test étalé.
Fixe un plus grand nombre lorsque :
- Fixez une valeur plus élevée lorsque :
- Le canal sert une gamme large d'appareils.
- The app has low daily open frequency.
- A une courte panne pourrait créer de nombreuses fausses échecs.
Ne pas utiliser le seuil pour cacher un problème connu. Si un bundle échoue sur un plugin natif requis, mettez-vous en pause et corrigez la cause. Un minimum d'essais ne peut pas rendre un bundle incompatibles sécurisé.
Associez le seuil avec la taille de déploiement
Supposons que vous déployiez 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-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 la mise en œuvre. Modifiez le seuil avec le canal, et non après que la mise à jour a 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 compte lorsque l'un des membres de l'équipe voit un canal en pause pendant une incident 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
context : Page/zone : Page d'informations sur Capgo. Rôle : Étiquette de l'IHM. Vu dans : page sur .astro. Clé de message `about_how_step_label` (Étape de l'about Comment ça marche).
Premièrement, créez un bundle de test que vous pouvez identifier sans le confondre avec une mise en production. Gardez la modification code en sécurité. Le test doit prouver les contrôles de la mise en production, 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. Le code OTA ne peut pas corriger tous les désaccords de version native, donc un appareil exécutant la mauvaise version peut rendre le test difficile à lire.
Publiez le bundle au canal. Utilisez une commande dans votre flux de déploiement normal Capgo chaque fois que possible, mais gardez les identifiants du bundle et du canal dans le journal de la mise en production. N'ayez pas confiance dans le tampon de la fenêtre de terminal pendant une incident.
Testez le chemin d'arrêt.
Vous avez besoin d'une méthode sécurisée pour produire un essai raté. Utilisez un bundle de test uniquement ou une condition de failure contrôlée approuvée par votre équipe. Ne jamais endommager un bundle de production juste pour voir si l'auto-arrêt fonctionne.
Regardez la séquence suivante :
- Le canal pointe vers le bundle de test.
- Les appareils reçoivent l'instruction d'actualisation.
- Les tentatives apparaissent dans la vue d'analyse.
- La valeur minimale de tentative est atteinte.
- Le signal de failure cause le canal à s'arrêter, si les conditions de politique sont remplies.
La cinquième étape est importante. Atteindre la valeur minimale de tentative peut rendre l'auto-arrêt éligible. Cela ne signifie pas que chaque déploiement s'arrête à ce compteur exact. D'autres champs de politique et les résultats observés peuvent affecter le résultat.
Testez la récupération également
Après la pause, confirmez ce que les utilisateurs reçoivent. Vérifiez si le bundle échoué reste sélectionné, si les 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 mise en place de l'actualisation et du canal, vérifiez donc plutôt que d'assumer.
Reprenez ensuite avec un bundle connu avec succès uniquement après que quelqu'un ait examiné l'échec. Si l'échec 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 de la test. Incluez le seuil, le nombre de dispositifs, la condition d'échec, la durée de la pause et l'action de récupération. Cela transforme une test unique en vérification de mise en production répétable.
Étape 5 : Surveiller les tentatives, les analyses et le redémarrage automatique
Surveiller permet de savoir si la règle de pause automatique minimum de tentatives de Capgo voit une mise en production saine ou une mise en production brisée. Regardez le comptage de tentatives à côté du comportement d'échec. Un comptage sans contexte peut vous faire vous arrêter trop tôt ou manquer une question en croissance.
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 visualiser les informations d'actualisation et configurer le comportement de pause automatique. Gardez l'interface de dashboard ouverte pendant la première partie d'une mise en production, surtout lorsque le bundle change la mise en route code ou un flux d'application principal.
Lisez les signaux ensemble
Regardez d'abord le total d'essais. 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 seule version native, le bundle OTA peut nécessiter une version binaire plus récente. Si les failures apparaissent sur toutes les versions, inspectez le bundle lui-même ou le chemin de mise à jour.
Les failures de réseau peuvent créer du bruit. Une courte panne peut produire des essais échoués sans défaut code. C'est pourquoi le seuil doit fonctionner avec une politique de confiance et un processus de revue humaine. L'arrêt automatique peut stopper l'exposition, mais il ne peut pas expliquer chaque failure.
Connaître l'impact d'une annulation dans votre flux
Un rollback déplace les utilisateurs affectés vers une version connue et bonne ou arrête la mauvaise version de parvenir à plus de dispositifs. Il ne répare pas un fichier binaire natif qui manque d'une capacité requise. Il ne peut pas non plus annuler une migration de données qui a déjà été exécutée par un bundle OTA.
Avant d'utiliser en production, confirmez le chemin de rollback 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 permanence peut les trouver.
Capgo’s documentation de reversion can help you map the available rollback controls to your channel plan. Use the documented behavior as your reference, since the result can depend on the updater version and release setup.
Durant une incident, arrêtez d'abord si le modèle de failure est clair. Ensuite, inspectez les journaux et les modifications de bundle. Une poignée de minutes passées à arrêter l'exposition est généralement plus facile à gérer que de laisser une version 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.
Conservez la politique du canal séparée des secrets. Le nom du canal, l'étape de déploiement et la valeur de tentatives minimales peuvent vivre dans une configuration versionnée. Les jetons API doivent rester dans votre magasin de secrets CI/CD. N'enregistrez jamais un jeton dans un dépôt juste parce que la mise en place du canal est déjà là.
Une tâche de publication doit suivre un ordre clair :
- Construire le bundle web.
- Exécuter les tests et vérifier la compatibilité native.
- Télécharger le bundle.
- Définir ou confirmer le canal cible.
- Appliquer la valeur de tentatives minimales.
- Vérifier l'état du canal sauvegardé.
- Publier ou avancer le déploiement.
Utilisez une étape de test ou de revue si votre système de déploiement le supporte. La revue doit afficher l'identifiant du bundle, le canal, le seuil et l'action de déploiement avant que l'étape de production ne soit exécutée.
Intégrez la vérification dans le job
Après la commande API ou CLI, récupérez à nouveau l'état du canal. Faites fail le job si la valeur retournée ne correspond pas à la configuration attendue. Cela permet de capturer les mauvaises ID de canal, 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 job CI. Le job peut lire le nom du canal ou le 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, pas des noms de champs Capgo. Cartez-les aux 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 : restreignez l'accès au jeton, enregistrez la décision de mise en production et vérifiez le résultat après chaque modification.
Conservation d'un registre de changement
Enregistrez le seuil avec l'ID de commit ou de release. Ajoutez la raison du changement. Si une mise en production s'arrête inattendement, vous pouvez comparer la politique avec le bundle et l'heure de déploiement.
Capgo est facturé en tant que 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. Gardez le travail d'essai ciblé : 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
What does Capgo auto pause minimum attempts mean?
Capgo auto pause minimum attempts sets the minimum install and failure attempts needed before the auto-pause policy can act. It is a sample-size gate, not a percentage of failed installs. A low value reacts sooner but may rely on less evidence. A higher value gives the channel more time to collect results.
Qu'est-ce que Capgo auto pause minimum attempts signifie ?
You set the value on the channel that delivers the OTA bundle. Use the Capgo dashboard, CLI, or public API, then read the channel back to confirm the saved field. Check the channel name first. Editing a test channel when production is active will not change the production rollout.
Quel est la valeur d'essais minimale sûre ?
Vous configurez la valeur sur le canal qui délivre le bundle OTA. Utilisez l'interface de dashboard __CAPGO_KEEP_0__, __CAPGO_KEEP_1__, ou public __CAPGO_KEEP_2__, puis lisez le canal à nouveau pour confirmer le champ sauvegardé. Vérifiez d'abord le nom du canal. La modification d'un canal de test lorsqu'il est actif en production ne changera pas la mise en production de la production.
Est-ce que la valeur minimale d'essais arrête toujours une mise à jour ?
Non. Atteindre la valeur minimale d'essais Capgo rend la mise à jour é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 le chemin d'arrêt complet avec un bundle sûr avant de vous fier à lui en production.
L'arrêt automatique peut-il remplacer un plan de reprise ?
Non. L'arrêt automatique arrête ou limite davantage l'exposition, tandis que la reprise de mise à jour déplace les utilisateurs vers un bundle connu lorsqu'il est disponible. Testez les deux contrôles. N'oubliez pas également que la reprise de mise à jour 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 mise à jour de test petite, vérifiez les chemins d'arrêt et de reprise, puis automatisez la mise en place 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 à jour.
