Une pause empêche un rollout d'atteindre davantage d'appareils. Un rollback ramène les appareils affectés vers une version stable connue. Capgo supporte les deux, ce qui vous permet de contenir un problème d'abord, puis de décider de la suite.
Utilisez ces étapes pour choisir la bonne action, vérifier son effet et réduire le risque de répétition de l'incident.
Nous avons analysé 6 guides publics sur les déploiements progressifs et le rollback publiés par Google Play, Amazon Appstore, CodePush de Microsoft, Bitrise, Nearform et Digia. Quatre d'entre eux distinguent la pause du rollback comme deux actions distinctes, tandis que deux ignorent le rollback ou considèrent la pause comme le seul levier. Aucun des 6 n'explique comment vérifier la récupération via l'analytics ou des tests sur appareil, et aucun ne décrit de workflow pour prévenir la récurrence des incidents. Bien choisir entre pause et rollback, puis confirmer que l'action a fonctionné, permet de combler une lacune présente dans tous les guides de release publics.
Table of Contents
- Étape 1 : Configurez les contrôles de release dans Capgo
- Étape 2 : Choisissez de mettre en pause ou de faire un rollback
- Étape 3 : Mettre en pause l'exposition pendant l'analyse
- Step 4: Roll back when users need a stable version
- Étape 5 : Vérifiez le rétablissement via l'analytics et les tests sur appareil
- Étape 6 : Évitez la répétition d'incidents avec des workflows de release plus sûrs
- FAQ
- Conclusion
Étape 1 : Configurez les contrôles de release dans Capgo
Avant un incident, assurez-vous que votre équipe sait quel canal diffuse la release et quel bundle est stable. Un canal est une voie nommée qui dirige les appareils vers une mise à jour. Un bundle est le code web mis à jour envoyé via ce canal.
Dans Capgo, un déploiement progressif permet de maintenir un bundle stable tout en envoyant une cible de déploiement distincte à un groupe sélectionné. Cela vous offre un point de contrôl’avant que le nouveau bundle n'atteigne une base d'utilisateurs plus large. Examinez les contrôles de déploiement progressif avant d'en activer un en production.
Notez le responsable de la release et les signaux qui doivent arrêter l'extension du déploiement. Par exemple, décidez de la conduite à tenir si les échecs de mise à jour augmentent, si un écran clé cesse de fonctionner ou si le support signale que les utilisateurs ne parviennent pas à terminer une tâche. Fixez des limites basées sur le comportement normal de votre app plutôt que de choisir un seuil simplement parce qu'il semble strict.
Une mise à jour OTA modifie le code de l'app à distance. Elle ne remplace pas le binaire natif installé depuis un store. Le terme mise à jour over-the-air décrit cette méthode de diffusion. Gardez bien cette distinction en tête : si un correctif nécessite un nouveau plugin natif ou une modification de la configuration native de l'app, un rollback de bundle ne suffira pas.
Avant la release, confirmez que le bundle stable est bien celui attendu. Vérifiez le nom du canal, le bundle cible et l'état du déploiement. Une faute de frappe dans un nom de canal ou une cible obsolète peut orienter les intervenants vers le mauvais contrôl’alors que chaque minute compte.
À ce stade, vous devriez avoir un responsable de release désigné, un bundle validé et une condition d'arrêt écrite. Cette préparation transforme la décision suivante en un choix opérationnel, et non en une course paniquée dans le dashboard.
L'essentiel : Une pause limite l'exposition de nouveaux utilisateurs. Un rollback change la version vers laquelle les utilisateurs sont redirigés.
Étape 2 : choisir entre une pause et un rollback
Pour la décision Capgo pause rollout vs rollback, posez-vous d'abord une question : essayez-vous d'empêcher d'autres appareils de recevoir la cible, ou de retirer les appareils d'une cible qui cause déjà des dommages ? Une pause limite la nouvelle exposition. Un rollback supprime la cible et ramène les appareils à la version stable de secours lors de leur prochain contrôle de mise à jour.
Choisissez la pause lorsque les preuves sont incomplètes ou que le problème semble limité. Vous avez peut-être quelques rapports, mais vous ne savez pas si le bug affecte un type d'appareil, un flux utilisateur particulier ou chaque appareil mis à jour. La pause permet à l'équipe d'analyser les signaux sans ajouter de nouveaux appareils au groupe de déploiement.
Choisissez le rollback lorsque la cible est clairement dangereuse pour les utilisateurs, ou lorsque l'équipe a suffisamment de preuves que le bundle stable est plus sûr. Une pause seule ne retire pas la mauvaise cible des appareils déjà présents dans la cohorte de déploiement. Si ces utilisateurs doivent revenir à une version stable, le rollback est l'action qui modifie leur chemin de mise à jour.
Le Capgo canal CLI référence propose des commandes de pause et de rollback distinctes. Considérez-les comme des actions différentes, et non comme deux noms pour le même arrêt d'urgence.
| Ce que vous voyez | Première action | Ce qu'il faut vérifier ensuite |
|---|---|---|
| Erreurs précoces, périmètre flou | Mettre le déploiement en pause | Comparer les appareils affectés et non affectés |
| Bug connu affectant la cohorte cible | Effectuer un rollback de la cible | Confirmer que le bundle stable est actif |
| Problème lié au code natif ou à un service | Mettre en pause ou contenir la modification de l'app, puis corriger la couche affectée | Vérifier si un build natif ou une réparation de service est nécessaire |
| Seul un petit groupe a la version cible, sans impact utilisateur confirmé | Mettre en pause pendant l'analyse | Resume only after the release owner approves |
Un rollback ne corrigera pas une panne backend et ne peut pas ajouter une capacité native manquante. Identifiez d'abord quelle couche a échoué. Si le bundle web est en cause, choisissez entre la pause et le rollback selon le nombre d'utilisateurs à soulager.
Étape 3 : Mettre en pause l'exposition pendant l'analyse
Pausez quand vous devez empêcher de nouveaux appareils d'intégrer le groupe de déploiement, sans pour autant vouloir revenir en arrière pour ceux qui y sont déjà. C'est une étape de confinement. Cela vous donne du temps pour vérifier les faits tout en évitant que le problème ne se propage à davantage d'utilisateurs.
Ouvrez le canal de production et vérifiez que vous agissez bien sur le déploiement concerné. Mettez-l’en pause via le dashboard, CLI ou l'outil API utilisé par votre équipe. Relisez ensuite l'état du canal. Ne vous contentez pas de la réussite d'une commande ; confirmez que le déploiement est bien marqué comme « en pause ».
Dans le modèle de déploiement progressif de Capgo, les appareils déjà présents dans la cohorte peuvent rester sur la version cible après une pause. Les nouveaux appareils éligibles recevront la version stable lors de leur prochain check. Cette distinction est cruciale : la pause bloque les nouvelles entrées, mais ne ramène pas automatiquement la cohorte existante vers la version stable.
Ensuite, capturez les détails de la release avant d'effectuer une autre modification. Notez le bundle cible, le canal, l'heure de la pause et le premier rapport connu. Conservez les détails de l'appareil ou de la session que votre équipe est autorisée à collecter. Une chronologie claire vous aidera à comparer la cohorte de déploiement avec les appareils toujours sur le bundle stable.
Vérifiez le problème via un parcours reproductible. Si les utilisateurs signalent un échec de connexion, testez ce parcours exact sur un appareil affecté. Si l'app crash au lancement, vérifiez si le crash correspond au nouveau bundle et à la version de l'app native. Évitez de considérer chaque rapport de support comme une preuve que la mise à jour est la cause du problème.
Désignez un responsable et un délai de décision pour l'investigation. Un déploiement progressif en pause peut rester en suspens si personne ne pilote la suite. Le responsable doit soit reprendre le déploiement une fois la release validée, soit opter pour le rollback si la version cible n'est toujours pas sûre.
Conseil de pro : Prévenez le support et l'équipe de release que le déploiement est en pause. Sinon, un groupe peut continuer à faire remonter des signalements alors qu'un autre suppose que le déploiement a déjà été annulé.
À ce stade, les nouveaux appareils ne devraient plus rejoindre la cohorte de déploiement. Vérifiez l'état du canal et le comportement d'un appareil qui n'était pas dans la cohorte avant de passer au rollback ou à la reprise.
Step 4: Roll back when users need a stable version
Effectuez un rollback lorsque les utilisateurs déjà sur la version cible doivent revenir vers un bundle connu comme stable. C'est une réponse plus forte que la mise en pause. Cela modifie le contenu servi par le canal : vérifiez donc le build stable sélectionné avant de confirmer l'action.
Dans Capgo, ouvrez le canal concerné et consultez son historique de builds. Choisissez la version que vous souhaitez restaurer, puis confirmez qu'il s'agit du bon bundle stable pour cette application et ce canal. La documentation de Capgo sur le documentation sur le rollback décrit le parcours dans le dashboard et précise que les appareils recevront le build sélectionné lors de leur prochaine recherche de mise à jour.
Après un rollback, ne partez pas du principe que tous les appareils ont basculé en même temps. Un appareil doit vérifier s'il y a une mise à jour, et un utilisateur hors ligne ne le fera peut-être que 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 de la cohorte concernée.
N'utilisez le bundle intégré que s'il s'agit de la cible de récupération souhaitée. Il redirige les appareils vers le build web packagé dans l'application native, qui peut différer du dernier bundle Live Update. Vérifiez la compatibilité et l'impact utilisateur avant de le choisir comme étape de récupération.
Conservez le bundle ayant causé l'incident pour analyse, sauf si votre processus de rétention en dispose autrement. L'ID de la release et le commit aident les ingénieurs à comparer le changement avec la version stable. Préservez les logs pertinents avant le nettoyage, surtout si vous devez comprendre pourquoi le problème a échappé aux tests.
Le rollback n'est pas la solution à chaque incident. Si la cause racine est une dépendance côté serveur, réparez ce service. Si le changement dépend d'un code natif absent des binaires installés, préparez un build natif et suivez le processus de publication sur les stores pour ce changement.
Étape 5 : Vérifier la récupération avec l'analytics et les tests d'appareils
Après une pause ou un rollback, vérifiez le comportement des appareils plutôt que de considérer le changement de contrôle comme une preuve de récupération. Vérifiez d'abord l'état du canal actif. Comparez ensuite l'adoption des mises à jour, les erreurs et les rapports d'appareils entre la release affectée et la version stable.
Les analyses live update de Capgo peuvent vous aider à inspecter les métriques d'adoption, les taux d'erreur et les logs au niveau de l'appareil. Utilisez ces signaux pour répondre à des questions précises : les nouveaux appareils reçoivent-ils toujours la cible, les appareils affectés cherchent-ils le bundle stable, et l'échec signalé s'est-il arrêté après la récupération ?
Testez le parcours utilisateur qui a échoué. Un téléchargement réussi ne prouve pas que l'app fonctionne. Ouvrez l'écran concerné, répétez l'action qui a mené au rapport et vérifiez que l'app atteint l'état attendu. Si l'incident concerne un flux critique, demandez à quelqu'un d'autre que l'auteur de la modification de confirmer le résultat.
Comparez des éléments comparables. Un nombre élevé d'erreurs peut augmenter pour des raisons sans lien avec la release, comme un problème de service ou un changement de trafic. Filtrez par bundle, canal, version de l'app et appareil lorsque ces champs sont disponibles. Cherchez une différence liée à la release plutôt que de blâmer la dernière mise à jour par défaut.
Vérifiez également les utilisateurs qui n'ont pas fait la mise à jour. Leur présence peut donner l'impression que les métriques globales sont saines alors que la cohorte affectée voit toujours le bug. Suivez la part des appareils sur la cible par rapport à la part sur la version stable, et liez les rapports de support à la version réellement utilisée par les utilisateurs.
Notez le résultat de la récupération et l'incertitude restante. Si les erreurs diminuent mais que quelques utilisateurs signalent toujours le même problème, ne clôturez pas l'incident tant que vous n'avez pas compris s'ils sont hors ligne, sur une ancienne version du shell natif ou s'ils utilisent toujours le bundle affecté.
Le rétablissement est confirmé lorsque le canal pointe vers la version prévue et que le parcours utilisateur défaillant fonctionne sur un appareil ayant reproduit le problème. Les métriques vous aident à visualiser l'ampleur du problème ; un test sur appareil confirme ce que l'utilisateur expérimente réellement.
Étape 6 : Évitez la répétition d'incidents avec des workflows de release plus sûrs
Intégrez la pause et le rollback dans votre plan de release avant la publication. Un responsable de release doit savoir qui peut stopper l'exposition et qui peut approuver un retour à la version stable. Cela élimine un délai courant : attendre une réunion pendant que de plus en plus d'appareils entrent dans le rollout.
Gardez une version de secours stable assignée pendant que la cible du rollout est testée. Utilisez d'abord une cohorte restreinte et définie, puis étendez-l’uniquement lorsque les indicateurs de santé convenus restent dans vos limites. Capgo prend en charge le contrôle des releases par canal, permettant aux équipes de séparer les tests de la diffusion large en production.
Intégrez des vérifications de release dans votre CI/CD, le processus automatisé qui exécute les tests et déploie un changement. Un pipeline peut publier le bundle sur le canal prévu une fois les tests réussis. Il doit également échouer de manière sécurisée si le canal est incorrect ou si la release n'est pas prête pour la promotion.
Un workflow de continuous delivery maintient le logiciel prêt pour la release via un processus automatisé. Pour un workflow de Live Update, gardez un point d'approbation humaine clair, même si la publication est automatisée. L'automatisation doit rendre l'action choisie répétable, et non prendre la décision pour un changement non révisé.
Avec Capgo, un déploiement en une seule commande peut publier un bundle sur un canal. Intégrez la commande au même processus de release que vos tests, et rendez le canal cible visible dans l'historique de déploiement. Cela aide l'ingénieur d'astreinte à voir exactement ce qui a été publié sans avoir à deviner quel canal a reçu la mise à jour.
Avant d'activer des protections automatiques, définissez quel signal les déclenche et quelle action elles doivent entreprendre. Une pause peut stopper l'exposition de nouveaux utilisateurs tout en maintenant la cohorte actuelle sur la cible. Un rollback peut rediriger les appareils vers une version stable. Ces résultats diffèrent, ne configurez donc pas l'un comme s'il s'agissait de l'autre.
Utilisez un canal de test pour répéter l'intégralité de la procédure. Publiez un changement sans risque, vérifiez le contrôle de la pause, puis testez le rollback vers le bundle précédent. Confirmez le comportement de l'app sur un appareil après chaque action. Un runbook écrit doit inclure le canal, la commande ou le chemin dans le dashboard, l'état attendu et la personne qui confirme le succès.
Les notes de release doivent identifier le bundle et son objectif. Maintenez un lien entre l'historique de déploiement et le changement de code source pour que les ingénieurs puissent restreindre leur recherche en cas d'erreur. Si votre équipe transmet les incidents entre différents fuseaux horaires, incluez la dernière action effectuée et le responsable de la décision suivante.
Si l'incident pointe vers un goulot d'étranglement plus large dans l'implémentation front-end, un développeur web tel que Amir Arezoo peut être pertinent pour le développement web. Cela est distinct des contrôles de déploiement de Capgo, qui gèrent la diffusion et la récupération des mises à jour d'applications compatibles.
À ce stade, votre processus de release devrait inclure un fallback stable, un responsable, une règle d'arrêt et une action de récupération testée. Gardez un workflow assez court pour que l'ingénieur d'astreinte puisse l'appliquer sous pression.
FAQ
Does pausing a Capgo rollout roll back devices already updated?
Non. La pause empêche les nouveaux appareils éligibles d'entrer dans le déploiement, mais les appareils déjà dans la cohorte peuvent rester sur le bundle cible. Pour ramener ces utilisateurs vers une version stable, utilisez un rollback ou une autre action délibérée sur le canal. Vérifiez l'état du canal après l'une ou l'autre de ces actions, puis confirmez le résultat sur un appareil ayant reçu la version cible.
Quand dois-je mettre en pause plutôt que de faire un rollback ?
Mettez en pause lorsque le problème est encore en cours d'investigation et que vous devez limiter l'exposition. Faites un rollback lorsque la version cible est connue pour nuire aux utilisateurs ou lorsque les appareils affectés ont besoin d'un bundle stable. Le choix entre Capgo pause rollout vs rollback dépend de votre besoin immédiat : contenir le problème ou rétablir la cohorte existante.
Un rollback mettra-t-il à jour tous les appareils immédiatement ?
Non. Un rollback modifie le bundle vers lequel le canal pointe, mais les appareils le reçoivent lors de leur prochaine vérification de mise à jour. Un appareil hors ligne peut rester sur son bundle actuel jusqu'à sa reconnexion. Vérifiez la cible du canal, puis contrôlez les appareils affectés et leur statut de mise à jour avant de déclarer l'incident résolu.
Un rollback OTA peut-il corriger un problème d'application native ?
Non. Un rollback OTA peut restaurer un bundle web mis à jour précédemment, mais il ne peut ni ajouter ni supprimer de code natif à l'intérieur du binaire de l'application installée. Si le problème provient d'un plugin natif ou d'un changement de l'app-shell, évaluez si un nouveau build natif est nécessaire. Identifiez d'abord quelle couche a causé l'échec.
Que dois-je vérifier après une pause ou un rollback ?
Confirmez l'état du canal et le bundle actif, puis vérifiez l'adoption des mises à jour et les erreurs par release. Testez le parcours utilisateur qui a échoué sur un appareil du groupe concerné. Vérifiez également les appareils qui ne sont pas encore à jour, car les métriques globales peuvent masquer des problèmes limités à une version ou une cohorte spécifique.
Conclusion
Utilisez la pause quand vous devez stopper l'exposition de nouveaux utilisateurs pendant votre investigation. Utilisez le rollback quand les utilisateurs de la cible ont besoin d'une version stable. Configurez ces deux contrôles à l'avance, puis entraînez-vous sur un canal de test avant votre prochaine release en production.
