Rollbacks

Bien que les live updates de Capgo vous permettent de livrer rapidement des améliorations et des correctifs à vos utilisateurs, il peut arriver que vous deviez revenir à une version précédente de votre application. Peut-être qu'une nouvelle mise à jour a introduit un problème critique inattendu, ou que vous souhaitez revenir sur une modification spécifique pendant que vous travaillez sur un correctif.

Capgo propose plusieurs façons de gérer les builds d'un canal et de contrôler la version de votre application que reçoivent les utilisateurs, avec des options de rollback manuel et des mécanismes de sécurité automatiques.

Protection automatique contre les rollbacks

Capgo inclut un mécanisme de sécurité intégré pour protéger vos utilisateurs contre les mises à jour défectueuses. Si une erreur JavaScript survient avant le notifyAppReady() ne soit appelée, le plugin effectuera automatiquement un rollback vers la version précédente fonctionnelle.

Fonctionnement du rollback automatique

Lorsqu'une nouvelle mise à jour est téléchargée et appliquée, Capgo attend que votre application appelle notifyAppReady() dans un délai configurable pour confirmer que la mise à jour a été chargée avec succès. Cette méthode signale que :

• Le bundle JS a été chargé sans erreur critique
• Les fonctionnalités clés de votre app fonctionnent
• La mise à jour peut être conservée sans risque

Si notifyAppReady() si l'appel n'est pas déclenché par un crash JavaScript ou une erreur critique, Capgo va :

1. Détecter que la mise à jour n'a pas pu s'initialiser correctement
2. Revenir automatiquement au bundle fonctionnel précédent
3. Marquer la mise à jour problématique comme échouée pour éviter qu'elle ne soit réappliquée

Astuce

Assurez-vous d'appeler notifyAppReady() dans l'initialisation de votre app code, une fois vos composants principaux chargés avec succès. Cela garantit que la protection par rollback automatique fonctionne comme prévu.

import { CapacitorUpdater } from '@capgo/capacitor-updater'

// Call this after your app has successfully initialized
await CapacitorUpdater.notifyAppReady()

Cette protection automatique garantit que, même si vous poussez accidentellement une mise à jour défectueuse, vos utilisateurs ne se retrouveront pas avec une application non fonctionnelle.

Configuration du timeout

Vous pouvez configurer la durée d'attente de Capgo notifyAppReady() à appeler en configurant le appReadyTimeout dans votre configuration Capacitor :

{
  "plugins": {
    "CapacitorUpdater": {
      "appReadyTimeout": 10000
    }
  }
}

Le appReadyTimeout La valeur est spécifiée en millisecondes. Le timeout par défaut est généralement de 10 secondes, mais vous pouvez l'ajuster selon les besoins d'initialisation de votre app. Si votre app met plus de temps à charger en raison de processus d'initialisation complexes, vous pourriez vouloir augmenter cette valeur.

Effectuer un rollback vers un bundle précédent

Chaque fois que vous effectuez l'upload d'un nouveau build et que vous l'assignez à un canal, Capgo conserve l'historique de ces builds. Si vous devez annuler une mise à jour spécifique, vous pouvez sélectionner l'un de ces builds précédents pour le redéployer sur le canal.

Le principal moyen d'effectuer un rollback est de passer par l'interface de rollback, située dans le 4e onglet (Historique) lorsque vous consultez un canal dans le dashboard Capgo. Cet onglet offre une vue complète de tous les builds disponibles pour le canal, vous permettant de sélectionner et de revenir facilement à n'importe quelle version précédente.

Pour effectuer un rollback via l'onglet History :

1. Connectez-vous au dashboard Capgo.

2. Accédez à la section « Canaux ».

3. Cliquez sur le nom du canal sur lequel vous voulez effectuer un rollback.

4. Allez dans le 4e onglet (Historique) de la vue du canal.

5. Trouvez le build auquel vous souhaitez revenir dans l'historique des builds.

6. Sélectionnez ce build pour en faire le build actif du canal.

7. Confirmez que vous souhaitez effectuer un rollback vers ce build.

Méthode alternative : utiliser l'icône Crown

Deuxième option : vous pouvez aussi effectuer un rollback directement depuis le premier onglet en cliquant sur l'icône couronne à côté de n'importe quel build dans l'historique des builds du canal :

1. Dans le premier onglet de la vue du canal, trouvez le build vers lequel vous souhaitez revenir.
2. Cliquez sur l'icône couronne à côté de ce build pour en faire le build actif du canal.
3. Confirmez que vous souhaitez effectuer un rollback vers ce build.

Remarque

Le rollback vers un build précédent n'affecte que le canal sélectionné. Si vous avez plusieurs canaux (ex: Production, Staging, etc.), vous devrez répéter le processus de rollback pour chaque canal concerné.

Après le rollback, les appareils configurés pour écouter le canal mis à jour recevront le build précédent lors de leur prochain contrôle de mise à jour. Le build restauré sera traité comme une nouvelle mise à jour ; le flux et les conditions habituels s'appliquent donc.

Accélérer un rollback critique grâce aux notifications

Rediriger un canal prend normalement effet la prochaine fois qu'un appareil vérifie les mises à jour. Capgo Les notifications peuvent envoyer une notification silencieuse de vérification de mise à jour à une application compatible lorsqu'elle est en arrière-plan. Avec l'intégration de l'updater activée, l'application peut vérifier, télécharger et installer le rollback selon son mode de mise à jour configuré.

Il s'agit d'un mode d'accélération, pas d'une commande forcée sur toute la flotte. La livraison reste en best-effort et dépend de l'ordonnancement en arrière-plan du système d'exploitation, de la disponibilité du réseau et de l'état de l'appareil. Il ne peut pas mettre à jour une application hors ligne ou forcée à quitter, et ne peut donc pas garantir de délai fixe pour atteindre chaque appareil.

Pour configurer ce mode, suivez ces étapes : Notifications: Enable Silent Update Checks.

Dissocier un canal

Si vous voulez interrompre temporairement les mises à jour d'un canal le temps d'investiguer un problème, vous pouvez détacher le canal de son build actuel.

Pour détacher un canal :

1. Accédez au canal dans le dashboard Capgo.

2. Cliquez sur le bouton « Détacher » à côté du build actuel.

3. Confirmez que vous souhaitez détacher le canal.

Une fois un canal détaché, il ne distribuera plus aucune nouvelle mise à jour. Les appareils configurés sur ce canal resteront sur leur build actuel jusqu'à ce que le canal soit de nouveau lié à un build.

C'est utile si vous avez identifié un problème avec une mise à jour, mais que vous ne savez pas encore vers quel build effectuer le rollback. Dissocier le canal vous laisse le temps d'investiguer sans déployer d'autres mises à jour.

Forcer le bundle intégré

Dans des situations plus graves, vous pourriez vouloir faire revenir tous les appareils d'un canal au build web initialement empaqueté avec le binaire natif de votre application. C'est ce qu'on appelle le « built-in bundle ».

Pour forcer le built-in bundle sur un canal :

1. Accédez au canal dans le dashboard Capgo.

2. Cliquez sur le bouton « Built-in Bundle ».

3. Confirmez que vous souhaitez forcer le built-in bundle.

Lorsque vous forcez le built-in bundle, tous les appareils configurés pour ce canal reviendront au build web d'origine empaqueté lors de leur prochaine vérification de mise à jour. Cela se produit quel que soit le build sur lequel ils se trouvent actuellement.

Il s'agit d'une option de rollback plus radicale que de revenir à un build précédent précis, car elle écarte toutes les live updates publiées depuis la dernière publication de l'application sur les stores.

Attention

Soyez prudent quand vous forcez le bundle intégré, car cela affectera tous les appareils du canal. Assurez-vous d'avoir évalué l'impact et d'avoir un plan avant de procéder.

Surveiller et réagir aux incidents

Pour détecter rapidement les problèmes et minimiser l'impact des mises à jour problématiques, il est essentiel d'avoir un plan pour surveiller vos releases et réagir aux problèmes.

Voici quelques stratégies :

Pour un déploiement encore limité à une cohorte, utilisez Déploiements progressifs pour suspendre l'exposition ou effacer sa cible avant de changer le bundle stable de tout le canal.

• Surveiller les rapports de crash et les retours utilisateurs juste après la publication d'une mise à jour
• Utilisez des déploiements progressifs ou un système de canaux par étapes pour tester les mises à jour sur un groupe restreint avant la release globale
• Définir un processus de décision clair pour savoir quand faire un rollback, un unlink ou forcer le bundle intégré, et qui a l'autorité pour le faire
• Informer les utilisateurs du problème et de sa résolution, le cas échéant

En combinant un monitoring rigoureux et la capacité de gérer rapidement les mises à jour problématiques, vous pouvez offrir une expérience utilisateur en constante amélioration tout en minimisant les interruptions.

Continuer après les rollbacks

Si vous utilisez Rollbacks pour planifier le rollback et le contrôle de version, connectez-l’à Ciblage de version pour les détails d'implémentation dans Version Targeting, Comportement de mise à jour pour les détails d'implémentation du comportement des mises à jour, bundle pour les détails d'implémentation dans le bundle, Capgo Live Updates pour le workflow produit de Capgo Live Updates, et Stratégies de rollback pour Capacitor Live Updates pour le contexte pratique des stratégies de rollback pour Capacitor Live Updates.