Zapping de canaux pour Capgo : comment changer de canal de mise à jour au runtime

Avez-vous déjà souhaité déployer un changement directement auprès d'un utilisateur spécifique pour obtenir son avis immédiat, sans lui demander de télécharger et d'installer un nouveau build via TestFlight ou Google Play ?

Certains clients m'ont demandé des améliorations que j'ai pu implémenter rapidement, mais pour leur transmettre les résultats et les faire valider, je devais soit déployer une mise à jour à tous les utilisateurs (risqué pour un changement expérimental), soit créer un build spécifique pour ce 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, la QA, ou l'ensemble de la base d'utilisateurs le moment venu.

Il n'existait aucun moyen pour un build de production de basculer vers une version de travail, de recueillir des retours, puis de revenir en production.

C'est ce que le zapping de canaux permet. Une application installée sur l'appareil d'un utilisateur peut changer de canal de mise à jour au runtime, transformant une application de production en un espace flexible pour la revue et l'itération plutôt qu'en un point final figé. C'est particulièrement utile pour les parties prenantes non techniques travaillant sur des apps de production, leur permettant de tester les changements et de donner leur feedback directement dans l'application qu'ils ont déjà installée.

Comprendre les canaux de mise à jour

Les canaux de mise à jour sont la méthode utilisée par Capgo pour cibler les mises à jour vers des builds spécifiques. Chaque build est associé à un canal, et ce canal 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. Auparavant, changer de canal nécessitait d'installer un build natif différent ou de modifier manuellement l'assignation des appareils via le dashboard.

Les canaux dans 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 encore les canaux de mise à jour, la documentation des canaux de Capgo les détaille plus précisément.

Qu'est-ce que le channel surfing ?

Le channel surfing permet à une application installée de tirer des flux de mise à jour différents sans réinstallation. Une application peut changer de canal de mise à jour au runtime, et continuera de recevoir les mises à jour du nouveau canal sélectionné jusqu'à ce que l'app soit désinstallée ou basculée sur un autre canal.

En pratique, cela signifie qu'un product owner ou un QA peut basculer un production build vers, par exemple, un preview canal pour tester les derniers changements. Une fois les tests terminés, ils reviennent sur le production canal initial. Pas besoin de réinstaller l'app ou de créer un build de preview séparé.

Sous le capot, le channel surfing fonctionne en permettant à l'app d'indiquer au client de mise à jour quel canal utiliser. Ce choix peut être modifié au runtime et reste effectif jusqu'à ce qu'il soit effacé ou remplacé.

Comment implémenter le changement de canal

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

La seule configuration requise pour le changement de canal est d'activer « Allow devices to self associate » sur chaque canal vers lequel vous souhaitez basculer dans le dashboard Capgo. Aucune autre modification de code ou de la config n'est nécessaire.

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é pour interroger Capgo et récupérer les mises à jour. En savoir plus sur setChannel API.

Changement de canal instantané (v5.34.0+)

À partir de la version du plugin 5.34.0, 6.34.0, 7.34.0 ou 8.0.0 (selon votre version majeure), setChannel() cela fonctionne différemment et bien 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 sauvegardé dans le stockage local de l'appareil
Effet instantané: La prochaine vérification de mise à jour utilise immédiatement le nouveau canal

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

Flux complet de changement de canal

Pour une meilleure expérience utilisateur, vous voudrez généralement faire plus que simplement changer le canal et 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, et à 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 une mise à 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 est libre. Vous pouvez diviser ces étapes en plusieurs interactions ou toutes les exécuter d'un coup. Peu importe la structure choisie, assurez-vous de gérer les erreurs. Des problèmes de réseau ou un canal invalide peuvent empêcher l'application d'une mise à jour.

La seule exigence : activer le self-assignment

C'est la seule chose à faire pour permettre le changement de canal. Avant que votre app puisse basculer vers un canal via setChannel(), vous devez activer le self-assignment pour ce canal dans le dashboard Capgo :

Allez sur la Canaux section de votre dashboard Capgo
Cliquez sur le nom du canal à gérer
Activer « Autoriser l'auto-association des appareils »
Enregistrer les modifications

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

C'est tout. Aucun changement de config dans votre app. Pas de defaultChannel paramètre requis. Activez simplement l'auto-assignation sur les canaux vers lesquels vous voulez que les utilisateurs basculent.

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

Liste des 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

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

Récupérer le canal actuel

Vérifier le canal actuellement assigné à l'appareil :

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

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

Revenir au canal par défaut

Pour supprimer la modification du canal et revenir au mode par défaut :

await CapacitorUpdater.unsetChannel({});

Cela détache l'appareil de tout canal spécifiquement assigné, ce qui le ramène au defaultChannel de votre config ou au 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 classique.

Prerequisites

La seule condition pour le changement de canal est d'activer « Allow devices to self associate » sur chaque canal vers lequel vous souhaitez permettre la bascule. Aucun changement de config n'est requis dans votre app.

Créer un build de test

Compilez votre app comme d'habitude :

bun run build && npx cap sync

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

Publier des mises à jour sur différents canaux

Une fois l'app 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

À partir de là, accédez à votre interface de changement de canal dans l'app et déclenchez la bascule. L'app doit récupérer la mise à jour du canal sélectionné et recharger la nouvelle version.

Créer une interface de changement de canal

Le changement de canal est généralement une fonctionnalité à réserver à un groupe limité d'utilisateurs, et non à tout le monde. Par exemple, vous pourriez proposer un bouton accessible uniquement aux employés authentifiés pour basculer l'app vers le canal de preview.

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 du changement de canal, cela se manifeste généralement par un changement de canal de l'application sans application de la mise à jour, même si celle-ci existe sur ce canal.

Cela signifie généralement que la mise à jour a été publiée à partir d'une version native différente de l'application. 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 la retire 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 mise à jour stable 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

Changer 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, passer de l'un à l'autre peut causer 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 permettent un switch sécurisé ou restreindre le changement à une seule direction 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 vérifier rapidement des modifications dans un environnement de production.

Validation rapide

Imaginez un correctif de bug urgent qui nécessite une validation avant d'être déployé largement. Grâce au changement de canal, la modification peut être isolée sur un petit groupe d'utilisateurs désignés qui peuvent la tester avant qu'elle n'atteigne la production.

Revue par les parties prenantes

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

Tests simplifiés

Cela permet d'impliquer plus facilement les parties prenantes non techniques dans la revue et la prise de décision, tout en gardant un workflow 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
Tests A/BAssigner des utilisateurs à différents canaux pour des expérimentations
DébogageBasculer 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	Lieu de persistance	Cas d’usage
`setChannel()` depuis le plugin	Instantané	Appareil uniquement (local)	Changement de canal par l'utilisateur dans l'app
Surcharge par appareil via le dashboard	Jusqu'à 2 min	Base de données backend	Modifications initiées par l'admin sur des appareils spécifiques
Assignation du 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'UI 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 du changement de canal
Valider la compatibilité: Assurez-vous que les mises à jour sur les différents canaux sont compatibles avec la version native installée
Documenter les canaux: Gardez une documentation claire sur l'utilité de chaque canal
Surveiller l'usage: Suivez quels appareils sont sur quels canaux pour le débogage

Ressources

Conclusion

Le changement de canal transforme votre façon d'itérer sur votre application Capacitor. Au lieu de considérer les builds de production comme des points finaux fixes, ils deviennent des outils flexibles pour le test, la validation et l'itération rapide.

Avec le changement de canal instantané introduit dans les récentes 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 aucune attente.

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

De la zapping de canaux pour Capgo : comment changer de canal de mise à jour au runtime

Si vous utilisez Channel Surfing pour Capgo: comment changer de canal de mise à jour au runtime pour planifier le routage des canaux et le déploiement progressif, connectez-l’à 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 test bêta pour le workflow produit de la solution de test bêta, et Solution de ciblage de version pour le workflow produit de la solution de ciblage de version.