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

La meilleure mise à jour en temps réel est celle que vos utilisateurs remarquent à peine.

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 instantanée si quelque chose se produit.

Le même conseil de mise à jour « OTA lean » qui fonctionne dans le monde de 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 (facultatif) __CAPGO_KEEP_0__.

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

Le lean compte même lorsque le MAU reste le même.

Un détail utile spécifique à Capgo : le MAU de Capgo est effectivement le nombre de périphériques 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 une astuce pour réduire le comptage du MAU. Cela compte parce qu'il améliore les parties que les utilisateurs et les équipes ressentent vraiment :

Telechargements plus rapides sur les réseaux cellulaires ou les Wi-Fi faibles
Mieux expérient les Mises à jour directes
Moins de bande passante gaspillée sur les lancements ou les annulations échoués
Zone d'impact plus petite lors du test ou de la mise en scène d'une mise à jour

Mises à jour lean 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-là.

Capgo’s 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 la plus grande victoire unique pour la performance des mises à jour OTA de routine.

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

Une fois que votre passe de QA est terminée :

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 les versions de plugins mixtes, les appareils plus anciens qui ne supportent pas la livraison de manifeste basée sur les delta ne pourront pas télécharger cette mise à jour.

Cela compte encore plus si vous utilisez directUpdatecar 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 pas intégrer d'images ou de médias volumineux directement dans le code JavaScript lorsque des fichiers d'asset normaux suffisent.
Conservez le contenu changeant fréquemment sur votre propre CDN ou API si ce n'est pas nécessaire de le faire vivre à l'intérieur de la mise à jour du bundle d'application.
Faites attention avec les images de marketing, les vidéos d'abordage et les actifs de campagne uniques qui sont remplacés à chaque mise à jour.
Conservez 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 à mesure que votre application grandit. Le pire modèl’est une petite correction de l'interface utilisateur qui oblige les utilisateurs à télécharger un tas de médias non liés.

3. Conservez les mises à jour natives pour les changements natives réels

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

C'est pas le bon canal pour :

de nouveaux plugins natifs,
des changements de permissions,
capacitor.config.ts des changements,
tout ce qui modifie l'état du projet natif iOS ou Android.

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

Utilisez deux voies de lancement délibérément :

Voie native

Pour les modifications de plugin, les changements de permission et la configuration native :

bun run build
bunx cap sync

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

Capgo voie

Pour l'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 récemment ajouté un grand nombre d'actifs à long terme. 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. Il s'agit également de savoir combien de dispositifs reçoivent la mise à jour avant de savoir qu'elle est bonne.

Capgo's système de canal est la manière la plus propre pour 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.
Revenir immédiatement si la santé baisse.

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

Pour les équipes qui souhaitent des boucles de revue encore plus serrées, Capgo fonctionne également bien pour prévisions de PRCela 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 initiale

Plus vous voulez que l'application d'une mise à jour soit rapide, plus votre chemin d'initialisation doit être discipliné.

Le comportement d'Capgo la documentation explicite recommande de l'associer aux mises à jour Delta. C'est la bonne valeur par défaut. directUpdate La deuxième barrière est

__CAPGO_KEEP_0__'s notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

If votre application ne signale pas prête dans la fenêtre par défaut de 10 secondes, ou dans ce que vous avez défini dans votre __CAPGO_KEEP_0__ config, __CAPGO_KEEP_1__ peut marquer cette bundle comme invalide et restaurer la version précédente qui fonctionnait bien. Ce comportement de reprise est ce que vous voulez en production, mais cela signifie également que vous devriez garder le démarrage propre : notifyAppReady() Appelez 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:

Évitez les tâches de démarrage lent dans la voie critique notifyAppReady() 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 dispositifs de faible performance avant une mise en production large
Si vous n'avez pas révisé cela récemment, la
guide de notification d'appareil prêt

est à relire. 6. Utilisez les canaux d'actualisation internes au lieu de reconstructions natives inutiles window

config

A beaucoup d'équipes mobiles gaspillent du temps à construire des binaires pour des changements qui sont clairement web-unices.

Si le changement est :

copie ;
polissage de l'interface utilisateur ;
flux de prise en charge ;
logique de l'écran de tarification ;
branchement d'analytiques ;
drapeaux de fonctionnalité ;
affichage de réponse ou de prompt API ;

mises à jour Capgo sont souvent un artefact de revue plus rapide.

Cela signifie moins de rebuilds natives, moins de changement de TestFlight et un boucle de feedback plus serrée pour l'équipe. C'est l'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 environnement de pré-production avec un ID d'application mobile unique couvre une méthode pratique pour maintenir cela propre au fil du temps.

7. Gardez 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 ensemble confidentiel par eux-mêmes.

Si vous avez besoin de garanties de livraison plus solides :

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

Cela ne signifie pas que la taille des mises à jour est sans importance. Cela signifie simplement que vous devriez optimiser pour les deux dimensions :

pour la vitesse,
chiffré 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 souhaitez un modèl’opérationnel par défaut simple, utilisez ceci :

Maintenez les voies de publication natives et OTA séparées.
Téléchargez les modifications de JS avec --delta par défaut.
Utilisez staging et beta les canaux avant production.
Regardez Statistiques et journaux de mise à jour après le lancement, et non seulement avant.
Convertissez les PRs en prévisualisations installables lorsque la construction native n'est pas nécessaire.
Éloignez les médias importants et changeants de la charge utile chaque fois que possible.
Actualisez la base native après une croissance majeure des actifs ou des changements natifs.
Considérez notifyAppReady() et le comportement de reversion 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 ce qui a changé ».

Pensée finale

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

Pensée finale

Utilisez les mises à jour Delta pour la taille du payload, les canaux pour la taille de déploiement et les retours en arrière pour la taille de l'échec. Une fois que vous pensez à 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 à partir de Comment conserver les mises à jour de Capgo légères et rapides

Si vous utilisez Comment conserver les mises à jour de Capgo légères et rapides pour planifier la routage des canaux et le déploiement étalé, connectez-l’avec Canalisation contexte":"Nom de la fonctionnalité de canaux de mise à jour de Capgo. Page/zone : page de marketing de solutions de Capgo. Rôle : étiquette de navigation ou élément de navigation court. Vu dans : page solutions/white-label.astro. Clé de message `solutions_white_label_visual_cell2_value` (Valeur de cellule visuelle de Solutions White Label)." pour le détail d'implémentation dans Canalisation, Canalisation contexte":"Nom de la fonctionnalité de canaux de mise à jour de Capgo. Page/zone : page de marketing de solutions de Capgo. Rôle : étiquette de navigation ou élément de navigation court. Vu dans : page solutions/white-label.astro. Clé de message `solutions_white_label_visual_cell2_value` (Valeur de cellule visuelle de Solutions White Label)." pour le détail d'implémentation dans Canalisation, Canalisation : Solution de test en bêta pour le flux de travail du produit dans la Solution de Test Beta, et Solution de ciblage de version pour le flux de travail du produit dans la Solution de ciblage de version.