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

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

Cela signifie généralement trois choses :

1. Le téléchargement est petit.
2. La mise en production est contrôlée.
3. La récupération est instantanée 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, canaux, annulations automatiques, ciblage de versionet chiffrage de bout en bout optionnel Si vous utilisez ceux-ci ensemble, vous obtenez des payloads plus petits, des installations plus rapides et beaucoup moins de chaos opérationnel..

La minceur compte même lorsque le MAU reste le même

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

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.

__CAPGO_KEEP_0__ est un terme protégé, il ne doit pas être traduit. __CAPGO_KEEP_1__ est un terme protégé, il ne doit pas être traduit. __CAPGO_KEEP_2__ est un terme protégé, il ne doit pas être traduit.

• 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 réduit lors de la mise en ligne ou de la mise en ligne 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 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 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

If vous souhaitez que CI reste strict, utilisez --delta-only afin que personne ne tombe accidentellement sur des téléchargements de paquets 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 des bagages JavaScript

Les actifs volumineux sont là où les paquets OTA se font discrètement gonfler.

Quelques règles pratiques :

• Ne faites pas d'images ou de médias volumineux en ligne dans JavaScript lorsque un fichier d'actif normal le fera.
• Conservez le contenu qui change fréquemment sur votre propre CDN ou API si cela ne doit pas vivre à l'intérieur du paquet d'application livré.
• Prenez soin des images de marketing, des vidéos d'accueil et des actifs de campagne uniques qui sont remplacés à chaque mise à jour.
• 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 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 une grande quantité de médias non liés.

3. Gardez les versions natives pour les vraies modifications 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 modifications
• toute modification qui modifie l'état du projet native iOS ou Android.

Cette ligne compte également pour la performance. Si vous continuez à insérer des modifications structurelles majeures 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 modifications de plugin, les modifications de permission 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 en toute sécurité :

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 à vie longue. Une mise à jour de magasin fraîche 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 » 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 Le 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 :

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

Si votre application a plusieurs baselines natives dans la wild, associez les canaux avec ciblage de version. Cela garde les paquets incompatibles ou trop lourds loin des anciens binaires.

Pour les équipes qui veulent même des boucles de revue plus serrées, Capgo fonctionne également bien pour prévisualisations de PRCela permet aux produits, aux 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 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 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 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 la charge de démarrage 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:

• Call notifyAppReady() en place
• Évitez les tâches de démarrage lent dans la voie critique
• Sauvegardez et restaurez l'état de l'application avec soin si vous rechargez immédiatement
• Testez les scénarios de mauvaise connexion et de périphériques bas de gamme avant une mise à l'échelle large

Si vous n'avez pas révisé cela récemment, le guide de la notification d'appareil prêt est digne d'être relu. 6. Utilisez les canaux d'actualisation internes au lieu de rebuilds 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,

• notifyAppReady guide
• is worth re-reading
• flux de prise en main
• logique de l'écran de tarification
• branchement d'analytiques
• drapeaux de fonctionnalité
• affichage de réponse ou de prompt API

puis une mise à jour Capgo 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 plus sous-estimé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 garder cela propre au fil du temps.

7. Gardez séparé lean de secret

Les petits bundles et les bundles 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 chiffrage de mise à jour en temps réel,
• utilisez stockage personnalisé ou livraison auto-hébergée,
• __CAPGO_KEEP_0__

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

• optez pour la rapidité,
• chiffrer pour le contrôle de la livraison,
• canaux pour le contrôle de déploiement,
• retour en arrière pour la récupération.

Un workflow pratique « lean Capgo »

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

1. Maintenez séparés les chemins de version native et OTA.
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. Utilisez
6. Conservez les grandes ressources multimédias fréquemment modifiées hors du bundle chaque fois que possible.
7. Rafraîchissez la base native après une croissance majeure des actifs ou des changements natifs.
8. Traitez notifyAppReady() et le comportement de reversion comme partie de l'ingénierie de la mise à jour, et non comme triviaux de configuration.

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

Réflexion finale

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

C'est un problème de conception de mise à jour.

Utilisez les mises à jour Delta pour la taille de la charge utile, les canaux pour la taille de la mise à jour et les reversions 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.