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.

Réponse courte : pour faire un rollback d'un mauvais Capacitor live update avec Capgo, redirigez le canal vers le bundle précédent dans le dashboard Capgo ou via la Capgo CLI ; les appareils le récupèrent lors de leur prochaine vérification de mise à jour, et le metteur à jour revient automatiquement à la version précédente si un nouveau bundle n'appelle pas notifyAppReady() dans la plage configurée appReadyTimeout.

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 publiez par erreur une mise à jour défectueuse, vos utilisateurs ne se retrouvent pas avec une application inutilisable.

Configuration du timeout

Vous pouvez configurer la durée pendant laquelle Capgo attend notifyAppReady() pour être appelé en définissant appReadyTimeout dans votre configuration Capacitor :

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

Le appReadyTimeout La valeur est spécifiée en millisecondes. Le délai d’attente par défaut est généralement de 10 secondes, mais vous pouvez l’ajuster en fonction des besoins d’initialisation de votre application. Si votre application met plus de temps à se charger en raison de processus d’initialisation complexes, vous pouvez augmenter cette valeur.

Effectuer un rollback vers un bundle précédent

Chaque fois que vous envoyez 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

En alternative, vous pouvez également 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 auquel 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

Revenir à une version précédente n'affecte que le canal sélectionné. Si vous avez plusieurs canaux (par 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 la version précédente lors de leur prochaine vérification de mise à jour. La version rollback sera traitée comme une nouvelle mise à jour, donc le flux et les conditions habituels s'appliquent.

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 une surveillance rigoureuse et la capacité à gérer rapidement les mises à jour problématiques, vous pouvez offrir une expérience d’application en amélioration continue tout en minimisant les perturbations pour vos utilisateurs.

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 le détail d’implémentation dans le bundle, Live Updates Capgo pour le workflow produit dans 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.