Aller au contenu principal
Mises à jour de production

Proposez le dernier correctif à tous vos utilisateurs

Envoyez un nouveau bundle web depuis CLI ou votre CI. Les appareils le téléchargent en arrière-plan et l'exécutent lors du prochain passage de l'app au premier plan. Gérez le déploiement progressif par pourcentage, surveillez-le dans Observe et effectuez un rollback en cas de problème.

Aucune carte bancaire requise
Rollback automatique intégré
Mises à jour de la couche web uniquement

Le problème

A store release is a slow way to ship a small fix

Le parcours de correction via les stores uniquement

1

Identifier le bug

Le monitoring ou le support signale un écran cassé. Le correctif ne nécessite que quelques lignes de JavaScript ou de CSS.

2

Générer un nouveau binaire

Vous incrémentez la version, compilez pour iOS et Android, et préparez deux soumissions sur les stores.

3

Attente de la validation

La revue par les stores prend souvent 24 à 48 heures, parfois bien plus. Un rejet relance tout le processus d'attente.

4

Attendre la mise à jour des utilisateurs

Après l'approbation, chaque utilisateur doit encore installer la nouvelle version. D'ici là, ils utilisent l'ancien code.

Chaque étape rallonge le délai entre la disponibilité du correctif et son exécution sur les appareils de vos utilisateurs.

Why store fixes reach users slowly

24–48h+

Temps de revue habituel des stores

Apple et Google examinent chaque nouveau binaire. La revue dure souvent 24 à 48 heures, parfois bien plus, et un rejet impose une nouvelle soumission.

Par utilisateur

Store updates depend on each device

Une mise à jour du store n'atteint un appareil que lorsque l'utilisateur, ou son paramètre de mise à jour automatique, l'installe. Certains appareils restent sur d'anciens builds pendant longtemps.

2 stores

Deux soumissions pour chaque correctif

Le même correctif web doit passer par l'App Store et Google Play séparément, chacun avec sa propre revue et sa propre release.

La solution

Comment un live update atteint vos utilisateurs

C'est le comportement de mise à jour par défaut de Capgo. Aucun prompt de mise à jour, aucun redémarrage forcé et aucune soumission aux stores pour les changements de la couche web.

Flux de mise à jour par défaut

  1. L'application recherche des mises à jour

    Lorsque l'application passe au premier plan, et toutes les 10 minutes lorsqu'elle reste ouverte, l'updater demande à Capgo le dernier bundle du canal.

    Au premier plan

  2. Téléchargement en arrière-plan

    Le nouveau bundle se télécharge pendant que l'utilisateur continue d'utiliser la version actuelle. Avec les delta updates, seuls les fichiers modifiés sont téléchargés.

    Sans interruption

  3. Basculement au prochain redémarrage

    Lorsque l'utilisateur quitte l'application, l'updater installe le bundle. À la prochaine ouverture, la nouvelle version est lancée.

    Prochain premier plan

Vous voulez que vos utilisateurs voient la nouvelle version dès l'ouverture ? Les modes de mise à jour directe l'appliquent au lancement, pendant l'affichage de l'écran de splash.

Voir les mises à jour directes

Doc sur le comportement des mises à jour

Comment ça marche

Comment les équipes de prod déploient un correctif avec Capgo

Une release type pour une app Capacitor déjà sur les stores. Chaque commande ci-dessous provient de la doc Capgo CLI.

  1. Configurez l'updater une seule fois

    Lancez l'assistant de configuration, puis assurez-vous que votre app appelle notifyAppReady() au démarrage. Un bundle qui n'effectue jamais cet appel fait un rollback automatique.

    npx @capgo/cli@latest init
# in your app start-up code
await CapacitorUpdater.notifyAppReady()
    Docs de notifyAppReady()

  2. Envoyez le correctif sur une partie de la prod

    Utilisez --delta pour que les appareils ne récupèrent que les fichiers modifiés, et --rollout pour commencer avec un petit pourcentage d'appareils. Les autres restent sur le bundle stable.

    npx @capgo/cli@latest bundle upload --channel production --delta --rollout 5
    Docs sur le déploiement progressif

  3. Laissez Capgo stopper un mauvais déploiement

    Activez l'auto-pause avec un seuil de taux d'échec (500 points de base correspondent à 5 %). Si les échecs dépassent ce seuil, Capgo effectue un rollback du déploiement. Vérifiez la nouvelle version dans Observe pendant l'exécution.

    npx @capgo/cli@latest channel set production \
  --auto-pause-enabled \
  --auto-pause-failure-rate-bps 500 \
  --auto-pause-action rollback
    Consulter la doc Observe

  4. Déployer pour tout le monde

    Quand les chiffres sont bons, déployez le bundle sur tous les appareils du canal. Sinon, renvoyez la cohorte de déploiement vers la version stable.

    npx @capgo/cli@latest channel set production --rollout-promote
# or, if something looks wrong
npx @capgo/cli@latest channel set production --rollout-rollback
    Doc sur les rollbacks

Conçu pour les releases de production

Les outils que les équipes de production utilisent pour déployer souvent sans surprendre les utilisateurs.

Mises à jour delta

Envoyez avec --delta et les appareils ne téléchargent que les fichiers modifiés depuis leur bundle actuel. Les assets volumineux qui changent rarement ne sont téléchargés qu'une seule fois.

  • Téléchargements réduits pour les utilisateurs sur réseaux lents ou limités
  • Par défaut, les mises à jour s'appliquent entre deux sessions, pas en plein milieu d'une session
Docs des delta updates

--delta

Seuls les fichiers modifiés sont téléchargés

Déploiement progressif avec pause automatique

Envoyez un nouveau bundle à une fraction fixe et aléatoire d'un canal pendant que les autres restent sur le bundle stable. Augmentez le pourcentage, propagez-l’ou effectuez un rollback depuis le CLI ou la console.

  • L'auto-pause peut suspendre ou effectuer un rollback d'un déploiement progressif si le taux d'échec dépasse votre seuil
  • Observe compare la nouvelle version avec la précédente avant d'augmenter l'exposition
Docs sur le déploiement progressif

1–5%

Une première étape de déploiement typique

Rollback automatique

Chaque mise à jour doit prouver qu'elle démarre. Si un nouveau bundle n'appelle pas notifyAppReady() à temps, l'appareil revient au dernier bundle fonctionnel et marque le nouveau comme échoué.

  • Le rollback se déclenche si notifyAppReady() n'est pas appelé dans l'appReadyTimeout (10 secondes par défaut)
  • Effectuez un rollback de tout un canal vers n'importe quel bundle antérieur de son historique
Docs de notifyAppReady()

10 s

appReadyTimeout par défaut avant le rollback automatique

Livraison compatible avec la revue des stores

Capgo livre la couche web Capacitor : JavaScript, CSS et assets. Cela ne modifie pas le binaire natif, les plugins, les permissions, les entitlements ou les métadonnées du store. La validation par le store est spécifique à l'app, vous restez donc responsable de la conformité aux politiques et de l'approbation.

  • Utilisez une release native sur le store si les capacités natives, les plugins, les permissions ou les métadonnées changent
  • Indiquez clairement aux réviseurs la fonctionnalité prévue de l'app et le mode de mise à jour de la couche web
  • Consultez les politiques Apple et Google actuelles avant chaque soumission

Ce que font les équipes de production avec

Gestion quotidienne des releases une fois les live updates en place. Chaque carte renvoie vers la doc.

Corrections de bugs critiques

A broken checkout or login screen gets a web-layer fix. Upload it and devices pick it up on their next update check.

Doc sur le comportement des mises à jour

Modifications de texte et de contenu

Corrigez les textes, mettez à jour l'aide ou remplacez des images et autres assets du bundle sans recompiler un nouveau binaire.

Docs de compatibilité native

Santé des releases dans Observe

Comparez un nouveau bundle avec le précédent : taux d'erreur, temps de lancement et de WebView, et marqueurs de déploiement par version.

Consulter la doc Observe

Adoption plus rapide grâce aux notifications

Après avoir modifié le bundle d'un canal, envoyez une notification de mise à jour silencieuse pour que les appareils vérifient immédiatement au lieu d'attendre leur prochain passage au premier plan.

Envoyer une notification de mise à jour

Protégez les anciens builds natifs

Bloquez les mises à jour majeures sur un canal pour qu'un bundle nécessitant de nouveaux code natifs n'atteigne jamais un binaire plus ancien.

Docs sur le ciblage de version

Faites un rollback depuis l'historique du canal

Choisissez n'importe quel bundle précédent dans l'onglet History du canal pour le rendre à nouveau actif sur tous les appareils de ce canal.

Doc sur les rollbacks

Une infrastructure qui propulse déjà des apps en production

Capgo livre des live updates à des apps en production depuis 2021.

Mises à jour par mois
1 Md+
Appareils atteints
90 M+
Apps utilisant Capgo
4,7k+
Latence API typique
~50 ms

Solutions par type d'équipe

Trouvez la solution adaptée aux besoins de votre équipe

Enterprise

Déploiements multi-applications et multi-équipes

Startups

Déployez vite, sans la complexité

Développeurs solo

Essai gratuit de 14 jours, CLI upload

Agences

Gérez plusieurs applications clients

Apps développées avec Capacitor

Les apps à fort trafic nécessitent des changements d'UI fiables en production

La météo, la santé publique et les télécoms dépendent d'interfaces, d'alertes et de navigations précises. Les mises à jour en production permettent de déployer des correctifs d'interface approuvés tout en surveillant l'adoption avant de généraliser le déploiement.

Windy.com - Icône de l'application de prévisions météo MÉTÉO

Windy.com - Prévisions météo

Application météo où les cartes, les alertes et la navigation nécessitent un déploiement progressif maîtrisé.

Installations Google Play
32,9 M
Note du store
4.7
Icône de l'application Conecte SUS MÉDICAL

Connectez SUS

Application de santé publique nécessitant des mises à jour rapides et fiables pour les conseils et les services.

Installations Google Play
27,7 M
Note du store
4.6
Icône de l'application Mi Orange OUTILS

Mi Orange

Application de télécom où les alertes et l'interface du compte changent fréquemment.

Installations Google Play
9,3 M
Note du store
4.2

Témoignages clients

Ce que disent les équipes qui déploient avec Capgo

5.0/5 noté par les équipes de développeurs 9,400+ équipes Lire les avis
Portrait de Sergiu S

Sergiu S

Lead Developer, drivolino GmbH

« Le plugin Capgo Capacitor Updater a totalement transformé notre façon de déployer les mises à jour. Ce qui prenait des jours ne prend plus que quelques minutes. »

Kapil

Fondateur, NuTriQ

“Pouvoir pousser instantanément des mises à jour OTA en production sans attendre les cycles complets de validation de l’App Store est un avantage opérationnel énorme.”

Portrait de Michael Haberler

Michael Haberler

nethead emeritors

« Beau travail sur le plugin updater. Il fonctionne parfaitement pour moi, et les live updates sont un super accélérateur pour tester rapidement. »

FAQ

Questions des équipes de production

Comment les mises à jour atteignent les appareils et que faire en cas de problème.

Quand les utilisateurs reçoivent-ils un live update ?

Par défaut, l'app cherche des mises à jour lorsqu'elle passe au premier plan et toutes les 10 minutes lorsqu'elle reste ouverte. Elle télécharge le nouveau bundle en arrière-plan, l'installe quand l'utilisateur quitte l'app, et l'exécute lors de la prochaine ouverture. Le paramètre autoUpdate modifie ce comportement.

Doc sur le comportement des mises à jour

Can devices pick up an urgent fix faster?

Oui. Après avoir modifié le bundle d'un canal, envoyez une notification de mise à jour depuis la console, ou ajoutez --send-update-notification lors de l'upload du bundle. Les appareils reçoivent une notification push silencieuse et vérifient immédiatement. Cela nécessite Capgo Notifications avec des identifiants push iOS et Android. La livraison est faite au mieux : une app hors ligne ou fermée de force vérifiera lors de son prochain lancement.

Envoyer une notification de mise à jour

Que se passe-t-il si une mise à jour fait planter l'app ?

Si un nouveau bundle n'appelle pas notifyAppReady() sous 10 secondes (l'appReadyTimeout par défaut), l'appareil revient au dernier bundle fonctionnel et marque le nouveau comme échoué. Pour les bugs qui n'empêchent pas le démarrage de l'app, effectuez un rollback du déploiement progressif ou choisissez un bundle précédent dans l'historique du canal.

Doc sur les rollbacks

Comment déployer d'abord auprès de quelques utilisateurs ?

Utilisez l'option --rollout pour envoyer le bundle à une fraction aléatoire et persistante du canal, pendant que les autres restent sur la version stable. Augmentez le pourcentage, propagez la version ou effectuez un rollback depuis CLI ou la console. L'auto-pause peut stopper le déploiement si le taux d'échec dépasse un seuil.

Docs sur le déploiement progressif

Que ne peut pas changer un live update ?

Les live updates remplacent la couche web : JavaScript, HTML, CSS et les assets. Les plugins natifs, les mises à jour Capacitor, les changements dans capacitor.config et les fichiers de projet iOS ou Android nécessitent une release sur les stores. Capgo vérifie la compatibilité native des bundles lors de l'upload, et les canaux peuvent bloquer les mises à jour vers des binaires plus anciens.

Docs de compatibilité native

Déployez votre prochain correctif via live update

Testez le flux complet sur votre propre application pendant l'essai : envoyez un bundle, lancez un déploiement progressif sur quelques appareils, puis effectuez un rollback.