Aller au contenu principal
Aperçu de PR

Révisez chaque pull request sur un vrai téléphone

Votre CI envoie le web build de chaque pull request sur son propre canal Capgo. Les relecteurs scannent un QR code ou changent de canal dans l'app pour l'essayer sur leur appareil, et le canal est supprimé à la fermeture de la PR. Les changements au code natif nécessitent toujours un nouveau build.

  • Un canal par pull request
  • Aperçu QR code
  • Nettoyage lors de la fermeture de la PR

Le problème

Un changement web ne devrait pas nécessiter un nouveau binaire à réviser

Réviser une PR avec des builds de test pour les stores

  1. Le développeur ouvre une PR

    Le changement est prêt pour la revue, mais personne ne peut encore l'essayer sur un téléphone.

  2. Build, signature et upload

    Quelqu'un génère un binaire natif pour la branche, le signe, l'envoie sur TestFlight ou un canal de test Play Store, puis attend le traitement.

  3. Inviter et installer

    Les relecteurs doivent être ajoutés comme testeurs et installer ce build précis.

  4. Répéter pour chaque correction

    Chaque commentaire de revue modifiant code signifie un nouveau build, un nouvel upload et une nouvelle installation.

Chaque cycle de revue dépend d'un build natif, même si seul le JavaScript a changé.

Le coût réel pour l'équipe

Chaque build

Attend le traitement du store

Chaque build que vous envoyez sur TestFlight ou sur un canal de test Play est traité avant que les testeurs ne puissent l'installer. Cela s'applique à chaque build.

Chaque PR

Nécessite son propre build natif pour le test

Sans Live Update, les reviewers ne peuvent tester une branche qu'après qu'un binaire a été buildé, signé et envoyé, même pour un changement purement web.

Feedback tardif

La revue a lieu après le départ de l'auteur

Lorsque la revue attend les builds, les retours arrivent tardivement, l'auteur est déjà sur une autre tâche et la branche s'éloigne de la branche main.

Comment ça marche

Comment les équipes prévisualisent les pull requests avec Capgo

Quatre étapes CI : configurez une clé limitée une fois, envoyez à chaque push, partagez la preview et nettoyez à la fermeture. Chaque commande ci-dessous provient de la doc Capgo.

  1. Créez une clé App Preview et activez les previews

    Un admin crée une clé App Preview API pour la CI. Elle peut créer des canaux de preview et envoyer des bundles, mais ne peut pas modifier votre canal par défaut ou de production. Les previews s'activent une seule fois par application.

    # once, run by an admin (not the preview key)
npx @capgo/cli@latest app set com.example.app --preview
    Clés App Preview API

  2. Envoyez le build de la PR sur son propre canal

    À chaque push, la CI compile l'application web et l'envoie avec une version de bundle unique. bundle upload --channel crée le canal pr-<number> s'il n'existe pas et lie le bundle à celui-ci.

    npx @capgo/cli@latest bundle upload com.example.app \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --path ./dist \
  --channel "pr-$PR_NUMBER" \
  --bundle "1.2.3-pr.$PR_NUMBER.$GITHUB_RUN_NUMBER"
    Les previews de PR dans la doc des canaux

  3. Postez la preview sur la PR

    get-qr génère un QR code pour le canal, ou les URLs de preview avec --url, afin que la CI puisse les ajouter en commentaire de PR.

    npx @capgo/cli@latest get-qr com.example.app \
  --channel "pr-$PR_NUMBER" \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --url
    Référence get-qr

  4. Supprimez le canal à la fermeture de la PR

    Exécutez ceci lors de l'événement de fermeture de la pull request. Avec une clé App Preview, il supprime uniquement le canal et le bundle lié créés par cette clé.

    npx @capgo/cli@latest channel delete \
  "pr-$PR_NUMBER" com.example.app \
  --apikey "$CAPGO_PREVIEW_KEY" \
  --delete-bundle \
  --success-if-not-found
    Référence CLI du canal

Autres moyens pour les testeurs de passer sur un canal PR

Les deux nécessitent un canal permettant l'auto-assignation. Une clé App Preview ne le configure pas ; avec cette clé, partagez le QR de preview ou définissez un device override dans la console.

Menu Shake

Activez le menu par secousse dans vos builds internes. Les testeurs secouent l'appareil pour ouvrir le menu de test de Capgo, et le sélecteur de canal par secousse leur permet de choisir un canal.

// capacitor.config.ts (internal builds)
CapacitorUpdater: {
  shakeMenu: true,
}

Sélecteur intégré

Ajoutez un champ channel à un écran de paramètres développeur et appelez setChannel() avec le nom du canal de la PR.

import { CapacitorUpdater } from '@capgo/capacitor-updater'

await CapacitorUpdater.setChannel({
  channel: 'pr-123',
  triggerAutoUpdate: true,
})
Référence setChannel()

Qui utilise les PR previews

Toute personne examinant la pull request peut la tester sur un téléphone, pas seulement l'auteur.

Ingénieurs QA

  • Testez le build web de la PR sur votre propre appareil
  • Passez d'un canal de PR à l'autre sans réinstaller l'app
  • Le nom du canal correspond au numéro de la PR, vous savez donc quel code vous exécutez

Chefs de projet

  • Testez une fonctionnalité sur un téléphone avant sa fusion
  • Scannez le QR code posté sur la PR
  • Laissez vos retours directement sur la PR

Développeurs

  • Obtenez des retours sur l'appareil tant que la PR est ouverte
  • Chaque push met à jour le canal de la PR
  • Pas de build natif pour les changements JS uniquement

Builds de test pour les stores vs canaux PR Capgo

  • Installer une PR sur un téléphone

    TestFlight / Play testing
    Build natif, signature et traitement par les stores
    Canal PR Capgo
    Web build et upload du bundle depuis la CI

  • Passer d'une PR à l'autre

    TestFlight / Play testing
    Installer un autre build
    Canal PR Capgo
    Scanner un autre QR code ou changer de canal

  • Configuration du testeur

    TestFlight / Play testing
    Invitation du testeur, puis installation de chaque build
    Canal PR Capgo
    Installer l'app une seule fois

  • Changements code natifs et de plugins

    TestFlight / Play testing
    Oui
    Canal PR Capgo
    Non, nécessite un Native Build

Solutions par type d'équipe

Trouvez la solution adaptée aux besoins de votre équipe

Enterprise

Déploiements multi-apps et multi-équipes

Startups

Livrez vite sans la complexité

Développeurs solo

Essai gratuit de 14 jours, CLI upload

Agences

Gérez plusieurs apps clients

Apps développées avec Capacitor

Les apps produits nécessitent des changements mobiles révisables

Les apps d'apprentissage, d'événements ou communautaires peuvent avoir des changements d'onboarding, de pratique, de session live ou d'abonnement en cours de révision simultanément. Les PR previews permettent aux équipes produit, QA et support d'inspecter un build prêt pour le mobile avant le merge.

StudySmarter - icône d'app scolaire et universitaire ÉDUCATION

StudySmarter - École & université

App d'éducation où les changements de cours et d'abonnement nécessitent une revue par les parties prenantes.

Installations Google Play
6,5 M
Note du store
4.8
Icône de l'app Poll Everywhere ENTREPRISE

Poll Everywhere

App d'engagement en direct où les flux d'événements doivent être testés avant le merge.

Installations Google Play
1,1 M
Note du store
3.2
lichess • Free Online Chess app icon PLATEAU DE JEU

lichess • Échecs en ligne gratuits

Une application communautaire où les écrans de tournoi et d'analyse profitent des aperçus d'appareil.

Installations Google Play
11,3 M
Note du store
4.3

Témoignages clients

Ce que disent les équipes qui déploient avec Capgo

5.0/5 noté par les équipes de développeurs 9,400+ équipes Lire les avis

Nate van Jole

CTO, Privé

« L'installation a pris moins d'une journée. Les déploiements progressifs par canal me permettent de tester sur mon propre appareil avant de toucher les utilisateurs en production. »

Portrait de Michael Haberler

Michael Haberler

nethead emeritors

« Beau travail sur le plugin updater. Il fonctionne parfaitement pour moi, et les live updates sont un super accélérateur pour tester rapidement. »

no-tone @ Webincode

Développeur, Webincode

« Pouvoir ajouter des Device ID à certains groupes et n'envoyer les changements qu'à certains groupes, ça nous sauve la vie. »

FAQ

Questions des équipes sur les PR previews

Des réponses claires pour ceux qui mettent en place la CI et pour les relecteurs.

Do reviewers need a new build for each PR?

Pas si la PR ne modifie que la couche web. Les relecteurs installent l'app une seule fois, et le JavaScript, le HTML, le CSS et les assets de chaque PR arrivent dans son propre canal. Si la PR ajoute un plugin ou modifie du code natif, un build natif est nécessaire. Lancez build needed dans la CI pour le détecter.

Ce qui nécessite un build natif

La clé CI peut-elle toucher notre canal de production ?

Pas avec une clé App Preview API. Elle peut créer des canaux de preview, envoyer des bundles, et supprimer uniquement le canal et le bundle qu'elle a créés. Elle ne peut pas modifier le canal par défaut ou principal. Dans les GitHub Actions, lancez le job sur pull_request, pas sur pull_request_target, et limitez-l’aux PR provenant du même dépôt.

Clés App Preview API

Comment les relecteurs ouvrent-ils la preview ?

Un admin active les previews une seule fois avec app set --preview. Ensuite, get-qr affiche un QR code pour le canal de la PR, et --url affiche l'URL de la preview web et le deep link. Postez-les dans un commentaire de PR.

Référence get-qr

Que deviennent les anciens canaux et bundles de PR ?

Ajoutez un job sur l'événement pull request closed qui exécute channel delete avec --delete-bundle et --success-if-not-found. Avec une clé App Preview, cela supprime le canal et le bundle qui lui est lié. Les bundles des pushes précédents peuvent être supprimés avec bundle cleanup, à condition d'utiliser une clé disposant des droits de suppression.

référence du canal CLI

Est-ce que cela fonctionne avec GitLab, Bitbucket ou Azure DevOps ?

Oui. Les étapes utilisent des commandes Capgo CLI, elles s'exécutent donc dans n'importe quelle CI. La doc contient des guides d'intégration pour GitHub Actions, GitLab CI, Bitbucket Pipelines et Azure DevOps.

Intégrations CI/CD

Prévisualisez votre prochain pull request sur un téléphone

Ajoutez les étapes d'upload, de QR et de nettoyage à votre CI et testez-les sur votre propre app pendant l'essai gratuit.

Essai gratuit de 14 jours, sans carte bancaire. Les changements natifs nécessitent toujours un nouveau build.