Annulations

Même si les mises à jour en direct 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 tout en travaillant 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 des options de reversion manuelles et des mécanismes de sécurité automatiques.

Protection automatique de reversion

Capgo inclut 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 rétablira automatiquement vers la version précédente fonctionnelle. notifyAppReady() Comment fonctionne la protection automatique de reversion

Section intitulée « Comment fonctionne la protection automatique de reversion »

When a new update is downloaded and applied, Capgo expects your app to call notifyAppReady() Prêt à coller

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

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

1. Détermine que l'actualisation a échoué à se lancer correctement
2. Revert automatiquement à la version de travail précédente
3. Marque l'actualisation problématique comme échouée pour l'empêcher d'être appliquée à nouveau

Conseil

Assurez-vous d'appeler notifyAppReady() dans l'initialisation de votre application code après que vos composants de base ont chargé avec succès. Cela garantit que la protection automatique de reversion fonctionne comme prévu.

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

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

Cette protection automatique vous aide à vous 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.

Configuration du temps d'attente

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

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

valeur est spécifiée en millisecondes. La valeur de temps 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 prend plus de temps à charger en raison de processus d'initialisation complexes, vous devriez peut-être augmenter cette valeur. appReadyTimeout Retour en arrière vers une version précédente

Section intitulée « Retour en arrière vers une version précédente »

Chaque fois que vous téléchargez une nouvelle version et affectez-la à un canal, Capgo garde une histoire 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.

La principale façon de revenir en arrière est par l'interface de reversion, 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 à l'aide de 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 le 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 version pour la rendre la version active pour le canal.

7. Confirmez que vous souhaitez revenir à cette version.

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 n'importe quel build dans l'historique de build du canal :

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

Note

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

Après le rétablissement, les appareils configurés pour écouter le canal mis à jour recevront le build précédent la prochaine fois qu'ils vérifieront une mise à jour. Le build rétabli sera traité comme une nouvelle mise à jour, donc le flux de mise à jour habituel et les conditions s'appliquent.

Délier un canal

Si vous souhaitez suspendre temporairement les mises à jour sur un canal pendant que vous enquêtez sur un problème, vous pouvez délier le canal de sa build actuelle.

Pour délier un canal :

1. Naviguez vers le canal dans l'Capgo Tableau de bord.

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

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

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

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

Forcer le Bundle Intégré

Dans des situations plus graves, vous pouvez vouloir rétablir tous les appareils sur un canal sur la build web qui a été originellement emballée avec votre binôme natif. 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 bundle intégré.

Lorsque vous forcez le bundle intégré, tous les appareils configurés sur ce canal reverront à la mise à jour web originale empaquetée à leur prochaine vérification de mise à jour. Cela se produit quel que soit la mise à jour sur laquelle ils sont actuellement.

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

Attention

Faites preuve de prudence lors de la mise en œuvre du bundle intégré, car cela affectera tous les appareils sur le canal. Assurez-vous d'avoir considéré l'impact et d'avoir un plan pour avancer avant de prendre cette action.

Surveillance et réponse aux problèmes

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 :

• Surveiller les rapports de panne et les commentaires des utilisateurs immédiatement après la mise à jour d'une version
• 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
• Disposer d'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

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 Ciblage de version, Mise à jour du comportement pour le détail d'implémentation dans Mise à jour du comportement, bundle pour le détail 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.