Comment conserver les mises à jour de Capgo légères et rapides

La meilleure mise à jour en direct est celle que vos utilisateurs ne remarquent même pas.

Cela signifie généralement trois choses :

La téléchargement est petit.
La mise en production est contrôlée.
La récupération est instant si quelque chose se produit mal.

Le même conseil « gardez OTA mince » qui fonctionne dans le monde React Native s'applique également à Capgo. La différence est que Capgo donne aux équipes Capacitor quelques leviers supplémentaires : Mises à jour delta, context, Page/area, Enterprise product/pricing pageRole Short UI label or navigation item.

Seen in

page enterprise.astro

One useful Capgo-specific detail: Capgo MAU is effectively the number of monthly active devices that contacted the update service in the last 30 days.

enterprise_delta_updates

Téléchargements plus rapides sur les réseaux cellulaires ou les Wi-Fi faibles
Une meilleure expérience avec Mises à jour directes
Moins de bande passante gaspillée sur les lancements ou les annulations de versions
Un rayon d'action plus petit lors du test ou de la mise en scène d'une version

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

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

Si vous faites seulement une chose, faites celle-ci.

Capgo’s Envoient uniquement les fichiers qui ont changé entre les versions au lieu de télécharger à nouveau le bundle web complet. C'est la plus grande victoire pour la performance des OTA de routine. Lorsque votre passe de QA est terminée :

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

Delta mises à jour

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

Si vous souhaitez que CI reste strict, utilisez --delta-only afin que personne ne tombe accidentellement sur des téléchargements de bundles 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 des versions de plugins mixtes, les appareils plus anciens qui ne supportent pas la livraison delta basée sur le manifeste ne pourront pas 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 assets comme des assets, pas comme du bagage JavaScript

Les grands assets sont là où les bundles OTA se font tranquillement gonfler.

Quelques règles pratiques :

Ne faites pas d'images ou de médias volumineux en ligne dans le JavaScript lorsque un fichier d'asset normal suffit.
Conservez le contenu qui change fréquemment sur votre propre CDN ou API si cela ne doit pas vivre à l'intérieur du bundle d'application expédié.
Prenez soin des images de marketing, des vidéos d'accueil et des assets de campagne uniques qui sont remplacés à chaque release.
Maintenez les actifs stables dans leur état stable. 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 rapide même lorsque votre application grandit. Le pire modèl’est une petite correction de l'interface utilisateur qui oblige les utilisateurs à télécharger une grande quantité de médias non liés.

3. Maintenez les sorties natives pour les changements natives réels

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

C'est pas le bon canal pour :

de nouveaux plugins natives
les changements de permissions
capacitor.config.ts les changements
toute modification 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 délibérément :

Voie native

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

bun run build
bunx cap sync

Ensuite, expédiez une mise à jour de magasin normale.

Capgo voie

Pour une itération de la couche web sécurisée :

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

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

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

Une mise à jour « léger » n'est pas seulement question de mégaoctets. C'est aussi question de savoir combien d'appareils reçoivent la mise à jour avant de savoir qu'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

Un flux simple ressemble à ceci :

Télécharger vers staging.
Valider sur des appareils réels.
Déployer progressivement, qu'il s'agisse de canaux contrôlés ou de déploiement basé sur un pourcentage.
Régresser immédiatement si la santé diminue.

Si votre application possède plusieurs baselines natives dans la wild, associez les canaux avec ciblage de versionCela 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 prévisions de PRCe qui permet aux produits, aux équipes QA et aux parties prenantes de tester les modifications JS uniquement sans attendre de nouvelles versions de TestFlight ou Play internes.

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

Les mises à jour doivent être appliquées le plus rapidement possible, ce qui signifie que votre chemin d'initialisation doit être discipliné.

Capgo’s le comportement de mise à jour les documents recommandent explicitement de pairer directUpdate avec les mises à jour Delta. C'est la bonne valeur par défaut.

La deuxième garde-fou 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 vous avez configuré 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 devez garder l'initialisation propre : notifyAppReady() Appeler 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:

Preservez les termes de produit/branche et les termes de développeur exactement. notifyAppReady() en place
Évitez les tâches de démarrage lent dans le chemin critique
Sauvegardez et restaurez l'état de l'application avec soin si vous rechargez immédiatement
Testez les scénarios de réseau instable et de périphériques de faible performance avant une mise à l'échelle large

Si vous n'avez pas revu cela récemment, le guide de notification d'appareil prêt vaut la peine de le relire. 6. Utilisez les canaux d'actualisation internes au lieu de reconstructions natives inutiles

Beaucoup d'équipes de mobile gaspillent leur temps en construisant des binaires pour des changements qui sont clairement web-only.

Si le changement est :

copie,

polissage de l'interface utilisateur,
__CAPGO_KEEP_0__
flux de prise en charge,
logique de l'écran de tarification,
branchement des analyses,
drapeaux de fonctionnalité,
affichage de la réponse ou API prompt,

puis une mise à jour Capgo est souvent l'artefact de revue plus rapide.

Ce qui 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.

Notre guide sur mise en scène avec un ID d'application mobile unique couvre une méthode pratique pour conserver cela propre au fil du temps.

7. Garder lean séparé des secrets

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

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

Si vous avez besoin de garanties de livraison plus fortes :

activez la cryptage de mise à jour en direct,
utilisez un stockage personnalisé ou une livraison auto-hébergée,
gardez les clés privées uniquement dans les workflows de l'opérateur sécurisés ou les CI.

Cela ne signifie pas que la taille de la mise à jour est sans importance. Il s'agit simplement de vous faire optimiser pour les deux dimensions :

maigre pour la vitesse
crypté pour le contrôle de la livraison
les canaux pour le contrôle de déploiement
la reversion pour la récupération.

Avec un workflow ‘Capgo’ pratique

Si vous souhaitez un modèle d'exploitation simple par défaut, utilisez ceci :

Maintenez les voies de publication natives et OTA séparées.
Envoi des modifications de JS avec --delta par défaut.
Utilisez staging et beta les canaux avant production.
Regardez les statistiques et les journaux de mise à jour après le lancement, et non seulement avant.
Transformez les PR en prévisualisations installables lorsque la construction native n'est pas nécessaire.
Évitez les grandes ressources multimédias fréquemment modifiées dans le bundle autant que possible.
Actualisez la base native après une croissance majeure d'actifs ou des changements natifs.
Tout comme notifyAppReady() et le comportement de reversion doivent être considérés comme partie de l'ingénierie de la mise en production, et non comme des détails de configuration.

Cette combinaison reste rapide beaucoup plus longtemps que l'approche commune « envoyez simplement tout ce qui a changé ».

Pensée finale

Pour les équipes Capgo, « léger et rapide » n'est pas juste un problème de taille de bundle.

C'est un problème de conception de mise en production.

Utilisez les mises à jour Delta pour la taille du payload, les canaux pour la taille de déploiement et les reversions pour la taille d'erreur. Une fois que vous pensez à l'OTA de cette manière, vos mises à jour restent rapides même lorsque l'application, l'équipe et la base d'utilisateurs deviennent plus grandes.

Continuez de How to Keep Capgo Updates Lean and Fast

Si vous utilisez Comment garder les mises à jour Capgo de Capgo Lean and Fast planifier la routage du canal et la mise en production étape par étape, connectez-l’à Canaux détails d'implémentation dans les Canaux Canaux détails d'implémentation dans les Canaux 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. écrit par