Un bug de la couche web dans une app Capacitor peut souvent être corrigé sans demander aux utilisateurs d'installer un nouveau build depuis les stores. Un logiciel de mise à jour OTA envoie les changements éligibles au bundle JS de l'app pendant que son shell natif reste inchangé. Je vais vous guider à travers un parcours de release qui commence par la QA, passe par un déploiement progressif contrôlé et inclut des vérifications en cas d'échec.
Nous avons analysé 69 commentaires et questions sur YouTube, Quora et Reddit concernant les logiciels de mise à jour OTA, et 36 % d'entre eux portaient sur les détails d'implémentation.
Table des matières
- Étape 1 : Identifiez les changements de l'app pouvant être déployés en OTA
- Étape 2 : configurez les canaux QA, bêta et production
- Étape 3 : Connectez le logiciel de mise à jour OTA au CI/CD et déployez
- Étape 4 : Protégez vos releases avec rollback et contrôles de sécurité
- Étape 5 : Suivez l'adoption et améliorez le prochain déploiement progressif
- FAQ
- Conclusion
Étape 1 : Identifiez les changements de l'app pouvant être déployés en OTA
Tout d'abord, classez chaque modification prévue dans la couche web ou la couche native. Ce choix vous dira si une release OTA est adaptée ou s'il vous faut un nouveau build de l'app.
Dans une application Capacitor, la couche web contient le HTML, le CSS, le JavaScript et les assets affichés dans la WebView. Les mises à jour OTA peuvent remplacer ce bundle. Un correctif de bug JS, un changement de mise en page ou une correction de texte peut passer par cette voie, tant que la modification reste dans le cadre de la finalité actuelle de votre app.
La couche native est différente. Elle inclut le code compilé pour iOS ou Android, les réglages natifs, les permissions et les plugins qui se connectent aux fonctionnalités de l'appareil. Ajouter un plugin ou modifier une permission nécessite un nouveau build natif et le processus de publication habituel sur les stores. Ne tentez pas de contourner cette limite avec un bundle web.
Avant de déployer, créez une petite checklist de release. Notez les fichiers modifiés, les versions installées de l'app qui peuvent exécuter le bundle, et si la mise à jour dépend d'un plugin natif déjà présent dans ces builds. Si le bundle appelle un plugin absent de l'app installée, les utilisateurs risquent de tomber sur une fonctionnalité cassée ou une erreur.
Les règles des stores imposent également des limites sur ce qu'un live update peut modifier. Pour examiner ces limites de plus près, consultez ce guide des mises à jour OTA conformes aux stores dans le cadre de votre revue de release.
L'OTA a un sens plus large dans d'autres domaines. Une voiture connectée peut recevoir un firmware pour une unité de contrôl’électronique via une connexion cloud, le Wi-Fi ou le réseau cellulaire. Un petit appareil peut recevoir un firmware via Wi-Fi ou Bluetooth Low Energy. Ces releases peuvent impliquer des bootloaders, des limites de stockage, des vérifications d'alimentation et une image de récupération. Un bundle web Capacitor n'est pas la même chose qu'un firmware embarqué, et son plan de déploiement doit correspondre à la couche applicative que vous modifiez.
À retenir : Utilisez live update pour les changements éligibles sur la couche web. Compilez et soumettez une nouvelle application native lorsque le changement touche le code compilé, les plugins ou les permissions.
Étape 2 : configurez les canaux QA, bêta et production
Un canal est un chemin nommé qui indique à l'application installée quel bundle elle peut recevoir. Configurez des canaux distincts avant votre première release en production, afin qu'un build QA ne puisse pas recevoir accidentellement un bundle de production.
Commencez par une répartition simple. Utilisez un canal QA pour les vérifications internes, un canal bêta pour un groupe de test limité, et un canal de production pour l'ensemble des utilisateurs. Gardez l'objectif de chaque canal explicite dans les notes de release et les paramètres de déploiement de votre équipe.
Ensuite, assignez les bons builds d'application aux bons canaux. L'application installée doit être configurée pour écouter le canal prévu. Vérifiez cela sur des appareils de test avant d'envoyer un bundle. Si votre build QA écoute la production, une release de production pourrait atteindre les testeurs avant que vos vérifications ne soient terminées.
Associez chaque canal à une étape de revue précise. Par exemple, la QA peut confirmer que les écrans clés se chargent et que le flux de connexion fonctionne toujours. Les bêta-testeurs peuvent vérifier le changement dans un usage plus large de l'app. Ce n'est qu'ensuite que vous devez envoyer la release en production.
Capgo prend en charge les releases par canal pour la QA, la bêta et la production. Ses contrôles de déploiement permettent d'envoyer un nouveau bundle à une partie des appareils pendant que les autres utilisateurs restent sur une version stable. Si vous définissez des groupes d'audience et des étapes de validation, ce guide de déploiement par canal peut vous aider à structurer votre workflow.
Choisissez une petite cohorte initiale que votre équipe peut observer. Convenez de ce qui stopperait le déploiement avant de publier, comme une hausse des échecs de mise à jour ou un problème de connexion. Une règle d'arrêt claire évite une décision précipitée dès la première alerte.
Étape 3 : Connectez votre logiciel de mise à jour OTA au CI/CD et déployez
Le CI/CD relie les changements de code à des tâches de build et de release reproductibles. Configurez-le pour que le même bundle testé soit compilé, vérifié et envoyé vers le canal prévu.
Commencez par choisir l'événement qui doit déclencher un déploiement OTA. Une équipe peut utiliser un merge vers une branche de release, un tag de version ou une approbation manuelle dans le pipeline. Choisissez un déclencheur qui correspond à votre processus de revue. Ne laissez pas chaque changement sur une branche de dev être publié en production.
Ajoutez ensuite les credentials nécessaires à votre store de secrets CI/CD. Gardez les clés de déploiement hors des fichiers sources et des logs de build. Limitez l'accès aux personnes et aux jobs qui en ont besoin, et faites tourner les credentials s'ils sont exposés.
Configurez le pipeline pour compiler les assets web avant d'uploader un bundle. Ajoutez des contrôles qui détectent les builds échoués et les dépendances natives incompatibles. Si votre release nécessite un plugin natif absent de l'application installée, arrêtez le job OTA et préparez plutôt un build natif.
Avec Capgo, CLI prend en charge un déploiement en une seule commande. Compilez les assets web de votre application, puis lancez la commande de déploiement configurée depuis un terminal local ou un job CI/CD. Définissez le canal cible avec précision et conservez la commande et ses options dans votre gestion de versions, pour qu'un membre de l'équipe puisse vérifier le chemin de release.
Effectuez le premier déploiement sur l'environnement QA. Ouvrez l'app sur un appareil de test et confirmez qu'elle vérifie la présence du bundle, le télécharge et affiche le changement prévu après l'application de la mise à jour. Enregistrez la version du bundle et le canal dans votre fiche de release. Ce détail aide l'équipe à rattacher un rapport au rollout exact.
Si vous comparez des schémas de configuration avant de brancher votre pipeline, ce Guide de configuration SaaS pour les mises à jour OTA couvre les canaux, la planification du rollback, l'analyse et le CI/CD comme éléments d'un workflow de release unique.
Conseil de pro : Exigez une étape d'approbation pour le déploiement en production. La même automatisation peut compiler et envoyer une release, tandis qu'une personne confirme encore le canal cible et le plan de déploiement.
Une fois la QA validée, faites progresser la release à travers les étapes prévues. Gardez le bundle testé inchangé entre les étapes, afin que les utilisateurs en production reçoivent le même artefact que celui approuvé par votre équipe.
Étape 4 : Protégez vos releases avec rollback et contrôles de sécurité
Un plan de release nécessite une procédure de récupération avant que le premier utilisateur ne reçoive le bundle. Déterminez qui peut mettre un déploiement progressif en pause, comment l'équipe restaurera une version stable et quels signaux sont considérés comme une erreur.
D'abord, vérifiez l'intégrité du bundle. La signature Code permet à une application de vérifier qu'une mise à jour provient d'une source fiable et n'a pas été modifiée durant le transfert. Conservez la clé de signature dans un gestionnaire de secrets restreint. L'application doit vérifier la mise à jour avant de l'activer.
Vérifiez également le bundle par rapport à l'application native qui l'exécutera. Une mise à jour web peut échouer si elle appelle des code natifs que le shell installé ne contient pas. Examinez les changements de plugins et de dépendances natives avant l'upload, puis testez le bundle sur la version d'application la plus ancienne que vous prévoyez de supporter.
Définissez une règle de rollback avant le déploiement. Un plan simple identifie le bundle stable, la personne autorisée à mettre le déploiement progressif en pause et les étapes pour restaurer la version précédente. Capgo maintient les appareils hors d'un déploiement progressif sur une version de secours stable et met automatiquement le déploiement en pause lorsque le taux d'erreur dépasse un seuil défini, avec un échantillon minimum. Cette pause peut limiter l'exposition pendant que l'équipe analyse l'erreur.
L'auto-pause et le rollback sont deux actions différentes. Une pause empêche d'autres appareils de recevoir la nouvelle release ; le rollback renvoie les appareils affectés vers un bundle fonctionnel. Sachez quel contrôle votre workflow utilise et testez la procédure de récupération avant qu'un incident ne survienne en production.
Pour les systèmes de mise à jour sensibles, la signature et le chiffrement répondent à des risques différents. Une signature permet de vérifier qui a publié le bundle et s'il a été modifié. Le chiffrement protège le contenu du bundle pendant son transfert ou son stockage. Utilisez HTTPS pour la distribution, protégez vos clés de signature et ne considérez pas le chiffrement comme un substitut aux vérifications au niveau de l'application.
Lorsqu'une mise à jour peut affecter un système critique pour la sécurité, comme le firmware d'un véhicule, les équipes doivent prévoir une validation distincte et un plan de secours. Anticipez les coupures de courant, la faible connectivité et le stockage limité avant l'activation. Une release web Capacitor ne remplace pas les tests de sécurité du firmware ni les processus de conformité propres aux systèmes embarqués.
Étape 5 : Suivez l'adoption et améliorez le prochain déploiement progressif
Un déploiement n'est pas terminé dès que l'upload réussit. Vérifiez ce qui se passe sur les appareils, puis utilisez ces résultats pour décider s'il faut continuer, mettre en pause ou restaurer le bundle précédent.
Suivez la release par version et par canal. Surveillez les téléchargements, les installations, les échecs, l'adoption et le taux de réussite. Analysez l'appareil et la version de l'app en cas d'échec. Un nombre élevé d'installations ne prouve pas à lui seul que le nouveau bundle a démarré correctement.
La vue Observe de Capgo suit les installations, les tentatives échouées, l'adoption et le taux de réussite pour une version et un canal donnés, par tranches de cinq minutes. Elle peut aussi signaler un canal qui sert un bundle dont les packages natifs diffèrent du build de l'app installée, puis identifier les packages bloquants et afficher un diff de dépendances.
Appliquez ces signaux avec une règle de décision claire. Si le taux d'échec reste dans la plage convenue, faites passer le déploiement au groupe suivant. S'il dépasse votre seuil, mettez-l’en pause et inspectez la version et le canal concernés. N'élargissez pas le déploiement tant que la cause reste floue.
Rédigez une note de release courte avec le changement, le public cible, la cohorte de départ et le résultat. Ajoutez le problème principal et l'action menée si le déploiement a été mis en pause. La passation d'astreinte n'en sera que plus simple, surtout si le support signale un problème après la validation du responsable de la release.
Les analytics aident aussi à mesurer le coût d'un déploiement à l'aveugle. Sans signaux d'adoption et d'échec, vous savez peut-être qu'un bundle a été uploadé, mais pas si les utilisateurs l'ont reçu ni s'il s'est lancé correctement. Pour plus de détails sur les signaux de release, consultez le guide d'analytics des mises à jour d'app en temps réel.
Après le déploiement, passez le résultat en revue avec les équipes d'ingénierie et de support. Notez si la taille de la cohorte était pertinente, si la règle d'arrêt a bien détecté les problèmes et si les étapes de récupération étaient claires. Ne changez qu'un élément du processus à la fois. La prochaine release sera plus facile à évaluer.
À retenir : Suivez chaque release par version de bundle et par canal, puis utilisez le seuil d'échec défini pour mettre en pause ou continuer.
FAQ
Que peut mettre à jour une application Capacitor en OTA ?
Une application Capacitor peut mettre à jour ses fichiers de la couche web à distance, incluant le HTML, le CSS, le JavaScript et les assets. Le shell natif reste inchangé. Si un changement ajoute un plugin, modifie une permission ou altère le code compilé pour iOS ou Android, préparez un nouveau build natif et soumettez-le via le processus habituel des stores.
Do OTA updates need app store review?
Les mises à jour éligibles de la couche web peuvent atteindre les utilisateurs sans nouvelle soumission sur les stores, tant qu'elles respectent les règles des stores et restent dans le périmètre approuvé de l'application. Les changements de code natif et de permissions nécessitent un nouveau binaire. Une mise à jour OTA doit rester conforme à l'usage de l'application.
Comment tester une release OTA avant la production ?
Envoyez d'abord le bundle vers un canal QA. Testez-le sur les versions de l'app que vous prévoyez de supporter, puis confirmez que les écrans clés et les appels de plugins natifs fonctionnent toujours. Déployez ce même bundle testé vers la bêta si vous utilisez un groupe de test plus large. Lancez la production avec une cohorte limitée et un seuil de pause défini.
Capgo supporte-t-il le déploiement progressif et le monitoring ?
Oui. Capgo permet de servir un bundle à un pourcentage d'appareils pendant que les autres restent sur une version stable de secours. Sa vue Observe suit les installations, les échecs, l'adoption et le taux de réussite par version et par canal par tranches de cinq minutes. Capgo met également en pause automatiquement un déploiement progressif lorsque son taux d'échec dépasse un seuil défini.
Conclusion
Limitez les releases OTA aux changements compatibles de la couche web, passez-les par des canaux QA et production, et définissez une règle de récupération avant le déploiement progressif. Capgo peut regrouper le déploiement du bundle et les signaux de release dans un seul workflow. Commencez votre essai gratuit de 14 jours, puis envoyez un bundle de test en QA avant de vous connecter à la production.
