Passer au contenu principal
Tutoriel

Transformez chaque demande de tirage en une prévisualisation installable

Arrêtez d'attendre le traitement de TestFlight. Les prévisualisations PR Capgo permettent aux équipes QA, PM et aux parties prenantes de tester les fonctionnalités sur des appareils réels en moins d'une minute.

Martin Donadieu

Martin Donadieu

Responsable de contenu marketing

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 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 builds bêta.

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

C'est ce que les prévisions de PR 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. Le développeur ouvre la PR - Code est prêt à la revue
  2. Attendez-vous à TestFlight - 15-30 minutes de temps de traitement
  3. Trouvez et installez - Les testeurs cherchent la bonne build
  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 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'actualisations par PR. Voici le flux :

  1. PR ouverte ou mise à jour - L'action de GitHub déclenchée
  2. Bundle téléchargé - Vos modifications JS/CSS sont envoyées à un canal PR spécifique
  3. Commentaire publié - Les testeurs reçoivent des instructions dans le PR
  4. Test instantané - Passer entre les canaux, tester, passer à nouveau

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

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 Capgo si vous n'avez pas déjà fait cela. Flux de travail d'Actions Capgo Créer

GitHub Actions Workflow

flag 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 Guide de démarrage rapide __CAPGO_KEEP_0__ setChannel() Flux de travail d'Actions API

Configurer le jeton Capgo

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

Comment les testeurs basculent sur les canaux

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

Option 1 : Menu de secousses (la plus simple)

Activez le menu de secousses avec sélection de canal dans votre configuration Capacitor :

// 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 sur la production.

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

  1. Récupère tous les canaux auto-assignables via listChannels()
  2. Displays channels with search to find specific PRs
  3. Affiche les canaux avec recherche pour trouver des PR spécifiques
  4. 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é

  • listChannels() 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 :
  • 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;
}

- Met l'appareil sur 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');

For un exemple de composant React complet, consultez 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 un 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 la version

Les aperçus de PR ne fonctionnent qu'à condition que le paquet JavaScript soit 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 PR cible une version native différente de celle installée, l'mise à jour 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 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 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 besoin d'attendre le traitement de TestFlight

Gestionnaires de produits

  • Examinez 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éduire le temps de cycle de revue

Développeurs

  • Obtenez 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
  • Gagnez moins de temps pour gérer les builds bêta

Comparaison : Traditionnel vs Aperçu PR

Aspect TestFlight/Bêta Capgo Aperçu PR
Temps de construction 15-30 min <1 min
Passage d'APR 5+ min de réinstallation 10 secondes
Complexité de mise en place Identifiants de l'App Store Un fichier de workflow unique
Nettoyage Manuel Automatique
Changements natifs code Obligatoire Facultatif (JS uniquement)

Meilleures Pratiques

  1. Nommer les canaux clairement: Utiliser pr-{number} convention pour une identification facile
  2. Nettoyage automatique: Supprimer toujours les canaux lorsque les PR se ferment
  3. Restreindre l'accès: Activer uniquement le menu de secousses dans les builds de débogage/étape
  4. Documenter le processus: Ajouter des instructions de test à votre modèle de PR
  5. Gérer les échecs avec élégance: Vérifier que la création de canaux réussit avant d'ajouter des commentaires

Quand 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
  • Les modifications natives Android code
  • Mises à jour de dépendances affectant les builds natives

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

Combinaison avec Channel Surfing

Les aperçus de PR fonctionnent le mieux lorsqu'ils sont combinés avec channel surfingVotre 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 à - tout cela avec la même application installée.

Ressources

Conclusion

Les prévisualisations des 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 versions de beta, les testeurs peuvent passer à n'importe quel canal de 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. Le QA reste débloqué, 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 Turn Every Pull Request Into an Installable Preview planifier la routage des canaux et la mise en production étape par étape, connectez-le à Canaux détails d'implémentation dans Canaux, Canaux détails d'implémentation dans Canaux, Canaux détails d'implémentation dans Canaux, Solution de test bêta pour le flux de travail du produit dans Solution de test bêta, et Solution de ciblage de version pour le flux de travail du produit dans Solution de ciblage de version.

Mises à jour en temps réel pour les applications Capacitor

Lorsqu'un bug de la couche web est en ligne, expédiez la correction par Capgo au lieu d'attendre des jours pour l'approbation de la boutique d'applications. Les utilisateurs reçoivent la mise à jour en arrière-plan tandis que les modifications natives restent dans le chemin de revue normal.

Commencez dès maintenant

Dernières actualités de notre Blog

Capgo vous donne les meilleures informations dont vous avez besoin pour créer une application mobile vraiment professionnelle.