Aller au contenu principal

Ciblage de version

Envoyez à chaque version native uniquement les bundles compatibles

Les utilisateurs effectuent leurs mises à jour sur les stores à leur propre rythme, ce qui signifie que plusieurs versions natives de votre application sont actives simultanément. Capgo vérifie les dépendances natives de chaque bundle, bloque les mises à jour selon vos règles de version et peut diriger chaque version native vers son propre canal.

Vérifiez la compatibilité native avant l'upload

La compatibilité du bundle compare les packages natifs de votre projet avec le bundle actif sur le canal. Ajoutez --fail-on-incompatible dans votre CI pour stopper un upload nécessitant un nouveau binaire.

Docs de compatibilité native

Définissez un seuil de version native par bundle

Appliquez la stratégie de métadonnées au canal et effectuez l'upload avec --auto-min-update-version. Les appareils dont la version native est inférieure au seuil du bundle l'ignorent et conservent leur bundle actuel.

Docs sur le ciblage de version

Bloquez les mises à jour par ligne semver

--disable-auto-update major, minor, ou patch empêche un appareil de recevoir un bundle en dehors de sa ligne de version native. Ces règles comparent uniquement les numéros de version. Elles n'inspectent pas le code natif.

Types de mise à jour et blocage de version

Un canal par version native

Définissez defaultChannel dans la config Capacitor de chaque build natif, par exemple v2 ou v3. Chaque ligne a ses propres bundles, et une ancienne ligne peut rester sur son dernier bundle fonctionnel.

Docs sur le ciblage de version

Comment ça marche

Comment les équipes avec plusieurs versions natives déploient avec Capgo

Une configuration CI qui permet à la voie live update et à la voie du store de fonctionner côte à côte. Chaque commande ci-dessous provient de la doc Capgo CLI.

  1. Vérifier si le commit nécessite un build natif

    build needed compare vos packages natifs avec le canal. Il affiche « yes » et quitte avec le code code 1 lorsqu'une release sur le store est requise, et « no » lorsqu'une live update suffit.

    npx @capgo/cli@latest build needed com.example.app --channel production
    Référence build needed

  2. Basculez le canal vers la stratégie de métadonnées

    Faites-l’une seule fois. À partir de là, chaque bundle inclut une version native minimale et les appareils inférieurs l'ignorent.

    npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update metadata
    Docs sur le ciblage de version

  3. Envoyez vos live updates quotidiennement

    Gardez --auto-min-update-version lors de chaque upload. --fail-on-incompatible interrompt le job si le bundle nécessite un code natif que le canal ne possède pas.

    npx @capgo/cli@latest bundle upload --channel production \
  --auto-min-update-version \
  --fail-on-incompatible
    Docs de compatibilité native

  4. Envoyez le bundle pour une nouvelle release native

    Lorsque le nouveau binaire est déployé, envoyez son bundle sans --fail-on-incompatible. Capgo définit un seuil minimum pour que les builds plus anciens l'ignorent, et les vérifications ultérieures comparent les versions avec les nouveaux packages natifs.

    npx @capgo/cli@latest bundle upload --channel production \
  --auto-min-update-version
    Workflow des canaux natifs et OTA

Migration Appflow

Vous venez d'Ionic Appflow ?

Appflow associait les live updates aux versions natives pour vous. Avec Capgo, obtenez le même résultat grâce aux canaux et aux règles de version :

  1. Créez un canal pour chaque ligne native, par exemple v1 et v2.
  2. Définissez defaultChannel sur son canal dans la config Capacitor de chaque build natif.
  3. Envoyez chaque bundle vers le canal de la ligne native pour laquelle il a été compilé.
  4. Conservez l'option --auto-min-update-version lors des uploads pour qu'un bundle nécessitant un code natif plus récent ignore les builds plus anciens.
Guide de migration Appflow
Un canal par ligne native 
// capacitor.config.ts in your 2.x native builds
plugins: {
  CapacitorUpdater: {
    defaultChannel: 'v2',
  },
},

# ship a fix to 2.x users only
npx @capgo/cli@latest bundle upload --channel v2 \
  --auto-min-update-version

# 1.x devices stay on their channel's current bundle

Cas d'usage courants

Un nouveau plugin natif

Votre binaire 2.0 ajoute un plugin caméra. Envoyez le bundle qui l'utilise avec --auto-min-update-version, et les appareils en 1.x l'ignoreront jusqu'à l'installation de la version 2.0.

Docs de compatibilité native

Déploiement progressif

Envoyez un bundle à une partie d'un canal avec --rollout, surveillez les données d'installation et d'échec, puis propagez-l’ou effectuez un rollback.

Docs sur le déploiement progressif

Retrait d'une ancienne version

Arrêtez l'upload vers le canal v1. Les appareils utilisent leur dernier bundle fonctionnel tandis que la v2 continue de recevoir des mises à jour.

Docs sur le ciblage de version

Chaque version native pointe vers son propre canal

Exemple de structure avec trois versions natives en production.

  • Native 3.x
    v3
    Nouveaux bundles
  • Native 2.x
    v2
    Fixes only
  • Native 1.x
    v1
    Aucun nouveau bundle

Déployez les fonctionnalités sur v3, les correctifs sur v2, et rien sur v1. Les appareils en v1 conservent leur dernier bundle fonctionnel.

Apps développées avec Capacitor

Public apps must support old and new native versions

Les applications citoyennes, de santé ou de prévisions peuvent prendre en charge d'anciennes versions d'Android et différentes générations d'appareils. Le ciblage par version maintient chaque build natif sur le bundle web compatible le plus récent, sans imposer un même parcours de mise à jour à tous.

Icône de l'application e-Título SOCIAL

e-Título

Application d'identité civique nécessitant une large compatibilité avec les appareils publics.

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

Connectez SUS

Application de santé où les shells natifs anciens et récents peuvent nécessiter des bundles web différents.

Installations Google Play
27,7 M
Note du store
4.6
Icône de l'application Windy.com - Weather Forecast MÉTÉO

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

Application météo où les capacités de l'appareil et les performances de la carte peuvent varier selon la version.

Installations Google Play
32,9 M
Note du store
4.7

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

no-tone @ Webincode

Développeur, Webincode

« Pouvoir ajouter des Device ID à certains groupes et n'envoyer les changements qu'à certains groupes, ça nous sauve la vie. »

Nate van Jole

CTO, Privé

« L'installation a pris moins d'une journée. Les déploiements progressifs par canal me permettent de tester sur mon propre appareil avant de toucher les utilisateurs en production. »

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. »

FAQ

Questions sur les versions en production

For teams supporting users who update the store app at different times.

What happens to users who never update the native app?

Ils continuent de recevoir des bundles compatibles avec leur version native. Grâce à la stratégie de métadonnées, un bundle dont la version native minimale est supérieure à la leur est ignoré, et ils conservent leur bundle actuel.

Docs sur le ciblage de version

--disable-auto-update est-il assez robuste pour éviter les crashs ?

Non. Les règles de version ne comparent que les numéros de version ; un changement natif déployé via une release mineure ou patch sera donc toujours diffusé. Utilisez --fail-on-incompatible ou --auto-min-update-version, qui vérifient vos packages natifs.

Docs de compatibilité native

Comment la CI sait-elle si un changement nécessite une release sur les stores ?

Exécutez le build nécessaire ou comparez le releaseType du bundle avec le canal. Les deux comparent les métadonnées des packages natifs. Ils ne détectent pas chaque modification dans ios/, android/ ou capacitor.config, pensez donc à protéger également ces chemins dans git.

Choisissez entre Live Update ou build natif dans votre CI

Nous quittons Ionic Appflow. Pouvons-nous conserver des mises à jour synchronisées avec la version ?

Oui. Utilisez un canal par branche native avec defaultChannel, ou la stratégie de métadonnées avec --auto-min-update-version. Le guide de migration Appflow vous accompagne dans la configuration.

Guide de migration Appflow

Que faire si un bundle incompatible a déjà été déployé ?

Redirigez le canal vers le dernier bundle compatible de son historique, ou forcez le bundle intégré, puis déployez le build natif. notifyAppReady() effectue un rollback d'un bundle qui ne parvient pas à démarrer, mais cela ne remplace pas un code natif compatible.

Doc sur les rollbacks

Associez chaque version native au bundle qu'elle peut exécuter

Configurez la stratégie de métadonnées et un contrôle de compatibilité en CI durant l'essai gratuit de 14 jours. Aucune carte bancaire requise.