Passer au contenu principal
Tutoriel

How to Keep Capgo Mises à Jour Économiques et Rapides

Un guide pratique Capgo pour des mises à jour en direct plus petites et plus sûres : les ensembles delta, la mise en œuvre basée sur le canal, les mises à jour de base natives, les aperçus de PR et les garde-fous de mise à jour directe.

Martin Donadieu

Martin Donadieu

Spécialiste du contenu

How to Keep Capgo Mises à Jour Économiques et Rapides

La meilleure mise à jour en direct est celle que vos utilisateurs remarquent à peine.

Cela signifie généralement trois choses :

  1. La mise à jour est petite.
  2. La mise en œuvre est contrôlée.
  3. La récupération est instantanée si quelque chose se produit mal.

Les mêmes conseils pour garder les mises à jour OTA économes qui fonctionnent dans le monde de React Native s'appliquent également à Capgo. La différence est que Capgo donne aux équipes Capacitor quelques leviers supplémentaires : Mises à jour Delta, canaux, annulations automatiques, ciblage de version, et optionnel chiffrement de bout en bout.

Si vous utilisez ces deux ensemble, vous obtenez des payloads plus petits, des installations plus rapides, et beaucoup moins de chaos opérationnel.

L'efficacité compte même lorsque le MAU reste le même

Un détail utile spécifique à Capgo : le MAU Capgo est effectivement le nombre de dispositifs actifs mensuels qui ont contacté le service de mise à jour au cours des 30 derniers jours.

Ainsi, réduire un bundle n'est pas principalement un tour de passe-passe pour réduire le comptage du MAU. Cela compte parce qu'il améliore les parties que les utilisateurs et les équipes ressentent vraiment :

  • Téléchargements plus rapides sur les réseaux cellulaires ou les Wi-Fi faibles
  • Expérience meilleure avec Mises à jour directes
  • Moins de bande passante gaspillée sur les mises à jour échouées ou annulées
  • Un rayon d'impact plus petit lors de la mise en production ou de la mise en ligne d'une mise à jour

Les mises à jour économes sont vraiment axées sur la vitesse, la sécurité et la discipline opérationnelle.

1. Définir par défaut les mises à jour Delta

Si vous faites seulement une chose, faites ceci.

Capgo’s Les mises à jour Delta Envoient uniquement les fichiers qui ont changé entre les versions au lieu de télécharger à nouveau le bundle web complet. C'est le plus grand gain pour la performance des mises à jour OTA de routine.

bun run build
bunx @capgo/cli@latest bundle upload --channel staging --delta

Lorsque votre passe de QA est terminée :

bunx @capgo/cli@latest bundle upload --channel production --delta

Si vous voulez que CI reste strict, utilisez --delta-only afin que personne ne retombe accidentellement sur les téléchargements de bundle complets :

bunx @capgo/cli@latest bundle upload --channel production --delta-only

Utilisez uniquement --delta-only lorsque votre flotte de production prend en charge les mises à jour Delta. Sur les versions de plugins mixtes, les appareils plus anciens qui ne supportent pas la livraison delta basée sur le manifeste ne seront pas en mesure de télécharger cette mise à jour.

Cela compte encore plus si vous utilisez directUpdate, car le temps entre « mise à jour trouvée » et « application rechargée » devient visible pour l'utilisateur.

2. Traitez les actifs comme des actifs, pas comme du bagage JavaScript

Les actifs volumineux sont où les lots OTA se gonflent discrètement.

Quelques règles pratiques :

  • Ne faites pas passer les grandes images ou les médias à l'intérieur du JavaScript lorsqu'un fichier d'actif normal fera l'affaire.
  • Keep frequently changing content on your own CDN or API if it does not need to live inside the shipped app bundle.
  • Laissez les actifs stables rester stables. Avec les mises à jour Delta, les fichiers inchangés sont réutilisés au lieu d'être téléchargés à nouveau.
  • C'est l'une des façons les plus faciles de garder __CAPGO_KEEP_0__ rapide même lorsque votre application grandit. Le pire modèle est une petite correction de l'interface utilisateur qui oblige les utilisateurs à télécharger un tas de médias non liés.

This is one of the easiest ways to keep Capgo fast as your app grows. The worst pattern is a tiny UI fix that forces users to download a pile of unrelated media.

3. Gardez les versions natives pour les changements réels natives

Capgo met à jour la couche web : HTML, CSS, JavaScript et les actifs chargés en temps de exécution.

Ce n'est pas le bon canal pour :

  • de nouveaux plugins natives,
  • les modifications de permissions,
  • capacitor.config.ts les changements,
  • toute chose qui modifie l'état du projet native iOS ou Android.

Cette ligne compte aussi pour la performance. Si vous continuez à injecter des changements structurels majeurs dans la voie de mise à jour OTA, votre stratégie d'actualisation devient plus lourde et plus risquée au fil du temps.

Utilisez deux voies de mise à jour à des fins délibérées :

Voie native

Pour les changements de plugins, les modifications de permissions et la configuration native :

bun run build
bunx cap sync

Ensuite, expédiez une mise à jour normale dans l'app store.

Capgo voie

Pour une itération sécurisée du niveau web :

bun run build
bunx @capgo/cli@latest bundle upload --channel production --delta

Rafraîchissez régulièrement votre ligne de base native si vous avez ajouté récemment un grand nombre d'actifs à durée de vie longue. Une nouvelle construction de magasin intègre cette nouvelle ligne de base, ce qui réduit les différences futures Capgo.

4. Utilisez les canaux pour garder la taille de la mise à jour petite

Une mise à jour « mince » ne concerne pas seulement les mégaoctets. C'est aussi le nombre de dispositifs qui reçoivent la mise à jour avant de savoir si elle est bonne.

Capgo’s système de canaux est la manière la plus propre de contrôler cela :

  • staging pour les tests de qualité
  • beta pour les testeurs invités
  • production pour tout le monde
  • hotfix pour la récupération d'urgence

A un flux simple ressemble à ceci :

  1. Envoyez vers staging.
  2. Validez sur des appareils réels.
  3. Sortez progressivement, qu'il s'agisse de canaux contrôlés ou de lancement basé sur des pourcentages.
  4. Revenez immédiatement si la santé baisse.

Si votre application a plusieurs baselines natives dans la wild, associez les canaux avec la ciblage de version. Cela empêche les paquets incompatibles ou trop lourds d'atteindre les anciens binaires.

Pour les équipes qui veulent même des boucles de revue plus serrées, Capgo fonctionne également bien pour les prévisions de PR. Cela permet aux produits, à la QA et aux parties prenantes de tester les modifications JS uniquement sans attendre de nouvelles versions de TestFlight ou Play.

5. Si vous activez les mises à jour directes, optimisez la charge de démarrage

Plus vous voulez que l'mise à jour soit appliquée rapidement, plus votre chemin d'initialisation doit être discipliné.

Capgo’s comportement de mise à jour les docs recommandent explicitement de pairer directUpdate avec les mises à jour Delta. C'est le bon paramètre par défaut.

La deuxième barrière est notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

Si votre application ne signale pas prête dans la fenêtre de 10 secondes par défaut, ou dans ce que notifyAppReady() vous avez défini dans votre __CAPGO_KEEP_0__ config, __CAPGO_KEEP_1__ peut marquer cette version invalide et restaurer la version précédente valide. Ce comportement de reversion est ce que vous voulez en production, mais cela signifie également que vous devriez garder l'initialisation propre : appReadyTimeout you set in your Capacitor config, Capgo can mark that bundle invalid and restore the previous good version. That rollback behavior is what you want in production, but it also means you should keep startup clean:

  • au bon endroit notifyAppReady() Évitez le travail lent au moment de l'initialisation dans le chemin critique
  • Avoid slow boot-time work in the critical path
  • Enregistrez et restaurez l'état de l'application avec soin si vous rechargez immédiatement.
  • Testez les scénarios de réseau mauvais et de périphériques de faible performance avant une mise à l'échelle large.

Si vous n'avez pas révisé cela récemment, le guide de notification notifyAppReady est digne d'être relu. 6. Utilisez les canaux d'actualisation internes au lieu de reconstructions natives inutiles. Beaucoup d'équipes mobiles gaspillent leur temps à construire des binaires pour des changements qui sont clairement web-only.

Si le changement est :

copie,

polissage de l'interface utilisateur,

  • flux de démarrage,
  • logique de l'écran de tarification,
  • If you have not reviewed it recently, the "notifyAppReady" guide is worth re-reading.
  • 6. Use internal update channels instead of unnecessary native rebuilds
  • branchement d'analytique,
  • drapeaux de fonctionnalité,
  • alors une mise à jour API est souvent l'artefact de revue le plus rapide.

Cela signifie moins de rebuilds natives, moins de changement de flux de TestFlight et un boucle de feedback plus serrée pour l'équipe. Il s'agit d'un des avantages les moins utilisés de Capgo: vous pouvez déplacer plus de travail de revue et de QA dans la voie OTA sans briser la frontière native/web.

That means fewer native rebuilds, less TestFlight churn, and a tighter feedback loop for the team. It is one of the most underused benefits of Capgo: you can move more review and QA work into the OTA lane without breaking the native/web boundary.

mise en scène avec un ID d'application mobile unique couvre une méthode pratique pour garder cela propre au fil du temps. 7. Gardez séparé lean de secret

Les petits paquets et les paquets sécurisés résolvent des problèmes différents.

Les canaux contrôlent l'éligibilité. Ils ne rendent pas un paquet confidentiel par eux-mêmes.

Si vous avez besoin de garanties de livraison plus fortes :

protectedTokens

Cela ne rend pas la taille de la mise à jour sans importance. Il suffit de dire que vous devriez optimiser pour les deux dimensions :

  • se concentrer sur la vitesse,
  • chiffrer pour le contrôle de la livraison,
  • canaux pour le contrôle de la mise en production,
  • retour en arrière pour la récupération.

Un workflow pratique « lean Capgo »

Si vous voulez un modèle opérationnel simple par défaut, utilisez celui-ci :

  1. Maintenez les voies de publication natives et OTA séparées.
  2. Téléchargez les modifications JS avec --delta par défaut.
  3. Utilisez staging et les canaux avant beta Regardez production.
  4. mettre à jour les statistiques et les journaux après le lancement, et non seulement avant. Transformez les PRs en prévisualisations installables lorsque la construction native n'est pas nécessaire.
  5. Maintenez les médias importants et changeants hors du bundle lorsque cela est possible.
  6. Rafraîchissez la base native après une croissance majeure des actifs ou des modifications natives.
  7. __CAPGO_KEEP_0__
  8. Traitez et annulez le comportement comme partie de l'ingénierie de la mise en production, et non comme des triviaux de configuration. notifyAppReady() Cette combinaison reste rapide pendant plus longtemps que l'approche commune « envoyez simplement ce qui a changé ».

Réflexion finale

Pour les équipes __CAPGO_KEEP_0__, « maigre et rapide » n'est pas juste un problème de taille de paquet.

For Capgo teams, “lean and fast” is not just a bundle-size problem.

Utilisez les mises à jour Delta pour la taille du payload, les canaux pour la taille de la mise en route et les annulations pour la taille de l'échec. Une fois que vous pensez à l'OTA de cette façon, vos mises à jour restent rapides même lorsque l'application, l'équipe et la base d'utilisateurs deviennent plus grandes.

Continuez à partir de Comment garder les mises à jour __CAPGO_KEEP_0__ maigres et rapides

Keep going from How to Keep Capgo Updates Lean and Fast

Comment garder les mises à jour __CAPGO_KEEP_0__ maigres et rapides How to Keep Capgo Updates Lean and Fast Canal Utilisez les mises à jour Delta pour la taille du payload, les canaux pour la taille de la mise en route et les annulations pour la taille de l'échec. Une fois que vous pensez à l'OTA de cette façon, vos mises à jour restent rapides même lorsque l'application, l'équipe et la base d'utilisateurs deviennent plus grandes. pour les détails d'implémentation dans les canaux, Canaux pour les détails d'implémentation dans les canaux, Canaux pour les détails d'implémentation dans les canaux, Solution de test bêta pour le flux de travail du produit dans la Solution de test bêta, et Solution de ciblage de version pour le flux de travail du produit dans la Solution de ciblage de version.

Mises à jour en direct pour les applications Capacitor

Lorsqu'un bug de la couche web est en ligne, expédiez la correction par le biais de Capgo au lieu d'attendre des jours pour l'approbation de la boutique d'applications. Les utilisateurs reçoivent la mise à jour en arrière-plan tandis que les modifications natives restent dans le chemin de revue normal.

Commencez maintenant

Dernières actualités de notre Blog

Capgo vous donne les meilleures informations dont vous avez besoin pour créer une application mobile véritablement professionnelle.