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

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

Cela signifie généralement trois choses :

La mise à jour téléchargée est petite.
La mise à jour est contrôlée.
La récupération est instantanée si quelque chose se produit mal.

Le même conseil « gardez les mises à jour OTA minces » 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 version, et chiffrage de bout en bout facultatif La mise à jour delta permet aux équipes de publier des mises à jour plus fréquentes sans augmenter la taille du téléchargement. Les canaux permettent aux équipes de gérer plusieurs versions de l'application en même temps. Les annulations automatiques permettent aux équipes de revenir à une version précédente si une mise à jour se révèle problématique. Le ciblage de version permet aux équipes de cibler des versions spécifiques de l'application pour les mises à jour. Le chiffrage de bout en bout facultatif permet aux équipes de chiffrer les données de l'application pour une sécurité supplémentaire..

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

L'économie 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 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 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
Une meilleure expérience avec les mises à jour directes
Moins de bande passante gaspillée sur les lancements ou les annulations échoués
Un rayon d'action plus réduit lors de la mise en production ou de la mise en scène d'une mise à jour

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

Faites seulement cela si vous ne faites qu'une chose.

Capgo’s Mises à jour Delta envoyer 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 les performances 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 souhaitez que CI reste strict, utilisez --delta-only afin que personne ne tombe accidentellement en arrière sur les 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 mélangées, 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 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 des bagages JavaScript

Les grands assets sont là où les bundles OTA sont discrètement gonflés.

Some practical rules:

Ne pas intégrer d'images ou de médias volumineux directement dans le JavaScript lorsque des fichiers d'actifs normaux suffisent.
Conservez le contenu en constante évolution sur votre propre CDN ou API si cela ne doit pas vivre à l'intérieur du bundle d'application embarqué.
Faites attention aux images de marketing, aux vidéos d'accueil et aux actifs de campagne ponctuels 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 pile de médias non liés.

3. Conservez les versions 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 natives,
des changements de permissions,
capacitor.config.ts des changements,
toute modification d'état de projet natif iOS ou Android.

Cette ligne compte également 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 à long terme.

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

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 normale dans l'app store.

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 également votre ligne de base native régulièrement si vous avez ajouté récemment un grand nombre d'actifs à long terme. Une mise à jour de magasin fraîche 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égère » ne concerne pas seulement les mégaoctets. C'est également le nombre de dispositifs qui 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 sur staging.
Valider sur des appareils réels.
Lancer progressivement, qu'il s'agisse de canaux contrôlés ou de lancement 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 version. Cela empêche les bundles incompatibles ou trop lourds d'atteindre les anciens binaires.

Pour les équipes qui veulent des boucles de revue encore plus serrées, Capgo fonctionne également bien pour prévisions de PR. Cela permet aux producteurs, 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'une des mises à jour soit appliquée rapidement, plus votre chemin d'initialisation doit être discipliné.

Capgo’s 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 de sécurité est notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

Si 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 valide. Ce comportement de reprise est ce que vous voulez en production, mais cela signifie également que vous devez garder le démarrage propre : notifyAppReady() Appel 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 travaux 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 bas de gamme avant une mise à l'échelle large
Si vous n'avez pas révisé cela récemment, le
guide notifyAppReady

vaut la peine de le relire. 6. Utilisez les canaux d'actualisation internes au lieu de rebâtir nativement inutilement 6. Utilisez les canaux d'actualisation internes au lieu de rebâtir nativement inutilement.

6. Utilisez les canaux d'actualisation internes au lieu de rebâtir nativement inutilement.

Beaucoup d'équipes mobiles perdent du 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,
branchement des analyses,
drapeaux de fonctionnalité,
affichage de réponse ou API prompt,

alors une mise à jour Capgo est souvent l'artefact de revue le 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 rompre 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 garder cela propre au fil du temps.

7. Gardez les éléments de confidentialité séparés des secrets

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 :

activez Chiffrement de mise à jour en temps réel,
utilisez stockage personnalisé ou livraison auto-hébergée,
gardez les clés privées uniquement dans les workflows CI ou opérateurs sécurisés.

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

optimez 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èle d'exploitation par défaut simple, utilisez ceci :

Maintenez les voies de publication natives et OTA séparées.
Téléchargez les modifications JS avec --delta par défaut.
Utilisez staging et beta les canaux avant production.
Regardez mettre à jour les statistiques et les journaux après le lancement, et non juste avant.
Convertir les PRs en prévisualisations installables lorsque la construction native n'est pas nécessaire.
Maintenez les grandes médias changeantes hors du bundle chaque fois que possible.
Rafraîchir la base native après une croissance majeure d'actifs ou des changements natifs.
Traitez notifyAppReady() et le comportement de reversion comme partie de l'ingénierie de la mise en production, et non comme des triviaux de configuration.

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

Réflexion finale

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

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

Utilisez les mises à jour Delta pour la taille du payload, les canaux pour la taille de déploiement et les annulations 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 la section Comment garder les mises à jour Capgo légères et rapides

Si vous utilisez Comment garder les mises à jour Capgo légères et rapides pour planifier la routage des canaux et le déploiement étalé, connectez-le à Canal pour les détails d'implémentation dans Canal, Canal pour les détails d'implémentation dans Canal, Canal pour les détails d'implémentation dans Canal, Solution de test bêta pour le flux de produit dans la Solution de test en bêta, et Solution de ciblage de version pour le flux de produit dans la Solution de ciblage de version.