Tournez chaque demande de tirage en un aperçu 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 la revue bêta de TestFlight ou Google Play. Ce qui devrait prendre des minutes se transforme en heures d'attente, d'installation et de gestion de versions bêta.

Et si votre application de production pouvait récupérer les dernières modifications de n'importe quel requête de fusion directement sur le dispositif, sans aucune réinstallation ou retard de l'App Store ?

C'est ce que les prévisualisations de requête permettent. Lorsqu'un développeur ouvre une requête de fusion, 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 la requête de fusion - Code est prêt à la revue
Attendez TestFlight - 15-30 minutes de temps de traitement
Trouvez et installez - Les testeurs cherchent la bonne version
- Testez et répétez - Chaque changement signifie une autre attente

Ce processus crée un goulet d'étranglement. Le QA est bloqué en attendant les versions. 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 les prévisions PR fonctionnent

Les prévisions PR utilisent le système de canal de Capgo pour créer des flux de mise à jour par PR. Voici le flux :

Une PR est ouverte ou mise à jour - L'action de GitHub est déclenchée
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 d'un canal à un autre, tester, passer à un autre canal

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

Configurer les prévisions de PR

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

GitHub Actions Workflow

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

__CAPGO_KEEP_0__. --self-assign __CAPGO_KEEP_0__ setChannel() API

Configuration de Capgo Token

Allez dans votre Capgo tableau de bord
Naviguez vers Paramètres > Clés API
Générez une nouvelle clé avec all permissions
Y ajoutez-les comme CAPGO_TOKEN dans vos secrets de repository GitHub

Comment les testeurs changent de canal

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

Activez 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 reviennent à la production.

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

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

Option 2 : Sélecteur de canal personnalisé UI

Construirez 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 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 complet de composant React, voir Notre article sur la navigation de chaînes.

Nettoyer les 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 ainsi votre liste de canaux propre.

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 code (nouveaux plugins Capacitor pour iOS/Android), les testeurs auront besoin d'une nouvelle build native.

Capgo 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 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 actifs qui ne touchent pas les modifications natives code.

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

Ingénieurs QA

context : Page/zone : Page de marketing des solutions Capgo. Rôle : Étiquette de navigation ou élément de menu court. Vu dans : page solutions/pr-preview.astro. Clé de message `solutions_pr_preview_teams_qa` (Solutions Pr Preview Teams Qa).
Passer entre plusieurs PR sans réinstaller
Vérifier les correctifs et les régressions sur des appareils réels
Plus d'attente pour le traitement de 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 les fonctionnalités aux parties prenantes instantanément
Déboguer les problèmes avec des utilisateurs spécifiques
Économisez du temps pour gérer les builds bêta

Comparaison : Préversions traditionnelles vs Préversions PR

Aspect	TestFlight/Bêta	Capgo Préversion PR de Capgo
Temps de construction	15-30 min	<1 min
Passer d'une PR à l'autre	5+ min de réinstallation	10 secondes
Complexité de mise en place	Identifiants de magasin App Store	Un fichier de workflow
Nettoyage	Manuel	Automatique
Modifications natives code	Obligatoire	Facultatif (seulement JS)

Meilleures pratiques

Nommez les canaux clairement: Utilisez pr-{number} une convention pour une identification facile
Nettoyage automatique: Supprimer toujours les canaux lorsque les PR se ferment
Limitation d'accès: Activer uniquement le menu de secousses dans les builds de débogage/étape
Documenter le processus: Ajouter des instructions de test à votre modèle de PR
Gérer les échecs avec élégance: Vérifier 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
context : Fragment de texte HTML d'une chaîne de Capgo (clé de page `capwesome_diff_plugins_capgo`). Zone : Page de comparaison Capawesome. Rôle : Paragraphe marketing ou juridique long. Voir dans : page capwesome.astro. Conserver les termes de produit/marque et les termes de développeur exactement. Clé de message `capwesome_diff_plugins_capgo` (Différences de plugins Capawesome Capgo). » : Nouveaux plugins code pour HTML » : Nouveaux plugins code pour iOS natif
Mise à jour native d'Android code
Mises à jour de dépendances affectant les builds natifs

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

Combinaison avec Channel Surfing

Les prévisions PR fonctionnent le mieux lorsqu'elles sont combinées avec channel surfing. Votre application peut avoir :

production - Sorties stables pour tous les utilisateurs
beta - Accès précoce pour les utilisateurs qui ont opté pour cela
pr-123 - Prévisions de fonctionnalités pour des PR spécifiques

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

Ressources

Conclusion

Les aperçus PR transforment la façon dont votre équipe passe en revue et test les fonctionnalités mobiles. Au lieu d'attendre le traitement de TestFlight et de gérer plusieurs versions de beta, 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 seul fichier de workflow GitHub - et les avantages s'accumulent au fil du temps dans votre équipe. La QA reste débloquée, les responsables 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 de Turn Every Pull Request Into an Installable Preview

Si vous utilisez Turn Every Pull Request Into an Installable Preview planifier la routage du canal et la mise en production é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 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. Crédits de l'article

Transformez chaque demande de tirage en une prévisualisation installable