Passer à la navigation principale

Retours en arrière

Même si les mises à jour en temps réel de Capgo vous permettent de livrer rapidement des améliorations et des correctifs à vos utilisateurs, il peut y avoir des situations où vous devez revenir à une version précédente de votre application. Peut-être que la mise à jour récente a introduit une erreur critique inattendue, ou peut-être que vous souhaitez rétablir une modification spécifique pendant que vous travaillez sur une correction.

Capgo fournit plusieurs moyens de gérer les builds d'un canal et de contrôler la version de votre application que les utilisateurs reçoivent, y compris les options de reversion manuelle et les mécanismes de sécurité automatiques.

Capgo comprend un mécanisme de sécurité intégré pour protéger vos utilisateurs des mises à jour brisées. Si une erreur JavaScript se produit avant l'appel de la méthode, le plugin se met automatiquement en reversion vers la version précédente fonctionnelle. notifyAppReady() Comment fonctionne la protection de reversion automatique

Titre de la section « Comment fonctionne la protection de reversion automatique »

Capacitor

Lorsqu'une mise à jour nouvelle 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 s'est chargée avec succès. Cette méthode signale que :

  • Le bundle JavaScript s'est chargé sans erreurs critiques
  • La fonctionnalité de base de votre application fonctionne
  • La mise à jour est sûre à conserver

Si notifyAppReady() n'est pas appelée en raison d'un crash JavaScript ou d'une erreur critique, Capgo fera :

  1. Déterminera que la mise à jour a échoué à s'initialiser correctement
  2. Reviendra automatiquement à la version de travail précédente
  3. Marquera la mise à jour problématique comme échouée pour l'empêcher d'être appliquée à nouveau
import { CapacitorUpdater } from '@capgo/capacitor-updater'
// Call this after your app has successfully initialized
await CapacitorUpdater.notifyAppReady()

Cette protection automatique aide à s'assurer que même si vous poussez par erreur une mise à jour cassée, vos utilisateurs ne seront pas coincés avec une application non fonctionnelle.

Vous pouvez configurer le temps pendant lequel Capgo attend notifyAppReady() pour être appelé en définissant le appReadyTimeout dans votre configuration Capacitor :

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

La appReadyTimeout valeur est spécifiée en millisecondes. La durée de 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 prend plus de temps à charger en raison de processus d'initialisation complexes, vous devriez peut-être augmenter cette valeur.

Chaque fois que vous publiez une nouvelle version et que vous l'affectez à un canal, Capgo garde une trace de ces versions. Si vous avez besoin de rétablir une mise à jour spécifique, vous pouvez sélectionner l'une de ces versions précédentes pour la redéployer sur le canal.

Interface de retournement de version

La méthode principale pour revenir en arrière est l'interface de retournement de version, qui se trouve dans la 4ème onglet (Histoire) lors de la consultation d'un canal dans le tableau de bord Capgo. Cet onglet fournit une vue complète de toutes les versions disponibles pour le canal, vous permettant de sélectionner facilement et de rétablir n'importe quelle version précédente.

Pour revenir en arrière en utilisant l'onglet Histoire :

  1. Se connecter au Tableau de bord Capgo.

  2. Naviguer vers la section « Canaux ».

  3. Cliquez sur le nom du canal que vous souhaitez revenir en arrière.

  4. Allez dans la 4ème onglet (Histoire) dans la vue du canal.

  5. Trouvez la version que vous souhaitez rétablir dans l'historique des versions.

  6. Sélectionnez cette build pour la rendre la build active pour le canal.

  7. Confirmez que vous voulez revenir à cette build.

Méthode alternative : Utilisation de l'icône de couronne

Section intitulée “Méthode alternative : Utilisation de l'icône de couronne”

Comme deuxième méthode, vous pouvez également revenir directement à partir de la première page en cliquant sur l'icône de couronne à côté de toute build dans l'historique des builds du canal :

  1. Dans la première page de la vue du canal, trouvez la build que vous souhaitez rétablir.
  2. Cliquez sur l'icône de couronne à côté de cette build pour la rendre la build active pour le canal. Options de gestion du canal
  3. Confirmez que vous voulez revenir à cette build.

After le retour en arrière, les appareils configurés pour écouter le canal mis à jour recevront la version précédente la prochaine fois qu'ils vérifient une mise à jour. La version retournée sera traitée comme une nouvelle mise à jour, donc le flux de mise à jour habituel et les conditions s'appliquent.

Accélérer un Retour en Arrière Critique avec Notifications (Prévue Privée)

Section intitulée “Accélérer un Retour en Arrière Critique avec Notifications (Prévue Privée)”

La réattribution d'un canal a généralement effet la prochaine fois qu'un appareil vérifie une mise à jour. L'intégration de Notifications Capgo est actuellement en prévue privée et peut envoyer une notification de vérification de mise à jour silencieuse à une application prise en charge pendant qu'elle est en arrière-plan. Avec l'intégration de l'actualiseur activée, l'application peut vérifier, télécharger et installer le retour en arrière selon le mode de mise à jour configuré.

Ceci est un chemin d'accélération, pas une commande de flotte forcée. La livraison reste de meilleure volonté et dépend de la planification de l'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é de quitter, donc il ne peut pas promettre un temps fixe pour atteindre chaque appareil.

Pour demander un accès à la prévue privée ou configurer ce chemin critique, contactez support@capgo.app. Vous pouvez également lire Notifications : Activer les Vérifications de Mise à Jour Silencieuses.

Si vous souhaitez temporairement arrêter les mises à jour sur un canal pendant que vous investigatez un problème, vous pouvez désassocier le canal de sa version actuelle.

Pour délier un canal :

  1. Naviguez vers le canal dans le tableau de bord Capgo.

  2. Cliquez sur le bouton « Délié » à côté de la version actuelle.

  3. Confirmez que vous voulez délier le canal.

Une fois qu'un canal est délié, il ne distribuera plus de mises à jour nouvelles. Les appareils configurés pour ce canal resteront sur leur version actuelle jusqu'à ce que le canal soit lié à une version à nouveau.

Cela est utile si vous avez identifié un problème avec une mise à jour mais n'êtes pas encore sûr de la version à laquelle vous souhaitez revenir. Délier le canal vous donne du temps pour enquêter sans pousser de mises à jour supplémentaires.

Dans des situations plus graves, vous pouvez vouloir rétablir tous les appareils sur un canal sur la version web qui a été initialement emballée avec votre application native. Cela s'appelle le « bundle intégré ».

Pour forcer le bundle intégré sur un canal :

  1. Naviguez vers le canal dans le tableau de bord Capgo.

  2. Cliquez sur le bouton « Bundle Intégré ».

  3. Confirmez que vous souhaitez forcer le paquetage intégré.

Lorsque vous forcez le paquetage intégré, tous les appareils configurés sur ce canal reverront automatiquement à la mise à jour web originale empaquetée lors de leur prochaine vérification de mise à jour. Cela se produit, quel que soit le build sur lequel ils se trouvent.

Cette option de reversion est plus agressive que la reversion à un build précédent spécifique, car elle élimine tous les mises à jour en direct publiées depuis la dernière mise à jour de l'application dans les magasins d'applications.

Pour détecter rapidement les problèmes et minimiser l'impact des mises à jour problématiques, il est important de disposer d'un plan de surveillance de vos releases et de réponse aux problèmes.

Certaines stratégies incluent :

Pour un lancement limité à un groupe, utilisez Déploiements progressifs ou mettre en pause l'exposition ou effacer son cible avant de changer le bundle stable pour tout le canal.

  • Surveiller les rapports de crash et les commentaires des utilisateurs immédiatement après la mise à jour d'une mise à jour
  • Utiliser des déploiements étalés ou un système de canal étape par étape pour tester les mises à jour sur un groupe plus petit avant une large diffusion
  • Avoir un processus de décision clair pour savoir quand revenir en arrière, délier ou forcer le bundle intégré, et qui a l'autorité pour le faire
  • Communiquer aux utilisateurs sur le problème et la résolution, si nécessaire

En combinant une surveillance soigneuse avec la capacité de gérer rapidement les mises à jour problématiques, vous pouvez livrer une expérience d'application en constante amélioration tout en minimisant les perturbations pour vos utilisateurs.

Continuez à partir des Retours en arrière

Sous-titre « Continuez à partir des Retours en arrière »

Si vous utilisez Retours en arrière pour planifier le retour en arrière et le contrôle de version, connectez-le avec Ciblage de version pour les détails d'implémentation dans la cible de version, Mise à jour pour les détails d'implémentation dans la Mise à jour, bundle pour les détails d'implémentation dans bundle, Capgo Mises à jour en temps réel pour le flux de travail du produit dans Capgo Mises à jour en temps réel, et Stratégies de reversion pour Capacitor Mises à jour en temps réel pour le contexte pratique dans Stratégies de reversion pour Capacitor Mises à jour en temps réel.