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 à la revue, mais la faire passer aux mains des parties prenantes signifie naviguer dans le labyrinthe de TestFlight ou Google Play beta. Ce qui devrait prendre des minutes tourne en heures d'attente, d'installation et de gestion des builds bêta.

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

C'est ce que les prévisualisations PR 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 à l'application qu'il a déjà.

Le problème de TestFlight

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

1. Développeur ouvre PR - Code est prêt à la revue
2. Attendez-vous à TestFlight - 15-30 minutes de temps de traitement
3. Trouvez et installez - Les testeurs recherchent la bonne build
4. Testez et répétez - Chaque changement signifie attendre à nouveau

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.

Commentaires de PR Fonctionnent

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

1. Commentaire de PR ouvert ou mis à jour - GitHub Action déclenche
2. Bundle téléchargé - Vos modifications JS/CSS sont envoyées à un canal spécifique au commentaire de PR
3. Commentaire publié - Les testeurs reçoivent des instructions dans le commentaire de PR
4. Test instantané - Passer de canal, tester, passer à nouveau

Pas de nouvelles installations d'applications. Pas de 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 Commentaires 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 Capgo guide de démarrage rapide si vous n'avez pas déjà fait cela.

GitHub Flux de travail 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 drapeau lors de la création du canal. Cela permet aux testeurs de passer à la canal à partir de l'application en utilisant le setChannel() API.

Configuration du jeton Capgo

1. Allez à votre Capgo tableau de bord
2. Naviguer dans Paramètres > API Clés
3. Générer une nouvelle clé avec all permissions
4. 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 :

Option 1 : Menu de secousses (la plus simple)

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.

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

Option 2 : Sélecteur de canal personnalisé

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

• listChannels() Ces briques de construction vous permettent de créer une interface utilisateur simple :
• setChannel() Pour un exemple de composant React complet, voir

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

notre article sur la navigation de canaux

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

Nettoyage des canaux PR Lorsqu'un PR est fusionné ou fermé, vous devrez nettoyer le canal. Ajoutez une autre workflow :.

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

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

This supprime le canal lorsque le PR est fermé, gardant votre liste de canaux propre.

Compatibilité de version

Les prévisualisations 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 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évisualisations de PR fonctionnent mieux pour les modifications JavaScript, CSS et des assets qui ne touchent pas les code natives.

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

Ingénieurs de test

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

Gestionnaires de produit

• Révisez les fonctionnalités avant qu'elles soient fusionnées
• Faites des commentaires directement sur le PR
• Vérifiez que l'implémentation correspond aux exigences
• Réduisez le temps de cycle de revue

Développeurs

• Obtenez des retours rapides sur les modifications
• Démontrer les fonctionnalités aux parties prenantes instantanément
• Déboguez les problèmes avec des utilisateurs spécifiques
• Passez moins de temps à gérer les builds bêta

Comparaison : Traditionnel vs Prévisions PR

Meilleures Pratiques

1. Nommer les canaux clairement: Utiliser pr-{number} une convention pour une identification facile
2. Nettoyage automatique: Supprimer toujours les canaux lors de la fermeture des PR
3. Restreindre l'accès: Activer uniquement le menu de secousses dans les builds debug/staging
4. Documenter le processus: Ajoutez des instructions de test à votre modèle de PR
5. 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.

Combinaison 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

• Capgo Mises à jour en temps réel Documentation
• Documentation des chaînes
• Guide de navigation entre les chaînes
• CLI Référence des commandes
• Page de Prévisualisation des PR

Conclusion

Les prévisualisations de PR transforment la façon dont votre équipe passe en revue et testifie 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 configuration est minimale - un fichier de workflow GitHub Actions - et les avantages s'accumulent au fil du temps dans 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.

Continuez à partir de Turn Every Pull Request Into an Installable Preview

Si vous utilisez Turn Every Pull Request Into an Installable Preview pour planifier la mise en route des canaux et la mise en œuvre étalée, connectez-le avec Channels pour les détails d'implémentation dans Channels, Channels pour les détails d'implémentation dans les canaux, Canaux pour les détails d'implémentation dans les canaux, Solution de test bêta pour le flux de travail du produit dans la Solution de test bêta, et Solution de ciblage de version pour le flux de travail du produit dans la Solution de ciblage de version.