Transformez chaque demande de tirage en une prévisualisation installable

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

Quoi si votre application de production pouvait extraire les dernières mises à jour de n'importe quelle demande de tirage directement sur l'appareil, sans aucune réinstallation ou retard de l'application store ?

C'est ce que PR previews enable. Lorsqu'un développeur ouvre une demande de tirage, une GitHub Action 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 à celle qu'il avait - tout cela sans quitter l'application qu'il possède déjà.

Le problème de TestFlight

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

Développeur ouvre PR - Code est prêt à la revue
Attendez-vous à TestFlight - 15-30 minutes de temps de traitement
Trouvez et installez - Les testeurs cherchent la bonne build
Testez et répétez - Chaque changement signifie une autre attente

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

Commentaires de PR Fonctionnent

Les aperçus de PR utilisent le système de canal de Capgo pour créer des flux d'actualisation par-PR. Voici le flux :

PR ouvert ou mis à jour - GitHub Action déclenche
Bundle téléchargé - Vos modifications JS/CSS sont envoyées à un canal spécifique à la PR
Commentaire publié - Les testeurs reçoivent des instructions dans la PR
Test instantané - Passer de canal, tester, revenir

Aucune nouvelle installation d'application. Aucun retard de TestFlight. La même application de production peut récupérer des mises à jour à partir de différents canaux d'actualisation.

Configuration des Aperçus de PR

Avant de pouvoir mettre en œuvre les aperçus de PR, votre projet doit être configuré avec Capgo Mises à jour en temps réel. Suivez le guide de démarrage rapide Capgo. Si vous n'avez pas déjà fait cela.

Le workflow d'actions GitHub

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 le --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 dans votre Capgo tableau de bord
Naviguez jusqu'à Paramètres > API Clés
Générer une nouvelle clé avec all permissions
L'ajouter comme CAPGO_TOKEN dans votre GitHub secrets de dépôt

Comment les testeurs basculent les canaux

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

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

// 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 débogage, qui affiche une liste des canaux disponibles avec une barre de recherche. Ils trouvent leur canal PR (par exemple, pr-123)

appuient dessus pour le sélectionner et l'application télécharge et applique automatiquement la mise à jour. Lorsqu'ils ont terminé les tests, ils secouent à nouveau et basculent vers la production.

Le menu de secousses gère l'ensemble de la flux automatiquement : listChannels()
Affiche des canaux avec une recherche pour trouver des PR spécifiques
Télécharge la mise à jour après sélection
Invite à recharger avec les options « Recharger maintenant » / « Plus tard »

Option 2 : Sélecteur de canaux personnalisé

Construire un sélecteur de canaux dans votre application qui liste les canaux PR disponibles et permet aux testeurs de choisir un.

listChannels() Ceci utilise deux API clés :
setChannel() - Récupère tous les canaux avec l'auto-assignement activé

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;
}

- Change le périphérique vers le canal sélectionné

// 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');

Avec ces briques de construction, vous pouvez créer une interface utilisateur simple : Pour un exemple de composant React complet, voir notre article sur la navigation de canaux.

Nettoyage des canaux PR

Lorsqu'un PR est fusionné ou fermé, vous devrez 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 }}

Cette fonction supprime le canal lorsque la PR est fermée, gardant ainsi votre liste de canaux propre.

Compatibilité de la version

Les prévisions 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, modifications iOS/Android), les testeurs auront besoin d'une nouvelle build native.

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

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

Qui bénéficie des prévisions de PR

Ingénieurs de test

Testez les fonctionnalités immédiatement lorsque les PR sont ouvertes
Passer entre plusieurs PR sans réinstaller
Vérifiez les corrections et les régressions sur des appareils réels
Plus de temps d'attente pour le traitement de TestFlight

Responsables de produit

Examine les fonctionnalités avant qu'elles soient fusionnées
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 retours d'information plus rapides sur les modifications
Démontrer les fonctionnalités aux parties prenantes instantanément
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/Beta	Capgo Aperçu de la PR
Temps de construction	15-30 min	Moins de 1 min
Passage entre les PRs	5+ min de réinstallation	10 secondes
Complexité de mise en place	Informations de connexion de l'App Store	Un fichier de workflow
Nettoyage	Manuel	Automatique
Mise à jour native code	Requis	Facultatif (JS uniquement)

Meilleures Pratiques

Nommez les canaux clairementUtilisez : pr-{number} convention pour une identification facile
Nettoyage automatique : Supprimez toujours les canaux lors de la fermeture des PR
Restreignez l'accès : Activez uniquement le menu de secousses dans les builds de débogage/étape
Documentez le processus: Ajoutez des instructions de test à votre modèle de PR
Gérer 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 qui affectent les builds natifs

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

Combinez avec Channel Surfing

Les aperçus de PR fonctionnent le mieux lorsqu'ils sont combinés avec la navigation entre les chaînes Votre application peut avoir :

production - Des versions stables pour tous les utilisateurs
beta - Un accès anticipé pour les utilisateurs qui ont opté pour cela
pr-123 - Des aperçus de fonctionnalités pour des PR spécifiques

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

Ressources

Conclusion

Les prévisualisations 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 en utilisant 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 sein de votre équipe. La QA reste débloquée, les gestionnaires de produit passent en revue plus rapidement et les développeurs obtiennent des retours plus rapides.

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