Une pause arrête une mise à jour de plus en plus de dispositifs. Un rollback amène les dispositifs affectés vers une version connue et bonne. Capgo supporte les deux, vous pouvez donc contenir un problème en premier et décider de la suite à suivre.
Utilisez ces étapes pour choisir l'action appropriée, vérifier son effet et réduire la chance de répéter l'incident.
We read 6 public guides on staged rollouts and rollback published by Google Play, Amazon Appstore, Microsoft’s CodePush, Bitrise, Nearform, and Digia. Four of the 6 separate pausing from rolling back as distinct actions, while 2 skip rollback or treat pause as the only lever. None of the 6 explain how to verify recovery with analytics or device checks, and none describe a workflow for preventing repeat incidents. Getting the pause-versus-rollback choice right, then confirming it worked, closes a gap left open across public release guidance.
Tableau de Contenu
- Étape 1 : Configurez les contrôles de version dans Capgo
- Étape 2 : Choisissez de suspendre ou de remonter en arrière
- Étape 3 : Mettre fin à la diffusion pour investiguer
- Step 4: Roll back when users need a stable version
- Vérifiez la récupération avec les analyses et les vérifications de l'appareil
- Prévenir les incidents répétitifs avec des flux de mise à jour plus sûrs
- FAQ
- Conclusion
Étape 1 : Configurez les contrôles de version dans Capgo
Avant un incident, assurez-vous que votre équipe connaît le canal qui délivre la mise à jour et le paquet stable. Un canal est une voie nommée qui dirige les appareils d'applications vers une mise à jour. Un paquet est la mise à jour web code envoyée à travers cette voie.
Dans Capgo, une mise à jour progressive peut conserver un paquet stable en place tout en envoyant un cible de mise à jour séparée à un groupe sélectionné. Cela vous donne un point de contrôl’avant que le nouveau paquet ne rejoigne la base d'utilisateurs plus large. Examinez les contrôles de mise à jour progressive avant de les activer en production. avant de l'activer en production.
Une mise à jour OTA modifie la mise à jour web __CAPGO_KEEP_0__ de l'application par voie aérienne. Elle ne remplace pas le code natif de l'application installé à partir d'une boutique d'applications. Le terme mise à jour par voie aérienne décrit cette approche de livraison. Gardez à l'esprit cette frontière : si une correction nécessite un nouveau plugin natif ou une modification de la configuration native de l'application, un roulage de paquet ne le fournira pas.
An OTA update changes the app’s updateable code over the air. It doesn’t replace the native app binary installed from an app store. The term over-the-air update describes this delivery approach. Keep this boundary in mind: if a fix needs a new native plugin or a change to the app’s native setup, a bundle rollback won’t supply it.
Avant la mise en production, confirmez que le bundle stable est celui que vous attendez. Vérifiez le nom du canal, le bundle cible et l'état de déploiement. Une faute d'orthographe dans un nom de canal ou un bundle obsolète peuvent envoyer les répondeurs vers le contrôl’incorrect lorsqu'il s'agit de minutes précieuses.
À ce stade, vous devriez avoir un propriétaire de version nommé, un bundle connu pour être bon et une condition d'arrêt écrite. Cette préparation transforme la prochaine décision en un choix opérationnel, et non en un chaos dans le tableau de bord.
Rappel clé : Une pause limite la nouvelle exposition. Un rollback change la version auxquels les utilisateurs sont dirigés.
Étape 2 : Choisissez de suspendre ou de remonter en arrière
For the Capgo pause rollout vs rollback decision, ask one question first: are you trying to stop more devices from getting the target, or move devices off a target that’s already causing harm? A pause limits new exposure. A rollback clears the target and returns devices to the stable fallback on their next update check.
Choose pause when evidence is incomplete or the issue appears limited. You may have a handful of reports but not know whether the bug affects one device type, a particular user flow, or every updated device. Pausing gives the team room to inspect the signal without adding new devices to the rollout group.
Choisissez le roulé-back lorsque la cible est clairement dangereuse pour les utilisateurs, ou lorsque l'équipe dispose de suffisamment d'éléments pour prouver que le bundle connu est plus sûr. Un arrêt seul ne supprime pas la cible nocive des appareils déjà dans le groupe de déploiement. Si ces utilisateurs doivent revenir à la version stable, le roulé-back est l'action qui modifie leur chemin d'actualisation.
Le Capgo canal CLI de référence contrôles de pause et de reversion séparés. Les considérez comme des actions distinctes, et non comme deux noms pour le même arrêt d'urgence.
| Ce que vous voyez | Première action | Qu'est-ce à vérifier ensuite |
|---|---|---|
| Ce à quoi vous devez vérifier ensuite | Erreurs précoces, champ d'application incertain | Comparez les appareils touchés et non touchés |
| Comparez les appareils affectés et non affectés | Annuler la mise à jour ciblée | Confirmer que le bundle stable est activé |
| Problème lié à une code native ou un service | Arrêtez ou contenez la mise à jour de l'application, puis corrigez la couche affectée. | Vérifier si une mise à jour native ou une réparation de service est nécessaire |
| Seulement un petit groupe a pour cible, sans impact utilisateur confirmé | Mettre en pause pendant l'enquête | Resume only after the release owner approves |
Un rollback ne réparera pas une panne de backend, et il ne peut pas ajouter une capacité native manquante. Identifiez d'abord la couche qui a échoué. Si le bundle web est à l'origine du problème, choisissez entre mettre en pause et rétablir en fonction du nombre d'utilisateurs qui ont besoin d'aide.
Étape 3 : Arrêtez l'exposition pour poursuivre l'enquête
Mettre en pause lorsque vous avez besoin d'arrêter de nouveaux appareils d'entrer dans le groupe de lancement mais n'êtes pas prêt à rétablir la cible pour les appareils déjà dans celui-ci. C'est une étape de contenance. Cela achète du temps pour vérifier les faits tout en empêchant la diffusion de l'incident vers plus d'utilisateurs.
Ouvrez le canal de production et vérifiez que vous agissez sur la mise en lancement affectée. Mettez-l’en pause avec le tableau de bord, CLI, ou API contrôlez votre équipe utilise. Lisez ensuite l'état du canal. N'attendez pas uniquement que la commande se termine avec succès ; confirmez que la mise en lancement montre maintenant comme étant en pause.
In Capgo’s modèle de lancement progressif, les appareils déjà dans le groupe peuvent rester sur la cible de lancement après une pause. Les nouveaux appareils éligibles reçoivent la version stable par défaut lors de leur prochaine vérification. Cette distinction compte : la pause arrête la nouvelle entrée, mais elle n'a pas elle-même déplacé le groupe existant vers la version stable.
Ensuite, capturez les détails de la mise en production avant de faire une autre modification. Enregistrez la version de bundle cible, le canal, l'heure de la pause et le premier rapport connu. Gardez les détails de l'appareil ou de la session que votre équipe est autorisée à collecter. Un calendrier clair vous aide à comparer le groupe de lancement avec les appareils toujours sur la version stable.
Vérifiez le problème à travers un chemin répétable. Si les utilisateurs signalent un échec de connexion, testez ce parcours exact sur un appareil affecté. Si l'application s'effondre lors du lancement, vérifiez si la panne est alignée avec la nouvelle version de bundle et l'application native. Évitez de traiter chaque rapport de support comme preuve que la mise à jour a causé le problème.
Fixez un propriétaire et une date de décision pour l'enquête. Une lancement en pause peut rester en suspens si personne ne possède le prochain mouvement. Le propriétaire devrait soit reprendre après que les preuves aient clairement éclairci la mise en production, soit choisir le retrait lorsque la cible reste dangereuse.
Conseil Pro : Alertez le support et l'équipe de mise en production que la lancement est en pause. Sinon, un groupe peut continuer à faire monter les rapports tandis que l'autre suppose que la lancement a déjà été annulé.
À ce stade, les nouveaux appareils ne devraient plus entrer dans le groupe de déploiement. Vérifiez l'état du canal et le comportement d'un appareil qui n'était pas dans le groupe avant de passer à la mise à l'arrêt ou de reprendre.
Step 4: Roll back when users need a stable version
Revenir en arrière lorsque les utilisateurs déjà sur la version cible doivent se déplacer vers une version connue et bonne. C'est une réponse plus forte que la mise à l'arrêt. Cela change ce que le canal sert, vérifiez donc la version stable sélectionnée avant de confirmer l'action.
In Capgo, ouvrez le canal affecté et passez en revue son historique de build. Choisissez la version que vous souhaitez restaurer, puis confirmez qu'il s'agit de la bonne version stable pour cette application et ce canal. Capgo’s documentation de reversion La prochaine fois que les appareils vérifient une mise à jour, ils recevront la version sélectionnée.
Après la mise à l'arrêt, ne supposez pas que tous les appareils aient changé en même temps. Un appareil doit vérifier une mise à jour, et un utilisateur hors ligne peut ne pas le faire jusqu'à plus tard. Gardez l'incident ouvert jusqu'à ce que vous ayez vérifié la version active du canal et testé le chemin de récupération sur un appareil dans le groupe affecté.
Utilisez uniquement le bundle intégré lorsque c'est le cible de récupération intentionnelle. Il redirige les appareils vers la build web encapsulée dans l'application native, qui peut différer de la dernière version OTA. Vérifiez la compatibilité et l'impact utilisateur avant de choisir cela comme étape de récupération.
Conservez le bundle responsable de l'incident pour analyse, à moins que votre processus de conservation ne le sache autrement. L'ID de la mise en production et le commit aident les ingénieurs à comparer la modification avec la version stable. Préservez les journaux pertinents avant la suppression, surtout si vous devez comprendre pourquoi le problème a échappé aux tests.
La régression n'est pas la bonne solution pour chaque échec. Si la cause racine est une dépendance côté serveur, réparez ce service. Si la modification dépend d'une code native absente des binaires installés, préparez une build native et suivez la voie de publication de l'application pour cette modification.
Vérifiez la récupération avec les analyses et les vérifications de l'appareil
Après une pause ou une régression, vérifiez ce que les appareils font plutôt que de considérer le changement de contrôle comme preuve de récupération. Vérifiez l'état de la chaîne active en premier. Comparez ensuite l'adoption des mises à jour, les erreurs et les rapports de dispositif entre la version affectée et la version stable.
Les signaux d'Capgo’s live update analytics peuvent vous aider à inspecter les métriques d'adoption, les taux d'erreur et les journaux de niveau de dispositif. Utilisez ces signaux pour répondre à des questions spécifiques : les nouveaux appareils reçoivent-ils toujours la cible, les appareils affectés vérifient-ils la bundle stable, et a-t-on arrêté le problème après la récupération ?
Testez le chemin d'utilisateur qui a échoué. Un téléchargement réussi ne prouve pas que l'application fonctionne. Ouvrez l'écran pertinent, répétez l'action qui a conduit au rapport et vérifiez si l'application atteint l'état attendu. Si l'incident implique un flux critique, faites confirmer le résultat par quelqu'un d'autre que la personne qui a effectué la mise à jour.
Comparez les choses avec les choses. Un comptage d'erreurs large peut augmenter pour des raisons non liées à la mise à jour, telles qu'une problème de service ou une modification du trafic. Filtrez par paquet, canal, version de l'application et appareil lorsque ces champs sont disponibles. Cherchez une différence liée à la mise à jour plutôt que de blâmer la mise à jour la plus récente par défaut.
Vérifiez également les utilisateurs qui n'ont pas mis à jour. Leur présence peut rendre les métriques globales saines tout en laissant le groupe affecté voir le bug. Suivez la part de dispositifs sur la cible par rapport à la part sur stable, et gardez les rapports de support liés à la version que les utilisateurs utilisent réellement.
Notez le résultat de la récupération et l’incertitude restante. Si les erreurs diminuent mais quelques utilisateurs signalent toujours le même problème, n'aboutez pas l'incident jusqu'à ce que vous compreniez si ils sont hors ligne, sur une ancienne coquille native ou toujours utilisent le paquet affecté.
La récupération est confirmée lorsque le canal pointe vers la version prévue et le chemin d'utilisateur qui a échoué fonctionne sur un appareil capable de reproduire l'incident. Les métriques vous aident à voir la forme du problème ; une vérification de l'appareil confirme ce que l'utilisateur expérimente.
Étape 6 : Prévenir les incidents répétitifs avec des flux de lancement plus sûrs
Intégrez la pause et le rollback dans le plan de publication avant de publier. Le propriétaire de la publication devrait savoir qui peut arrêter l'exposition et qui peut approuver un retour à l'état stable. Cela élimine un retard fréquent : attendre une réunion pendant que plus de dispositifs entrent dans le déploiement.
Assignez une version stable en tant que fallback pendant que le cible de déploiement est testée. Utilisez une petite cohorte définie en premier, puis élargissez uniquement lorsque les signaux de santé convenus restent dans vos limites. Capgo prend en charge le contrôle de la version par canal, de sorte que les équipes puissent séparer les tests de la livraison de production large.
Placez les contrôles de publication dans CI/CD, le processus automatisé qui exécute les tests et déploie une modification. Une pipeline peut publier le bundle dans le canal ciblé après que les tests passent. Il devrait également échouer en toute sécurité si le canal est incorrect ou si la version n'est pas prête pour la promotion.
Un flux de livraison continue garde l'application prête à la publication à travers un processus automatisé. Pour un workflow OTA, gardez le point d'approbation humaine clair même lorsque la publication est automatisée. L'automatisation devrait rendre l'action choisie répétable, et non prendre la décision pour une modification non revue.
Avec Capgo, un déploiement à commande unique peut publier un bundle dans un canal. Gardez la commande dans le même processus de publication que vos contrôles, et faites visible le canal cible dans le registre de déploiement. Cela aide l'ingénieur en charge de la permanence à voir exactement ce qui a été déployé sans deviner dans quelle voie il l'a reçu.
Avant de mettre en place des mesures de sécurité automatiques, définissez quel signal les déclenche et quelle action elles prennent. Une pause peut arrêter la nouvelle exposition tout en gardant les appareils de la cohorte actuelle sur la cible. Un rollback peut diriger les appareils vers la stabilité. Ces résultats diffèrent, ne configurez donc pas l'un comme l'autre.
Utilisez un canal de test pour répéter la réponse complète. Publiez une modification sans danger, vérifiez le contrôle de pause et testez ensuite le rollback vers le bundle précédent. Confirmez le comportement de l'application sur un appareil après chaque action. Un livre de run devrait inclure le canal, la commande ou le chemin de tableau de bord, l'état attendu et la personne qui confirme le succès.
Les notes de version devraient identifier le bundle et sa finalité. Gardez un lien entre le registre de déploiement et le changement source afin que les ingénieurs puissent restreindre la recherche lors d'une erreur. Si votre équipe transmet des incidents à travers les fuseaux horaires, incluez la dernière action effectuée et le prochain propriétaire de décision.
Si l'incident pointe vers une bouteille d'embouteillage plus large de l'implémentation front-end, un développeur web tel que Amir Arezoo Peut être pertinent pour le développement web. Cela est séparé des contrôles de mise en production de Capgo qui gèrent la livraison et la récupération pour les mises à jour d'applications compatibles.
À ce stade, votre chemin de mise en production devrait inclure un fallback stable, un propriétaire, une règle d'arrêt et une action de récupération testée. Gardez le flux de travail court enough pour que l'ingénieur en charge puisse l'utiliser sous pression.
FAQ
Does pausing a Capgo rollout roll back devices already updated?
Non. L'arrêt pause empêche de nouveaux appareils éligibles d'entrer dans le déploiement, mais les appareils déjà dans le groupe peuvent rester sur le bundle cible. Pour faire revenir ces utilisateurs vers stable, utilisez le rollback ou une autre action délibérée du canal. Vérifiez l'état du canal après l'une ou l'autre modification, puis confirmez le résultat sur un appareil qui a reçu le cible.
Quand devrais-je arrêter plutôt que de faire remonter ?
Pause when the issue is still under investigation and you need to stop wider exposure. Roll back when the target is known to harm users or when affected devices need a stable bundle. The Capgo pause rollout vs rollback choice depends on whether the immediate need is containment or recovery for the existing cohort.
Un rollback met-il à jour tous les appareils immédiatement ?
Non. Un rollback change le bundle auquel le canal pointe, mais les appareils le reçoivent lorsqu'ils vérifient à nouveau une mise à jour. Un appareil hors ligne peut rester sur son bundle actuel jusqu'à ce qu'il se reconnecte. Vérifiez la cible du canal, puis vérifiez les appareils affectés et leur statut de mise à jour avant de déclarer l'incident résolu.
Un rollback OTA peut-il résoudre un problème d'application native ?
No. An OTA rollback can restore an earlier updateable web bundle, but it can’t add or remove native code inside an installed app binary. If the issue comes from a native plugin or app-shell change, assess whether a new native build is needed. First identify which layer caused the failure.
Qu'est-ce que je devrais vérifier après avoir arrêté ou fait remonter ?
Confirmez l'état du canal et du bundle actif, puis vérifiez l'adoption et les erreurs des mises à jour par version. Testez le parcours utilisateur qui a échoué sur un appareil du groupe affecté. Vérifiez également les appareils qui n'ont pas encore mis à jour, car les métriques globales peuvent cacher les problèmes limités à une version ou à un groupe de cohorte.
Conclusion
Arrêtez-vous lorsque vous avez besoin d'arrêter la nouvelle exposition pendant que vous enquêtez. Revenez en arrière lorsque les utilisateurs ciblés ont besoin d'une version stable. Mettez en place les deux contrôles à l'avance, puis les répétez sur un canal de test avant votre prochaine mise en production.
