Transformez chaque pull request en une preview installable

Toute équipe de développement mobile a déjà ressenti cette douleur : une fonctionnalité est prête pour revue, mais la mettre entre les mains des parties prenantes implique de naviguer dans le labyrinthe de la revue TestFlight ou de la bêta Google Play. Ce qui devrait prendre quelques minutes se transforme en des heures d’attente, d’installation et de gestion de builds bêta.

Et si votre application de production pouvait récupérer les dernières modifications de n’importe quelle pull request directement sur l’appareil, sans réinstallation ni délai de store ?

C’est ce que les previews de PR permettent. Lorsqu’un développeur ouvre une pull request, une Action GitHub crée un canal de mise à jour dédié et publie les changements. N’importe qui ayant l’application installée peut basculer sur ce canal, tester la fonctionnalité, puis revenir en arrière — le tout sans quitter l’application qu’il possède déjà.

Le problème TestFlight

Le workflow traditionnel pour tester des fonctionnalités mobiles ressemble à ceci :

Le développeur ouvre la PR - Code est prête pour revue
Attente de TestFlight - 15 à 30 minutes de traitement
Trouver et installer - Les testeurs cherchent le bon build
Tester et répéter - Chaque changement implique une nouvelle attente

Cela crée un goulot d’étranglement. QA est bloqué en attendant les builds. Les chefs de produit ne peuvent pas vérifier les fonctionnalités rapidement. Les développeurs perdent le contexte en attendant les retours. L’industrie estime que cela coûte environ 340 $ par PR en productivité perdue.

Fonctionnement des aperçus de PR

Les aperçus de PR utilisent le système de canaux de Capgo pour créer des flux de mise à jour par PR. Voici le flux :

PR ouverte ou mise à jour - L’Action GitHub est déclenchée
Bundle envoyé - Vos modifications JS/CSS sont envoyées vers un canal spécifique à la PR
Commentaire publié - Les testeurs reçoivent les instructions dans la PR
Tests instantanés - Changer de canal, tester, revenir en arrière

Aucune nouvelle installation d’app. Aucun délai TestFlight. La même app de production peut se connecter à différents canaux de mise à jour.

Configurer les aperçus de PR

Avant d’implémenter les aperçus de PR, votre projet doit être configuré avec Capgo Live Updates. Suivez le guide de démarrage rapide Capgo si vous ne l’avez pas encore fait.

Workflow GitHub Actions

Créer .github/workflows/pr-preview.yml:

name: PR Preview
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Setup Bun
        uses: oven-sh/setup-bun@v2

      - name: Install Dependencies
        run: bun install

      - name: Build
        run: bun run build

      # Create a channel named after your PR (may already exist on synchronize)
      - name: Create PR Channel
        id: create_channel
        continue-on-error: true
        run: bunx @capgo/cli@latest channel add pr-${{ github.event.pull_request.number }} --self-assign
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}

      # Upload the build to that channel
      - name: Upload to Capgo
        run: bunx @capgo/cli@latest bundle upload --channel pr-${{ github.event.pull_request.number }}
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}

      # Post a comment with testing instructions (only on PR open)
      - name: Comment on PR
        if: github.event.action == 'opened'
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: ${{ github.event.pull_request.number }},
              body: '📱 **Test this PR on device:**\n\nOpen your app and switch to channel: `pr-${{ github.event.pull_request.number }}`\n\nUse the shake menu or call `setChannel()` from your app.'
            })

L’élément clé est le --self-assign lors de la création du canal. Cela permet aux testeurs de basculer vers ce canal depuis l’app en utilisant le setChannel() API.

Configurer le token Capgo

Accédez à votre dashboard Capgo
Allez dans Paramètres > Clés API
Générer une nouvelle clé avec all des permissions
Ajoutez-l’en CAPGO_TOKEN dans les secrets de votre dépôt GitHub

Comment les testeurs changent de canal

Il existe deux façons pour les testeurs de passer sur un canal de PR :

Activez le menu shake avec sélecteur de canal dans votre config Capacitor :

// capacitor.config.ts
const config: CapacitorConfig = {
  // ... your other config
  plugins: {
    CapacitorUpdater: {
      shakeMenu: true,
      allowShakeChannelSelector: true
    }
  }
};

Les testeurs secouent leur appareil pour ouvrir le menu de debug, qui affiche la liste des canaux disponibles avec une barre de recherche. Ils trouvent leur canal de PR (ex : pr-123), appuient dessus pour le sélectionner, et l'app télécharge et applique automatiquement la mise à jour. Une fois le test terminé, ils secouent à nouveau pour repasser en production.

Le menu shake gère tout le flux automatiquement :

Récupère tous les canaux auto-assignables via listChannels()
Affiche les canaux avec une recherche pour trouver des PR spécifiques
Télécharge la mise à jour après la sélection
Prompts to reload with “Reload Now” / “Later” options

Option 2 : UI du sélecteur de canal personnalisé

Intégrez un sélecteur de canaux dans votre app pour lister les canaux de PR disponibles et permettre aux testeurs d'en choisir un. Cela utilise deux API clés :

listChannels() - Récupère tous les canaux avec l'auto-assignation activée
setChannel() - Bascule l'appareil sur le canal sélectionné

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

// Get all available channels (including PR channels)
async function getAvailableChannels() {
  const { channels } = await CapacitorUpdater.listChannels();

  // Filter to show only PR channels
  const prChannels = channels.filter(c => c.name.startsWith('pr-'));

  return prChannels;
}

// Switch to a specific PR channel
async function switchToChannel(channelName: string) {
  await CapacitorUpdater.setChannel({
    channel: channelName,
    triggerAutoUpdate: true  // Immediately check for updates
  });
}

// Return to production
async function switchBackToProduction() {
  await CapacitorUpdater.unsetChannel({});
}

// Get current channel
async function getCurrentChannel() {
  const { channel } = await CapacitorUpdater.getChannel();
  return channel;
}

Avec ces briques de base, vous pouvez créer une interface simple :

// Example: List PR channels and let user select
const channels = await getAvailableChannels();
const current = await getCurrentChannel();

// Display channels in your UI
channels.forEach(channel => {
  console.log(`${channel.name} ${channel.name === current ? '(current)' : ''}`);
});

// When user selects a channel
await switchToChannel('pr-123');

Pour un exemple complet de composant React, consultez notre article sur le channel surfing.

Nettoyage des canaux de PR

Lorsqu'une PR est fusionnée ou fermée, pensez à nettoyer le canal. Ajoutez un autre workflow :

name: Cleanup PR Preview
on:
  pull_request:
    types: [closed]

jobs:
  cleanup:
    runs-on: ubuntu-latest
    steps:
      - name: Delete PR Channel
        run: bunx @capgo/cli@latest channel delete pr-${{ github.event.pull_request.number }}
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}

Cela supprime le canal à la fermeture de la PR, pour garder votre liste de canaux propre.

Compatibilité des versions

Les aperçus de PR ne fonctionnent que si le bundle JavaScript est compatible avec la version native installée. Si votre PR inclut des modifications natives code (nouveaux plugins Capacitor, modifications iOS/Android), les testeurs auront besoin d'un nouveau build natif.

Capgo vérifie automatiquement la compatibilité des versions. Si le bundle d'une PR cible une version native différente de celle installée, la mise à jour ne sera pas appliquée. Cela évite les plantages liés à une incompatibilité de code.

Pour les PR qui nécessitent des modifications natives, vous devrez distribuer un nouveau build TestFlight/Play Store. Les aperçus de PR sont surtout utiles pour les modifications de JavaScript, de CSS et d'assets qui ne touchent pas au code natif.

Qui bénéficie des aperçus de PR

Ingénieurs QA

Testez les fonctionnalités dès l’ouverture des PR
Basculez entre plusieurs PR sans réinstaller
Vérifiez les correctifs et les régressions sur des appareils réels
Plus d’attente pour le traitement TestFlight

Product managers

Revuez les fonctionnalités avant leur fusion
Donnez votre retour directement sur la PR
Vérifiez que l’implémentation correspond aux exigences
Réduisez le temps de cycle de revue

Développeurs

Obtenez un retour plus rapide sur les modifications
Demo features to stakeholders instantly
Déboguer les problèmes avec des utilisateurs spécifiques
Passer moins de temps à gérer les builds bêta

Comparaison : approche traditionnelle vs previews de PR

Aspect	TestFlight/Bêta	Aperçu PR Capgo
Temps de build	15-30 min	< 1 min
Changement de PR	Réinstallation de 5+ min	10 secondes
Complexité de configuration	Identifiants App Store	Un seul fichier workflow
Nettoyage	Manuelle	Automatique
Modifications natives code	Requis	Facultatif (JS uniquement)

Bonnes pratiques

Nommez clairement les canaux : Utilisez pr-{number} convention pour faciliter l'identification
Auto-cleanup: Supprimez toujours les canaux à la fermeture des PR
Limiter l'accès: Activez le menu shake uniquement dans les builds debug/staging
Documenter le processus: Ajoutez les instructions de test à votre template de PR
Gérer les échecs proprement: Vérifiez que la création du canal réussit avant de publier des commentaires

Quand ne pas utiliser les previews de PR

Les aperçus de PR sont destinés aux modifications JavaScript/CSS. Si votre PR contient :

De nouveaux plugins Capacitor
Modifications natives iOS code
Modifications natives Android code
Mises à jour de dépendances affectant les builds natifs

Vous devrez utiliser la distribution classique via TestFlight/Play Store pour ces modifications.

Combiner avec le Channel Surfing

Les aperçus de PR fonctionnent le mieux combinés avec le channel surfing. Votre application peut avoir :

production - Des releases stables pour tous les utilisateurs
beta - Un accès anticipé pour les utilisateurs volontaires
pr-123 - Aperçus de fonctionnalités pour des PR spécifiques

Les testeurs disposant de builds de production peuvent basculer sur n'importe quel canal de PR, tester la fonctionnalité, puis revenir en arrière - le tout avec la même application installée.

Ressources

Conclusion

Les previews de PR transforment la façon dont votre équipe relit et teste les fonctionnalités mobiles. Au lieu d'attendre le traitement TestFlight et de gérer plusieurs builds bêta, les testeurs peuvent basculer sur n'importe quel canal de PR en quelques secondes avec l'application qu'ils ont déjà installée.

La mise en place est minimale — un seul fichier de workflow GitHub Actions — et les bénéfices se cumulent pour toute votre équipe. La QA reste débloquée, les product managers relisent plus vite et les développeurs obtiennent des retours plus rapides.

Commencez par ajouter le workflow à un dépôt et voyez comment il change votre processus de review.

Continuer la lecture : transformez chaque pull request en preview installable

Si vous utilisez Transformez chaque pull request en une preview installable 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.