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 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 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 le dispositif, sans aucune réinstallation ou retards de l'application Store ?

C'est ce que les prévisualisations de demande de tirage permettent. Lorsqu'un développeur ouvre une demande de tirage, 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 normale - 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 :

1. Développeur ouvre la demande de tirage - Code est prêt à la revue
2. Attendez la revue de TestFlight - 15-30 minutes de temps de traitement
3. Trouvez et installez - Les testeurs cherchent la bonne version
4. Testez et répétez - Chaque changement signifie une autre attente

Cela crée un goulet d'étranglement. Le QA est bloqué en attendant les builds. Les gestionnaires de produits 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 fonctionnent les aperçus de PR

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 :

1. Une PR est ouverte ou mise à jour - L'action de GitHub est déclenchée
2. Une archive est téléchargée - Vos modifications JS/CSS sont envoyées à un canal spécifique à la PR
3. Comment publié - Les testeurs reçoivent des instructions dans le PR
4. Test instantané - Passer d'un canal à l'autre, tester, revenir en arrière

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

Configuration des prévisualisations de PR

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

GitHub Actions Workflow

La clé est .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 --self-assign marquer lors de la création du canal. Cela permet aux testeurs de passer au canal depuis l'application en utilisant le setChannel() API.

Configuration de l'Capgo Token

1. Allez à votre Capgo tableau de bord
2. Naviguez vers Paramètres > API Clés
3. Générez une nouvelle clé avec all permissions
4. Ajoutez-le comme CAPGO_TOKEN dans vos secrets de votre GitHub dépôt

Comment les Testeurs Passent aux Canaux

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

Option 1 : Faire trembler le menu (la plus simple)

Activer le menu de tremblement avec un sélecteur de canal dans votre Capacitor de configuration :

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

Les testeurs font trembler 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 font trembler à nouveau et reviennent à la production.

Le menu de tremblement gère l'ensemble de la flux automatiquement :

1. Récupère tous les canaux auto-assignables via listChannels()
2. Affiche les canaux avec recherche pour trouver des PR spécifiques
3. Télécharge la mise à jour après sélection
4. Propose de recharger avec les options « Recharger maintenant » / « Plus tard »

Option 2 : Sélecteur de canal personnalisé de l'interface utilisateur

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() - Mettez 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 de construction, 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 entre les canaux Nettoyer les canaux PR.

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

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

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

Compatibilité de version

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

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

Capgo automatically checks version compatibility. If a PR’s bundle targets a different native version than what’s installed, the update won’t be applied. This prevents crashes from incompatible code.

For PRs that do require native changes, you’ll need to distribute a new TestFlight/Play Store build. PR previews work best for JavaScript, CSS, and asset changes that don’t touch native code.

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

Ingénieurs de test

• Tester les fonctionnalités immédiatement lors de l'ouverture des PR
• Passer entre plusieurs PR sans réinstaller
• Vérifier les correctifs et les régressions sur des appareils réels
• Aucune attente pour le traitement par TestFlight

Gestionnaires de produits

• Examiner les fonctionnalités avant qu'elles soient fusionnées
• Donner 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
• Démontrer des fonctionnalités de démo aux parties prenantes instantanément
• Déboguer les problèmes avec des utilisateurs spécifiques
• Passer moins de temps à gérer les builds de bêta

Comparaison : Prévisions traditionnelles vs Prévisions PR

Meilleures Pratiques

1. Nommez les canaux clairement: Utilisez pr-{number} une convention pour une identification facile
2. Auto-nettoyage: Supprimez toujours les canaux lorsque les PR se ferment
3. Limitation d'accès: Activez uniquement le menu de secousses dans les builds de débogage/étape
4. Documentez le processus: Ajoutez des instructions de test à votre modèle de PR
5. Gestion des échecs: 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 :

• De nouveaux Capacitor plugins
• Les modifications natives iOS code
• Les modifications natives Android code
• Mises à jour de dépendances affectant les builds natives

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

La combinaison avec Channel Surfing

Les aperçus PR fonctionnent le mieux lorsqu'ils sont combinés avec le channel surfingVotre 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 basculer vers n'importe quel canal de PR, tester la fonctionnalité, puis basculer à nouveau - tout cela avec la même application installée.

Ressources

• Capgo Mises à jour en direct Documentation
• Documentation des canaux
• Guide de navigation entre canaux
• CLI Référence des commandes
• Page de solutions de prévisualisation de PR

Conclusion

Les prévisualisations de PR transforment la façon dont votre équipe passe en revue et teste les fonctionnalités mobiles. Au lieu d'attendre le traitement de TestFlight et de gérer plusieurs builds de beta, les testeurs peuvent basculer vers n'importe quel canal de PR en quelques secondes en utilisant l'application qu'ils ont déjà installée.

La configuration est minimale - un seul fichier de workflow GitHub - 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 d'information plus rapides.

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

Continuez de Turn Every Pull Request Into an Installable Preview

Si vous utilisez Transformez chaque demande de tirage en une prévisualisation installable pour planifier la mise en route de canal et la mise en production étape par étape, connectez-l’à 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 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.