Changer de canal pour Capgo : comment basculer de canal de mise à jour au runtime

Avez-vous déjà souhaité livrer une modification directement à un utilisateur spécifique pour qu’il la valide et vous donne son retour immédiatement, sans lui demander de télécharger et d’installer un nouveau build depuis TestFlight ou Google Play ?

Des clients m’ont demandé des améliorations que j’ai pu implémenter rapidement, mais pour leur faire valider le résultat, il fallait soit déployer une mise à jour pour tous les utilisateurs (risqué pour un changement expérimental), soit créer un build unique dédié au client (une corvée pour nous deux).

Ce qui manquait, c’était de la flexibilité. Les développeurs voulaient pouvoir servir différentes mises à jour à différents groupes d’utilisateurs, comme des parties prenantes non techniques, l’équipe QA, ou l’ensemble des utilisateurs quand c’est pertinent.

Aucun moyen de faire basculer un build de production vers une version en cours de développement, de recueillir des retours, puis de revenir à la production.

C’est ce que le channel surfing permet. Une application installée sur l’appareil d’un utilisateur peut changer de canal de mise à jour à l’exécution, transformant une app de production en espace flexible pour la revue et l’itération plutôt qu’en point final figé. C’est particulièrement utile pour les parties prenantes non techniques qui travaillent avec des apps de production, leur permettant de tester des changements et de donner leur retour directement dans l’app qu’elles ont déjà installée.

Comprendre les canaux de mise à jour

Les canaux de mise à jour permettent à Capgo de cibler les mises à jour sur des builds spécifiques. Chaque build est associé à un canal, qui détermine les mises à jour qu’il recevra.

Par exemple, vous pouvez publier des mises à jour sur un preview canal sans affecter les utilisateurs sur production. Par le passé, changer de canal nécessitait d’installer un build natif différent ou de modifier manuellement les affectations d’appareils via le dashboard.

Les canaux de Capgo vous permettent de :

Target specific user groups with different features
Réalisez des tests A/B en assignant les utilisateurs à différents canaux
Déployez progressivement de nouvelles fonctionnalités
Créez des programmes de bêta-test
Debug production issues with individual users

Si vous ne connaissez pas les canaux de mise à jour, documentation sur les canaux Capgo les détaille davantage.

Qu’est-ce que le channel surfing ?

Le channel surfing permet à une application installée de se connecter à différents flux de mises à jour sans réinstallation. L’application peut changer de canal de mise à jour à l’exécution et continuera de recevoir les mises à jour du nouveau canal sélectionné jusqu’à son désinstallation ou son basculement vers un autre canal.

Concrètement, cela signifie qu’un product owner ou un QA peut basculer un production build vers, par exemple, un preview canal, pour tester les dernières modifications. Une fois les tests terminés, il revient sur production à nouveau. Aucune réinstallation ni build de préversion séparé n’est nécessaire.

Sous le capot, le channel surfing fonctionne en permettant à l’application d’indiquer au client de mises à jour quel canal utiliser. Ce choix peut être modifié à l’exécution et reste en vigueur jusqu’à ce qu’il soit effacé ou remplacé.

Comment implémenter le channel surfing

Avant de pouvoir tester le channel surfing, votre projet doit être configuré avec Capgo Live Updates. Pour cela, suivez le guide de démarrage rapide Capgo.

La seule configuration requise pour changer de canal consiste à activer « Autoriser les appareils à s’associer eux-mêmes » sur chaque canal cible dans le dashboard Capgo. Aucune modification de code ou de configuration n’est nécessaire au-delà de cela.

Au fond, le changement de canal repose sur un seul appel API :

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

await CapacitorUpdater.setChannel({ channel: 'your-channel' });

Cela définit le canal utilisé lors des requêtes à Capgo pour les mises à jour. En savoir plus sur setChannel API.

Changement de canal instantané (v5.34.0+)

À partir des versions 5.34.0, 6.34.0, 7.34.0 ou 8.0.0 du plugin (selon votre version majeure), setChannel() fonctionne différemment et beaucoup plus vite :

Validation backend (lecture seule): une requête est envoyée au backend Capgo pour valider que le canal est autorisé
Mise à jour du stockage local: si la validation réussit, le canal est enregistré dans le stockage local de l'appareil
Effet immédiat: La prochaine vérification de mise à jour utilise immédiatement le nouveau canal

Auparavant, setChannel() l'override de canal était enregistré dans la base de données backend (comme les changements faits dans le Dashboard ou via API). Les appareils devaient attendre la réplication du backend (jusqu'à 2 minutes) avant que le nouveau canal soit reconnu. Le nouveau comportement ne lit plus le backend que pour la validation et stocke la valeur localement, ce qui rend le changement de canal instantané.

Flux complet de changement de canal

Pour une meilleure expérience utilisateur, vous ne vous contenterez généralement pas de changer le canal et d'attendre le prochain redémarrage de l'app. Une approche courante consiste à vérifier immédiatement les mises à jour, à les télécharger si elles sont disponibles, puis à recharger l'app pour que l'utilisateur arrive directement sur la mise à jour du canal sélectionné.

Un flux typique ressemble à ceci :

Changer le canal (setChannel)
Vérifier les mises à jour (getLatest)
Récupérer et appliquer la mise à jour (download, set ou next)
Recharger l'app si nécessaire (reload)

Voici un exemple complet :

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

async function switchChannel(selectedChannel: string) {
  try {
    // 1. Set the updates channel (with optional auto-update trigger)
    await CapacitorUpdater.setChannel({
      channel: selectedChannel,
      triggerAutoUpdate: true // Immediately check for updates
    });

    console.log(`Switched to channel: ${selectedChannel}`);

    // If you want more control, handle the update manually:
    // const latest = await CapacitorUpdater.getLatest();
    // if (latest.url) {
    //   const bundle = await CapacitorUpdater.download({
    //     url: latest.url,
    //     version: latest.version
    //   });
    //   await CapacitorUpdater.set({ id: bundle.id });
    // }

  } catch (error) {
    console.error('Failed to switch channel:', error);
  }
}

// Switch to the beta channel
switchChannel('beta');

La structure de ce flux vous appartient. Vous pouvez répartir ces étapes sur plusieurs interactions ou les exécuter toutes d’un coup. Quelle que soit la structure choisie, pensez à gérer les échecs. Des problèmes réseau ou un canal invalide peuvent empêcher l’application d’une mise à jour.

La seule exigence : activer l’auto-attribution

C’est la seule chose à faire pour activer le changement de canal. Avant que votre application puisse basculer sur un canal à l’aide setChannel(), vous devez activer l’auto-attribution pour ce canal dans le dashboard Capgo :

Allez sur la Canaux section de votre dashboard Capgo
Cliquez sur le nom du canal que vous souhaitez gérer
Activer “Allow devices to self associate”
Enregistrer les modifications

Activer l'auto-attribution dans les paramètres du canal

That’s it. No config changes needed in your app. No defaultChannel paramètre requis. Il suffit d'activer l'auto-attribution sur les canaux vers lesquels vous voulez que les utilisateurs puissent basculer.

Si ce paramètre est désactivé, toute tentative d'appel de setChannel() avec ce canal échouera et l'événement channelPrivate se déclenchera.

Lister les canaux disponibles

Vous pouvez récupérer la liste des canaux disponibles pour l'auto-assignation :

const { channels } = await CapacitorUpdater.listChannels();

console.log('Available channels:', channels.map(c => c.name));
// Use this to build a channel selector UI

Cela ne retourne que les canaux où l'auto-assignation est activée.

Récupérer le canal actuel

Vérifier à quel canal l'appareil est actuellement assigné :

const { channel } = await CapacitorUpdater.getChannel();

console.log('Current channel:', channel);

Revenir au canal par défaut

Pour supprimer l'override de canal et revenir au canal par défaut :

await CapacitorUpdater.unsetChannel({});

Cela détache l'appareil de tout canal spécifiquement assigné, ce qui le fait basculer vers le defaultChannel dans votre config ou la valeur par défaut du cloud.

Comment tester le changement de canal

Pour voir le changement de canal en action, vous aurez besoin d'un build de release — le @capgo/capacitor-updater API est conçu pour les builds de release. Dans les builds de debug, l'app charge généralement le JavaScript depuis un serveur de développement, ce qui contourne le flux de mise à jour normal.

Prerequisites

La seule exigence pour changer de canal est d’activer “Allow devices to self associate” on each channel you want to allow switching to. No config changes are needed in your app.

Créer un build de test

Compilez votre application comme d'habitude :

bun run build && npx cap sync

Ensuite, créez vos builds natifs à l'aide de Xcode ou Android Studio, ou utilisez votre pipeline CI/CD. L'application démarrera sur le canal défini par défaut dans le cloud sur votre dashboard Capgo.

Publier des mises à jour sur différents canaux

Une fois l'application installée, publiez des mises à jour sur différents canaux :

# Publish to preview channel
npx @capgo/cli@latest bundle upload --channel preview

# Publish to production channel
npx @capgo/cli@latest bundle upload --channel production

Depuis là, accédez à l'interface de navigation entre canaux dans l'application et déclenchez le basculement. L'application doit récupérer la mise à jour depuis le canal sélectionné et se recharger avec la nouvelle version.

Construire une interface de changement de canal

La navigation entre canaux est généralement une fonctionnalité que vous souhaitez exposer à un ensemble limité d'utilisateurs, et non à tous les utilisateurs de votre application. Par exemple, vous pourriez avoir un bouton disponible uniquement pour les employés authentifiés qui bascule l'application sur le canal de préversion.

Voici un exemple de composant React pour un sélecteur de canal :

import { useState, useEffect } from 'react';
import { CapacitorUpdater } from '@capgo/capacitor-updater';

export function ChannelSwitcher() {
  const [currentChannel, setCurrentChannel] = useState<string>('');
  const [availableChannels, setAvailableChannels] = useState<string[]>([]);
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    loadChannelInfo();
  }, []);

  async function loadChannelInfo() {
    const { channel } = await CapacitorUpdater.getChannel();
    setCurrentChannel(channel || 'default');

    const { channels } = await CapacitorUpdater.listChannels();
    setAvailableChannels(channels.map(c => c.name));
  }

  async function handleChannelSwitch(channel: string) {
    setIsLoading(true);
    try {
      await CapacitorUpdater.setChannel({
        channel,
        triggerAutoUpdate: true
      });
      setCurrentChannel(channel);
      // App will update in background or on next restart
    } catch (error) {
      console.error('Failed to switch channel:', error);
    } finally {
      setIsLoading(false);
    }
  }

  return (
    <div>
      <p>Current channel: {currentChannel}</p>
      <div>
        {availableChannels.map(channel => (
          <button
            key={channel}
            onClick={() => handleChannelSwitch(channel)}
            disabled={isLoading || channel === currentChannel}
          >
            Switch to {channel}
          </button>
        ))}
      </div>
    </div>
  );
}

Pièges des mises à jour OTA

Aucun de ces éléments n'est spécifique au changement de canal, mais ils ont tendance à devenir évidents rapidement dès que vous commencez à changer de canal au runtime.

Incohérences de version au runtime

Les mises à jour dans Capgo sont liées aux versions natives de l'application. Si la version native d'une mise à jour ne correspond pas à la version native de l'application installée, la mise à jour ne sera ni téléchargée ni appliquée. Lors d'un changement de canal, on voit généralement l'app changer de canal sans appliquer de mise à jour, même si une mise à jour existe sur ce canal.

Cela signifie généralement que la mise à jour a été publiée depuis une version native différente de l'app. Assurez-vous que le bundle de votre canal est compatible avec la version native installée sur l'appareil.

Supprimer ou annuler des mises à jour

Si une application a déjà téléchargé une mise à jour pour un canal, la supprimer du dashboard Capgo ne l'enlèvera pas des appareils qui l'ont déjà. La suppression interrompt seulement les futurs téléchargements.

La méthode la plus fiable pour annuler une mauvaise mise à jour consiste à publier une version stable et connue sur le même canal. Cela crée une nouvelle mise à jour en haut de l'historique du canal, que les clients traiteront comme la dernière version et appliqueront à la place.

Capgo propose également un mécanisme de rollback qui peut ordonner aux clients de réappliquer une mise à jour stable précédente ou de revenir à la mise à jour intégrée au build.

Considérations sur la migration de données

Le changement de canal modifie le bundle JavaScript exécuté par l’application. Si votre application dépend de migrations ou de structures de données incompatibles entre les canaux, basculer d’un canal à l’autre peut provoquer des problèmes.

Par exemple, si une mise à jour bêta applique une migration de base de données, la version de production pourrait ne pas comprendre le nouveau schéma. Les développeurs doivent s’assurer que leurs mises à jour restent sûres lors du changement de canal, ou restreindre ce changement à un seul sens si nécessaire.

Pourquoi le changement de canal améliore l’itération mobile

Le changement de canal est particulièrement utile lorsque vous devez examiner rapidement des modifications dans un environnement de production.

Validation rapide

Imaginez un correctif urgent qui doit être validé avant un déploiement large. Grâce au changement de canal, la modification peut être isolée pour un petit groupe d’utilisateurs désignés, qui peuvent l’examiner avant qu’elle n’atteigne la production.

Revue des parties prenantes

Un product owner ou un testeur QA peut basculer son build de production installé vers un autre canal de mise à jour, vérifier le correctif ou la fonctionnalité, puis revenir en arrière une fois terminé.

Tests simplifiés

Cela facilite l’implication des parties prenantes non techniques dans l’examen et la prise de décision, tout en maintenant un flux de travail fluide. Un seul build de production devient un outil flexible pour les tests, les retours et la validation.

Cas d’usage

Tests QA: Let QA team switch between feature branches
Programmes bêta: Les utilisateurs rejoignent le canal bêta pour un accès anticipé
Revue des parties prenantes: Les product owners prévisualisent les changements avant la release
A/B testing: Assigner des utilisateurs à différents canaux pour des expérimentations
Débogage: Basculer un utilisateur spécifique sur un canal de debug pour diagnostiquer des problèmes

Comparaison : méthodes de changement de canal

Méthode	Délai d'effet	Emplacement de persistance	Cas d’usage
`setChannel()` depuis le plugin	Instantané	Appareil uniquement (local)	Changement de canal par l'utilisateur dans l'app
Surcharge d'appareil via le dashboard	Jusqu'à 2 min	Base de données backend	Modifications initiées par l'admin pour des appareils spécifiques
Affectation de canal API	Jusqu'à 2 min	Base de données backend	Intégrations backend automatisées

Pour une expérience utilisateur optimale lors de la création d'interfaces de changement de canal, utilisez toujours la setChannel() méthode.

Bonnes pratiques

Limiter l’accès: Le changement de canal est généralement réservé à un usage interne – ne l’exposez pas à tous les utilisateurs
Gérer les erreurs: Gérez toujours les erreurs proprement lors d’un changement de canal
Valider la compatibilité: Assurez-vous que les mises à jour des différents canaux sont compatibles avec la version native installée
Documenter les canaux: Maintenez une documentation claire sur le rôle de chaque canal
Surveiller l’usage: Suivez quels appareils sont sur quels canaux pour le débogage

Ressources

Conclusion

Le channel surfing transforme votre façon d'itérer sur votre app Capacitor. Au lieu de traiter les builds de production comme des points fixes, ils deviennent des outils flexibles pour tester, valider et itérer rapidement.

Avec le changement de canal instantané introduit dans les dernières versions du plugin, l'expérience est désormais fluide : les utilisateurs peuvent changer de canal et recevoir immédiatement les mises à jour du nouveau canal, sans aucun délai d'attente.

Que vous validiez des correctifs avec vos parties prenantes, meniez des programmes bêta ou déboguiez des problèmes avec des utilisateurs spécifiques, le channel surfing vous offre la flexibilité de déployer la bonne mise à jour au bon utilisateur au bon moment.

Continuez avec Channel Surfing pour Capgo : comment changer de canal de mise à jour à l’exécution

Si vous utilisez Changer de canal pour Capgo : comment basculer de canal de mise à jour au runtime pour planifier le routage des canaux et le déploiement progressif, connectez-l’avec Canaux pour les détails d'implémentation des canaux, Canaux pour les détails d'implémentation des canaux, Canaux pour les détails d'implémentation des canaux, Solution de bêta-test pour le workflow produit de la Solution de bêta-test, et Solution de ciblage de version pour le workflow produit de la Solution de ciblage de version.