Lancer une application Capacitor devient plus simple quand chaque release suit un parcours clair, du code web au build natif, jusqu'à l'utilisateur. Voici une configuration étape par étape des outils et services qui vous aident à déployer, surveiller et mettre à jour votre application, et notamment la place où Capgo s'intègre.
Nous avons analysé 45 commentaires YouTube et Reddit sur les outils de lancement d'applications Capacitor et constaté que 22 % mentionnaient des outils de débogage et des problèmes de performance.
Table des matières
- Étape 1 : identifier ce qui peut être déployé en OTA
- Étape 2 : Préparer le projet Capacitor et les builds natifs
- Étape 3 : ajouter Capgo pour sécuriser vos live updates
- Étape 4 : Créer des canaux et déployer les mises à jour progressivement
- Étape 5 : Connecter la CI/CD au workflow de release
- Étape 6 : Surveiller les releases et vérifier la préparation au rollback
- FAQ
- Conclusion
Étape 1 : identifier ce qui peut être déployé en OTA
Commencez par classer les modifications prévues en deux groupes : changements au niveau web et changements natifs. Les applications Capacitor utilisent le code web pour les écrans et la logique de l’application, puis relient ce code aux fonctionnalités natives de l’appareil via des plugins.
Une mise à jour OTA (over the air) remplace le bundle web de l’application sans remplacer le paquet natif installé. Cela convient à une correction de texte, un ajustement CSS ou un correctif de bug JavaScript. Un nouveau plugin, une permission ou une modification du code natif compilé nécessite un nouveau build natif et le parcours de publication habituel sur les stores.
Avant de choisir un service de lancement, établissez une liste de release. Marquez chaque modification comme web-only ou native. Cette simple distinction empêche qu’une petite correction d’interface soit bloquée dans le même processus qu’une nouvelle permission d’appareil.
Les live updates conviennent aux modifications qui ne nécessitent pas de mise à jour binaire. Utilisez cette limite comme règle de release. La revue du store et les builds natifs restent importants lorsque le code compilé de l’application change.
L’OTA est désormais une fonctionnalité de base, donc vérifiez ce qui l’entoure. Un service peut envoyer un nouveau bundle, mais cela seul ne vous dit pas comment cibler un groupe de test ou récupérer d’une mauvaise release. Les mises à jour différentielles peuvent envoyer uniquement les parties modifiées au lieu d’un bundle complet, ce qui réduit les données nécessaires pour chaque mise à jour. Les canaux séparent les audiences, tandis que le rollback vous permet de ramener les utilisateurs vers une version connue et stable.
Ces détails influencent le choix des outils. Capgo combine les live updates, les canaux, le contrôle des déploiements et la surveillance des releases. Pour une vue d’ensemble de la stack de lancement, explorez les outils pour développeurs mobiles.
- Web code, styles et assets : évaluez la livraison OTA.
- Plugins natifs, permissions ou code compilé : planifiez un nouveau build.
- Modifications web risquées : planifiez un canal, un déploiement progressif et un chemin de rollback.
Notez cette limite avant la première release en production. Cela donne aux ingénieurs et aux responsables produit la même définition de ce qui peut être déployé rapidement.
Étape 2 : Préparer le projet Capacitor et les builds natifs
Assurez-vous que l’application se compile de la même manière sur la machine d’un développeur et dans votre pipeline de release. Les projets Capacitor peuvent utiliser des frameworks web tels qu’Angular, React ou Vue, ainsi que du web code pur. Gardez le processus de build du framework séparé de l’étape de compilation native.
Le flux de build de base comporte trois parties. D’abord, compilez l’application web avec les outils de son framework. Ensuite, copiez les assets web finis dans les projets iOS et Android. Puis compilez chaque application native avec les outils de sa plateforme.
Pour iOS, l’étape de compilation native utilise Xcode. Pour Android, utilisez Android Studio ou les outils de build natif de votre plateforme. La livraison web a son propre chemin de build et d’hébergement si vous déployez également une Progressive Web App, ou PWA. Une PWA est la version web que les utilisateurs peuvent consulter via un navigateur ou installer depuis celui-ci.
Rendez le build reproductible avant d'ajouter d'autres outils de release. Utilisez une seule commande ou un script documenté pour le build web, puis intégrez l'étape de copie des assets à ce même flux. Si un développeur doit se souvenir d'une étape de copie séparée, il est facile de tester un bundle et d'en packager un autre.
Vérifiez aussi le côté natif dès le début. Installez l'application de chaque plateforme sur un appareil de test. Confirmez que les plugins dont l'application a besoin fonctionnent dans l'application compilée, et pas seulement dans un aperçu navigateur. Les tests navigateur peuvent détecter les problèmes de mise en page, mais ils ne peuvent pas prouver que l'accès à la caméra ou un autre pont natif fonctionne sur un appareil.
Gardez la configuration des plugins sous contrôle de version. Pour un plugin personnalisé, documentez ses exigences natives et comment les membres de l'équipe peuvent le compiler. Cette trace aide le responsable de la release à repérer quand un changement quitte le domaine OTA et exige un nouveau binaire.
Capacitor peut convenir à une équipe qui a déjà une application web et qui souhaite un packaging natif ainsi que l'accès aux fonctionnalités de l'appareil. React Native et Flutter sont d'autres options que les équipes peuvent peser au moment de planifier une application mobile ; Electron est souvent envisagé pour les applications de bureau. Le bon choix dépend de la base de code et des plateformes cibles : décidez selon les besoins réels de votre application plutôt que selon les étiquettes de framework.
Une fois que les deux builds natifs sont reproductibles, vous avez la base stable nécessaire pour la livraison OTA. Capgo fournit également des outils de build natif pour les équipes qui veulent des builds cloud en plus des live updates.
Étape 3 : ajouter Capgo pour sécuriser vos live updates
Configurez Capgo une fois que le premier build natif de votre app fonctionne. Capgo est un service de live update pour les applications Capacitor. Il distribue les bundles web aux apps installées, tandis que les changements natifs code continuent de passer par le build et les stores.
Commencez par ajouter l'application à Capgo et connecter son projet Capacitor au workflow de mise à jour. Conservez l'étape de build web existante de l'application. Le service de mise à jour a besoin des assets web compilés que votre app doit exécuter, pas de sources non compilées.
Vérifiez ensuite comment une release passe de votre machine au service. Capgo prend en charge la publication via un workflow en ligne de commande, avec un déploiement en une seule commande. Cela peut rendre une release plus facile à rejouer : la même commande peut être lancée par un développeur pendant les tests ou par la CI une fois les vérifications de l'équipe passées.
Avant d'utiliser les live updates avec de vrais utilisateurs, confirmez que l'application native installée peut recevoir le bundle. Faites correspondre les dépendances natives de l'app à celles attendues par le bundle. Capgo Observe peut signaler un canal qui sert un bundle dont les packages natifs diffèrent de ceux de l'application installée, et identifie les packages concernés.
La sécurité doit figurer dans la checklist de release, et non être une revue de dernière minute. Vérifiez que les bundles sont signés et que l'équipe comprend qui peut les publier. Capgo propose ISO 27001 et SOC 2 Type II sur son plan Enterprise, et son code, son historique de releases, ses taux de livraison et ses avis de sécurité sont publics.
Les live updates ont une limite stricte. Elles remplacent la couche web, pas le package natif de l’application. N’utilisez pas une release OTA pour ajouter un plugin natif ou modifier les permissions demandées par l’app. Compilez et soumettez une nouvelle version pour ces changements.
Si vous évaluez le coût de l’abonnement, les tarifs de Capgo sont par organisation. Les plans commencent à 14 $ par mois en facturation mensuelle, ou 12 $ par mois en facturation annuelle. L’essai gratuit illimité de 14 jours ne nécessite pas de carte bancaire, vous pouvez donc tester le parcours de release avant de passer en production.
À retenir : Considérez l’OTA comme un canal de release pour le bundle web, les modifications natives passant par un nouveau build.
Étape 4 : Créer des canaux et déployer les mises à jour progressivement
Utilisez les canaux pour séparer qui reçoit un bundle. Un canal est un parcours de release nommé, par exemple un pour les tests internes et un autre pour la production. Cela permet à l’équipe de vérifier un changement avec un groupe restreint avant qu’il n’atteigne l’audience complète.
Mettez en place le plan de canaux avant la première release en production. Gardez des noms faciles à comprendre et notez qui peut publier sur chacun. Un canal développeur peut servir aux vérifications d’équipe ; un canal production doit avoir une étape d’approbation claire.
Pour un changement à risque élevé, commencez par un petit pourcentage d'appareils. Capgo peut servir un nouveau bundle à un pourcentage fixe d'appareils pendant que les autres utilisateurs restent sur une version stable de secours. Un groupe fixe reste assigné à sa cohorte de déploiement, ce qui permet à l'équipe de comparer le même groupe au fil du temps plutôt que de faire entrer et sortir des utilisateurs.
Déterminez ce qui devrait stopper le déploiement avant de le lancer. Capgo peut mettre en pause automatiquement le processus lorsque le taux d'échec dépasse un seuil, avec une taille d'échantillon minimale. Définissez un seuil cohérent avec la release et vos modes d'échec habituels. Un seuil trop permissif peut détecter un problème trop tard ; un seuil trop strict peut mettre en pause une release saine.
Enregistrez le responsable de la release, la version du bundle, le canal cible et la règle de pause dans le ticket de changement ou la release note. Si le support client signale un problème, cet enregistrement aide l'ingénieur d'astreinte à identifier quels utilisateurs ont pu recevoir le bundle.
La conception des canaux fait partie du workflow de release, pas seulement d'une tâche de nommage. Déploiements progressifs par canal peut faciliter le contrôle des releases. Gardez votre plan simple au début. N'ajoutez des canaux que lorsqu'ils répondent à un vrai besoin de test ou de déploiement.
Conseil de pro : Testez la condition de pause avec un déploiement hors production. Confirmez qui est notifié et ce que l'équipe doit faire ensuite.
Une fois que la cohorte de test est validée, élargissez la release par étapes planifiées. Si le taux d'échec augmente, mettez en pause ou effectuez un rollback avant que d'autres appareils ne reçoivent le bundle.
Étape 5 : Connecter la CI/CD au workflow de release
CI/CD signifie intégration continue et livraison continue. Dans un workflow d’application mobile, il peut compiler le bundle web, lancer des vérifications et déclencher une tâche de release après l’approbation de code et son arrivée sur une branche. Le but est que les mêmes étapes s’exécutent dans le même ordre à chaque fois.
Commencez par lister ce qu’un humain fait aujourd’hui. Par exemple, quelqu’un peut fusionner une modification, compiler l’application web, copier ses assets, tester le résultat, puis envoyer le bundle. Transformez ces actions en tâches de pipeline, une par une. Conservez une approbation manuelle avant la production jusqu’à ce que l’équipe fasse confiance aux vérifications.
Choisissez un système de CI qui correspond à l’endroit où se trouve le code et à la façon dont votre équipe gère les builds natifs. GitHub Actions, Bitrise et Fastlane sont des options utilisées par les équipes dans les workflows de release mobile. Leur configuration exacte dépend de votre dépôt, de votre processus de signature et de votre environnement de build, donc testez sur une branche avant de connecter les identifiants de production.
Gardez les secrets hors des fichiers source. Stockez les éléments de signature et les identifiants API dans le coffre-fort de secrets protégé de votre système de CI. Limitez l’accès aux personnes et aux jobs qui en ont besoin. Un pipeline réussi ne doit pas exposer une clé dans un log ni faire de chaque contributeur un éditeur de production.
Séparez la vérification en étapes claires. Lancez d’abord le build web. Puis exécutez les tests qui couvrent les écrans principaux et le comportement de l’application. Ce n’est qu’après le passage de ces vérifications que le workflow doit préparer un bundle OTA ou un build natif. Pour les modifications natives, envoyez l’application à travers le processus normal de build de la plateforme et de publication sur les stores.
Utilisez des jobs CI ou des règles d’approbation séparés pour les canaux de test et de production. Cela rend plus difficile la mise en ligne accidentelle d’un bundle de test. Gardez le journal de release lié à la révision code, à la version du bundle et au canal afin de pouvoir retracer un signalement utilisateur jusqu’à une modification.
Le flux d’upload via CLI et CI de Capgo s’intègre parfaitement à ce pipeline. Commencez par automatiser une release sur un canal de test. Une fois que l’équipe peut vérifier la bonne version et confirmer que le bon public l’a reçue, ajoutez une approbation production explicite. CI/CD, tests et gestion des releases doivent vivre dans le même workflow. Voir la vue d’ensemble des outils DevOps mobiles.
L’automatisation doit éliminer les étapes manuelles répétitives, pas l’ownership. Attribuez un reviewer nommé à chaque release production, même si le pipeline fait l’essentiel du travail.
Étape 6 : Surveiller les releases et vérifier la préparation au rollback
Une release n’est pas terminée quand l’upload est fini. Surveillez si le bundle s’installe et si l’app continue de fonctionner après réception par les utilisateurs. Cette vision aide l’équipe à distinguer un problème de livraison d’un bug produit.
Capgo Observe suit les installations, les tentatives échouées, l’adoption et le taux de succès pour la version et le canal exacts. Les données apparaissent par buckets de cinq minutes après qu’un bundle soit en ligne. Cela donne au propriétaire de la release une vue de l’adoption en temps réel, plutôt qu’un simple résumé de fin de journée.
Définissez les signaux à vérifier avant publication. Regardez d’abord les tentatives échouées et le taux de succès. Comparez ensuite l’adoption au groupe de rollout. Si un bundle a une faible adoption, le problème peut être la livraison ou l’éligibilité de l’app ; si les échecs augmentent après réception, mettez en pause et investigatez avant d’élargir le rollout.
Rédigez un runbook de rollback pendant que l’app est saine. Il doit préciser qui peut déclencher un rollback, quel bundle stable restaurer et comment l’équipe confirmera que le changement a bien atteint les appareils. Un rollback n’est utile que si quelqu’un sait quand l’utiliser et peut vérifier le résultat.
Testez le chemin de récupération dans un canal sûr. Publiez un bundle de test, vérifiez que la release apparaît dans la surveillance, puis entraînez-vous à revenir à une version connue et stable. N’attendez pas un incident client pour découvrir où se trouve le contrôle de rollback.
La surveillance des releases aide aussi pour la compatibilité native. Si un bundle attend un package absent de l’app installée, l’équipe doit détecter cette incohérence plutôt que de la traiter comme un bug web ordinaire. Vérifiez les informations de dépendances avant d’élargir un déploiement progressif.
Concentrez le dashboard sur les signaux qui mènent à l’action. Une métrique sans responsable ni plan de réponse ne sera d’aucune utilité lors d’un incident de release.
Avant chaque push en production, confirmez que le fallback stable est toujours disponible et que le responsable de la release peut accéder au workflow de rollback. Puis suivez, adoptez et faites un rollback selon ce que montrent les données de la release.
FAQ
Que peut mettre à jour une application Capacitor en OTA ?
Une app Capacitor peut recevoir des modifications de la couche web en OTA lorsque la mise à jour ne nécessite pas un nouveau binaire natif. Cela inclut les modifications du code web, des styles ou des assets. Un nouveau plugin, une permission ou une modification native compilée nécessite un nouveau build de l’app et une release sur le store. Gardez cette distinction dans votre checklist de release.
Faut-il un build séparé pour iOS et Android ?
Oui, il vous faut des builds natifs spécifiques à chaque plateforme pour iOS et Android. L’application web peut partager une grande partie de son code, mais chaque projet natif est compilé avec les outils de sa plateforme. Vous pouvez automatiser ces builds en CI/CD, ou utiliser des services de build natif cloud dans le cadre de la configuration de la release.
Puis-je utiliser Angular, React ou Vue avec Capacitor ?
Oui. Capacitor peut fonctionner avec des applications web construites avec Angular, React, Vue ou du simple code web. Compilez l’application avec les outils de son framework, puis copiez les assets générés dans les projets natifs avant de les compiler. Testez les plugins natifs sur des appareils, car un build navigateur ne peut pas garantir que toutes les fonctionnalités de l’appareil fonctionnent.
Comment les canaux et le rollback aident-ils à protéger une release ?
Les canaux vous permettent d’envoyer un bundle à un groupe défini avant d’élargir sa portée. Le rollback offre à l’équipe un moyen de revenir à un bundle stable si la santé de la release se dégrade. Définissez à l’avance la taille du déploiement progressif et les conditions d’arrêt, puis testez le processus de récupération dans un canal sûr avant de vous y fier en production.
Capgo propose-t-il un essai gratuit ?
Oui. Capgo propose un essai gratuit illimité de 14 jours, sans carte bancaire. Ses plans sont des abonnements par organisation. Vous pouvez profiter de l'essai pour tester le parcours de votre bundle web — upload, distribution par canaux, suivi des releases — avant de décider si l'outil s'intègre à votre workflow.
Conclusion
Compilez d'abord l'application native, établissez une frontière nette entre les changements OTA et natifs, puis ajoutez le déploiement progressif et le monitoring. Capgo convient aux équipes qui veulent des live updates avec des canaux, de la visibilité sur les releases et des contrôles de rollback. Démarrez l'essai gratuit de 14 jours et testez un bundle dans un canal hors production avant votre premier déploiement en production.
