Une pause empêche le déploiement progressif d'atteindre plus 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 lu 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 des 6 distinguent la pause du rollback comme deux actions distinctes, tandis que 2 passent le rollback sous silence ou considèrent la pause comme le seul levier. Aucun des 6 n'explique comment vérifier le rétablissement avec l'analytics ou des vérifications sur appareil, et aucun ne décrit de workflow pour éviter que les incidents se reproduisent. Bien choisir entre pause et rollback, puis confirmer que cela a fonctionné, comble une lacune laissée ouverte par les recommandations publiques sur les releases.
Table des matières
- Étape 1 : Configurez les contrôles de release dans Capgo
- Étape 2 : Choisir entre pause et rollback
- Étape 3 : mettre en pause l'exposition supplémentaire pendant l'investigation
- Étape 4 : Rollback si les utilisateurs ont besoin d'une version stable
- Étape 5 : Vérifier le rétablissement via l'analyse et les tests d'appareils
- Étape 6 : Éviter les incidents récurrents avec des workflows de release plus sûrs
- FAQ
- Conclusion
Étape 1 : Configurez les contrôles de release dans Capgo
Before an incident, make sure your team knows which channel is delivering the release and which bundle is stable. A channel is a named lane that directs app devices to an update. A bundle is the updateable web code sent through that lane.
Dans Capgo, un déploiement progressif permet de maintenir un bundle stable en place 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 l’ensemble des utilisateurs. Consultez les contrôles de déploiement progressif avant d'en activer un en production.
Consignez le responsable de la release et les signaux qui doivent arrêter l'extension du déploiement. Par exemple, décidez de la marche à suivre si les échecs de mise à jour augmentent, si un écran clé cesse de fonctionner ou si le support signale que les utilisateurs ne peuvent pas terminer une tâche. Fixez des limites basées sur le comportement normal de votre app plutôt que de choisir un seuil sous prétexte qu'il paraît strict.
Une mise à jour OTA modifie le code de l'app à distance. Elle ne remplace pas le binaire natif de l'app installé depuis un store. Le terme mise à jour over-the-air décrit cette approche de livraison. 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 progressif. Une faute de frappe dans le nom d'un 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 stable 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 effrénée dans le dashboard.
À retenir : Une pause limite l'exposition de nouveaux utilisateurs. Un rollback change la version vers laquelle les utilisateurs sont redirigés.
Étape 2 : Choisir entre pause et rollback
Pour la décision Capgo entre pause du déploiement et rollback, posez-vous d'abord une question : voulez-vous empêcher d'autres appareils de recevoir la cible, ou retirer les appareils d'une cible qui pose déjà problème ? Une pause limite l'exposition de nouveaux appareils. Un rollback supprime la cible et ramène les appareils à la version stable de secours lors de leur prochaine vérification de mise à jour.
Choisissez la pause lorsque les preuves sont incomplètes ou que le problème semble limité. Vous avez peut-être quelques signalements, mais vous ne savez pas si le bug touche un type d'appareil, un parcours utilisateur précis ou tous les appareils mis à jour. La pause laisse à l'équipe le temps d'analyser les signaux sans ajouter de nouveaux appareils au groupe de déploiement.
Choisissez le rollback lorsque la cible est clairement risquée pour les utilisateurs, ou lorsque l'équipe a assez de preuves que le bundle stable est plus sûr. Une pause seule ne retire pas la cible défectueuse des appareils déjà dans la cohorte de déploiement. Si ces utilisateurs doivent revenir à la version stable, le rollback est l'action qui modifie leur parcours de mise à jour.
Le Capgo : référence du canal CLI 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 le changement d'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'investigation | 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 JS est en cause, choisissez entre la pause et le rollback selon le nombre d'utilisateurs à soulager.
Étape 3 : mettre en pause l'exposition supplémentaire pendant l'investigation
Mettez en pause lorsque vous devez empêcher de nouveaux appareils d'entrer dans le groupe de déploiement, sans être encore prêt à revenir sur la cible pour les appareils qui en font déjà partie. C'est une étape de confinement. Elle vous laisse le temps de vérifier les faits tout en empêchant le problème de se propager à davantage d'utilisateurs.
Ouvrez le canal de production et vérifiez que vous agissez bien sur le déploiement concerné. Mettez-l’en pause depuis le dashboard, CLI, ou API que votre équipe utilise. Relisez ensuite l'état du canal. Ne vous fiez pas au simple succès d'une commande ; confirmez que le déploiement apparaît bien 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 reçoivent la version stable de repli lors de leur prochaine vérification. Cette distinction compte : la pause bloque les nouvelles entrées, mais ne ramène pas à elle seule la cohorte existante sur la version stable.
Ensuite, relevez les détails de la release avant toute autre modification. Notez le bundle cible, le canal, l'heure de la pause et le premier signalement connu. Conservez les informations sur l'appareil ou la session que votre équipe est autorisée à collecter. Une chronologie claire vous aide à comparer la cohorte de déploiement avec les appareils encore 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 plante au lancement, vérifiez si le crash correspond au nouveau bundle et à la version native de l'app. Évitez de prendre chaque signalement du support comme la preuve que la mise à jour est en cause.
Désignez un responsable et une échéance 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 par les preuves, soit choisir le rollback si la cible reste risquée.
Conseil de pro : Informez le support et l'équipe de release que le déploiement est en pause. Sinon, un groupe pourrait continuer à faire remonter des signalements pendant qu'un autre suppose que le déploiement a déjà été annulé.
À ce stade, les nouveaux appareils ne devraient plus entrer dans 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 de reprendre le déploiement.
Étape 4 : Rollback si les utilisateurs ont besoin d'une version stable
Effectuez un rollback quand les utilisateurs déjà sur la cible doivent revenir vers un bundle connu comme stable. C'est une réponse plus forte que la pause. Cela modifie ce que sert le canal, vérifiez donc le build stable sélectionné avant de confirmer l'action.
Dans Capgo, ouvrez le canal concerné et examinez l'historique de ses builds. Choisissez la version que vous souhaitez restaurer, puis confirmez qu'il s'agit du bon bundle stable pour cette app et ce canal. Capgo documentation de rollback décrit le chemin dans le dashboard et précise que les appareils recevront le build sélectionné lors de leur prochaine vérification de mise à jour.
Après un rollback, ne partez pas du principe que tous les appareils ont changé d'un coup. 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 si c'est bien la cible de récupération visée. Il renvoie les appareils vers le build web empaqueté dans l'app native, qui peut différer du dernier bundle OTA. Vérifiez la compatibilité et l'impact utilisateur avant d'en faire votre étape de récupération.
Conservez le bundle à l'origine de l'incident pour l'analyse, sauf si votre processus de rétention en décide autrement. L'ID de release et le commit aident les ingénieurs à comparer le changement avec la version stable. Sauvegardez les logs pertinents avant le nettoyage, surtout si vous devez comprendre comment le problème a échappé aux tests.
Le rollback n'est pas la bonne solution à chaque incident. Si la cause racine est une dépendance côté serveur, corrigez ce service. Si le changement dépend d'un code natif absent des binaires installés, préparez un build natif et suivez le parcours de publication sur les stores pour ce changement.
Étape 5 : Vérifier le rétablissement via l'analyse et les tests d'appareils
Après une pause ou un rollback, regardez ce que font réellement les appareils plutôt que de voir dans le changement de contrôl’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 remontées des appareils entre la release concernée et la version stable.
Les analyses live update de Capgo vous aident à inspecter les métriques d'adoption, les taux d'erreur et les logs au niveau des appareils. Utilisez ces signaux pour répondre à des questions précises : les nouveaux appareils reçoivent-ils toujours la cible, les appareils concernés vérifient-ils bien le bundle stable, et l'échec signalé s'est-il arrêté après le rétablissement ?
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 signalement et vérifiez que l'app atteint l'état attendu. Si l'incident touche un flux critique, demandez à une autre personne que l'auteur de la modification de confirmer le résultat.
Comparez ce qui est comparable. Un compteur d'erreurs global 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 quand ces champs sont disponibles. Cherchez une différence liée à la release plutôt que d'accuser par défaut la dernière mise à jour.
Vérifiez aussi les utilisateurs qui n'ont pas mis à jour. Leur présence peut donner l'impression que les métriques globales sont saines alors que la cohorte concernée voit toujours le bug. Suivez la part des appareils sur la cible par rapport à celle sur la version stable, et rattachez les retours du support à la version réellement exécutée.
Consignez le résultat du rétablissement et l'incertitude qui reste. Si les erreurs baissent mais que quelques utilisateurs signalent toujours le même problème, ne clôturez pas l'incident tant que vous ne savez pas s'ils sont hors ligne, sur un ancien shell natif ou s'ils utilisent encore le bundle concerné.
Le retour à la normale est confirmé lorsque le canal pointe vers la version prévue et que le parcours utilisateur défaillant fonctionne sur un appareil capable de reproduire le problème. Les métriques vous aident à voir l'ampleur du problème ; un test sur appareil confirme ce que vit réellement l'utilisateur.
Étape 6 : Éviter les incidents récurrents avec des workflows de release plus sûrs
Intégrez la pause et le rollback à votre plan de release avant la publication. Le responsable de la release doit savoir qui peut arrêter l'exposition et qui peut approuver un retour à la version stable. Cela supprime un délai fréquent : attendre une réunion pendant que d'autres appareils entrent dans le déploiement progressif.
Gardez une version stable de secours assignée pendant que la cible du déploiement progressif est testée. Commencez par une cohorte restreinte et définie, puis élargissez uniquement lorsque les signaux de santé convenus restent dans vos limites. Capgo permet de contrôler les releases par canal, afin que les équipes puissent 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 passés. Il doit aussi échouer proprement si le canal est incorrect ou si la release n'est pas prête pour la promotion.
Un workflow de continuous delivery garde le logiciel prêt pour la release grâce à un processus automatisé. Pour un workflow OTA, gardez un point d'approbation humaine clair même quand la publication est automatisée. L'automatisation doit rendre l'action choisie répétable, pas prendre la décision à la place d'un changement non relu.
Avec Capgo, un déploiement en une seule commande peut publier un bundle sur un canal. Gardez la commande dans le même processus de release que vos vérifications, 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 deviner quel canal a reçu le bundle.
Avant d'activer des garde-fous automatiques, définissez quel signal les déclenche et quelle action ils appliquent. Une pause peut stopper l'exposition de nouveaux appareils tout en maintenant ceux de 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 toute la procédure. Publiez un changement sans risque, vérifiez le contrôle de 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. Gardez un lien entre l'historique de déploiement et le changement source pour que les ingénieurs puissent restreindre la recherche quand une erreur apparaît. Si votre équipe se passe le relais sur les incidents entre fuseaux horaires, indiquez la dernière action effectuée et la personne responsable de la prochaine décision.
Si l'incident pointe vers un goulot d'étranglement plus large dans l'implémentation front-end, un développeur web comme Amir Arezoo peut être pertinent pour le développement web. Cela est distinct des contrôles de rollout 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 le workflow assez court pour que l'ingénieur d'astreinte puisse l'appliquer sous pression.
FAQ
Un déploiement progressif Capgo en pause annule-t-il les mises à jour déjà faites ?
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 faut-il mettre en pause plutôt que de faire un rollback ?
Utilisez la pause lorsque le problème est encore en cours d'investigation et que vous devez limiter l'exposition. Utilisez le 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 pause du déploiement progressif Capgo et rollback dépend de votre besoin immédiat : contenir l'exposition ou rétablir la cohorte existante.
Est-ce qu'un rollback mettra à jour tous les appareils immédiatement ?
Non. Un rollback change le bundle vers lequel pointe le canal, mais les appareils ne le reçoivent qu'à 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 l'état des appareils affectés et de leur 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 ancien bundle web pouvant être mis à jour, mais il ne peut ni ajouter ni supprimer de code natif dans le binaire d'une application installée. Si le problème vient d'un plugin natif ou d'une modification 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 aussi 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.
Conclusion
Mettez en pause lorsque vous devez arrêter d'exposer de nouveaux utilisateurs pendant l'investigation. Faites un rollback lorsque les utilisateurs ciblés ont besoin d'une version stable. Configurez ces deux contrôles en amont, puis entraînez-vous sur un canal de test avant votre prochaine release en production.
