Turn Every Pull Request Into an Installable Preview

Tout équipe de développeurs mobiles a ressenti la douleur : une fonctionnalité est prête à la revue, mais la faire passer dans les mains des parties prenantes signifie naviguer dans le labyrinthe de la revue bêta TestFlight ou Google Play. Ce qui devrait prendre des minutes tourne en heures d'attente, d'installation et de gestion de versions bêta.

Qu'est-ce si votre application de production pouvait extraire les dernières modifications de toute demande de modification directement sur le dispositif, sans aucune réinstallation ou retard de l'application store ?

C'est ce que Aperçus de PR permettent. Lorsqu'un développeur ouvre une demande de modification, une Action GitHub crée un canal de mise à jour dédié et publie les modifications. N'importe qui avec l'application installée peut passer à ce canal, tester la fonctionnalité et revenir à la version précédente - tout cela sans quitter l'application qu'ils ont déjà.

Le Problème de TestFlight

Le flux de travail traditionnel pour tester les fonctionnalités mobiles ressemble à ceci :

Le développeur ouvre une PR - Code est prêt à la revue
Attendre TestFlight - 15-30 minutes de temps de traitement
Trouvez et installez - Les testeurs recherchent la bonne build
Testez et répétez - Chaque changement signifie attendre encore

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

Comment les Aperçus de PR fonctionnent

Les prévisions PR utilisent le système de canal de Capgo pour créer des flux d'actualisation par PR. Voici le flux :

Demande de mise à jour ouverte - Le GitHub Action déclencheur
Un bundle est téléchargé - Vos modifications JS/CSS sont envoyées à un canal PR spécifique
Un commentaire est posté - Les testeurs reçoivent des instructions dans la PR
Test instantané - Passer entre les canaux, tester, revenir en arrière

Aucune nouvelle installation d'applications. Pas de retard de TestFlight. L'application de production peut récupérer des mises à jour de différents canaux.

Configuration des prévisions PR

Avant de pouvoir mettre en œuvre les prévisions PR, votre projet doit être configuré avec les mises à jour en direct de Capgo. Suivez les Capgo guide de démarrage rapide si vous n'avez pas déjà fait cela.

GitHub Workflow d'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.'
            })

La clé est la --self-assign flag lors de la création du canal. Cela permet aux testeurs de passer à ce canal depuis l'application en utilisant le setChannel() API.

Configuration du jeton Capgo

Allez à votre Capgo tableau de bord
Naviguez jusqu'à Paramètres > Clés API
Générez une nouvelle clé avec all permissions
Y a-t-il ajouté CAPGO_TOKEN en votre répertoire secrets de votre GitHub

Comment les testeurs basculent sur les canaux

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

Activer le menu de secousses avec un sélecteur de canal dans votre Capacitor config :

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

Testers shake their device to open the debug menu, which shows a list of available channels with a search bar. They find their PR channel (e.g., pr-123Touchez pour le sélectionner, et l'application télécharge et applique automatiquement la mise à jour. Une fois les tests terminés, ils secouent à nouveau et reviennent à la production.

Récupère tous les canaux auto-assignables via

Récupère tous les canaux assignables par défaut. listChannels()
Affiche les canaux avec une recherche pour trouver des PR spécifiques
Telecharge l'actualisation après sélection
Invite à recharger avec les options « Recharger maintenant » / « Plus tard »

Option 2 : Sélecteur personnalisé de canal

Construire un sélecteur de canal dans votre application qui liste les canaux PR disponibles et permet aux testeurs de choisir un. Cela utilise deux API clés :

listChannels() - Récupère tous les canaux avec l'auto-assignement activé
setChannel() - Met le dispositif 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, vous pouvez créer une interface utilisateur 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 de composant React complet, voir notre article sur la navigation de canal.

Nettoyage des canaux PR

Lorsqu'un PR est fusionné ou fermé, vous souhaitez nettoyer le canal. Ajoutez une 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 lorsque le PR est fermé, gardant votre liste de canaux propre.

Compatibilité de la version

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

Capgo vérifie automatiquement la compatibilité de la version. Si un aperçu de PR cible une version native différente de celle installée, l'update ne sera pas appliqué. Cela empêche les plantages dus à des code incompatibles.

Pour les PR qui nécessitent des modifications natives, vous devrez distribuer une nouvelle build TestFlight/Play Store. Les aperçus de PR fonctionnent mieux pour les modifications JavaScript, CSS et des assets qui ne touchent pas les modifications natives code.

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

Ingénieurs de test

Testez les fonctionnalités dès l'ouverture des PRs
Testez les fonctionnalités immédiatement lorsque les PR sont ouverts
Passer entre plusieurs PR sans réinstaller
Pas plus de temps d'attente pour le traitement de TestFlight.

Gestionnaires de produit

Examine les fonctionnalités avant leur intégration
Fournir des commentaires directement sur le PR
Vérifier que l'implémentation correspond aux exigences
Réduire le temps de cycle de revue

Développeurs

Obtenir des commentaires rapides 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 versions bêta

Comparaison : Traditionnel vs Prévisions PR

Aspect	TestFlight/Bêta	Capgo Prévision PR
Build time	15-30 min	moins d'1 min
Passer entre les PRs	5+ min de réinstallation	10 secondes
Complexité de mise en place	Informations de compte App Store	Un fichier de workflow
Nettoyage	Manuel	Automatique
Mise à jour native code	Requis	Facultatif (seulement JS)

Meilleures pratiques

Nommez les canaux clairement Utilisez pr-{number} une convention pour une identification facile
Auto-cleanupSupprimez toujours les canaux lorsque les PR se ferment
Restreignez l'accèsSeulement activez le menu de secousse dans les builds de débogage/étape.
Documentez le processus: Ajoutez des instructions de test à votre modèle de PR
Gérez les échecs avec élégance: Vérifiez que la création de canal réussit avant d'ajouter des commentaires

Lorsque ne pas utiliser les aperçus de PR

Les aperçus de PR sont pour les modifications JavaScript/CSS. Si votre PR inclut :

Nouveaux Capacitor plugins
Changements natifs iOS code
Changements natifs Android code
Mises à jour de dépendances affectant les builds natifs

Vous aurez besoin de la distribution traditionnelle TestFlight/Play Store pour ces changements.

Combinaison avec la navigation de canal

PRs fonctionnent mieux lorsqu'elles sont combinées avec Navigation entre les canaux. Votre application peut avoir :

production - Mises à jour stables pour tous les utilisateurs
beta - Accès précoce pour les utilisateurs qui ont opté pour cela
pr-123 - Feature previews for specific PRs

Les testeurs avec des builds de production peuvent passer d'un canal PR à un autre, tester la fonctionnalité, puis revenir à la même application installée.

Ressources

Conclusion

Les aperçus de PR transforment la façon dont votre équipe examine et test les fonctionnalités mobiles. Au lieu d'attendre le traitement de TestFlight et de gérer plusieurs versions bêta, les testeurs peuvent passer à n'importe quel canal PR en quelques secondes à l'aide de l'application qu'ils ont déjà installée.

La mise en place est minimale - un fichier de workflow GitHub Actions - et les avantages s'accumulent au fil de votre équipe. La QA reste bloquée, les gestionnaires de produit examinent plus rapidement, et les développeurs obtiennent des retours plus rapides.

Commencez par ajouter le workflow à un dépôt et voyez comment cela change votre processus d'examen.

Continuez de Turn Every Pull Request Into an Installable Preview

Si vous utilisez Transformez Chaque Demande de Tirage en Prévisualisation Installeable planifier la routage du canal et le lancement étape par étape, connectez-l’avec Canaux pour les détails d'implémentation dans les canaux, Canaux pour les détails d'implémentation dans les canaux, Canaux pour les détails d'implémentation dans Canaux, Solution de test en bêta pour le flux de travail du produit dans la Solution de Test Beta. Solution de ciblage de version pour le flux de travail du produit dans Solution de ciblage de version.

Tournez chaque demande de tirage en une prévisualisation installable