Ce qui change quand on livre une application mobile

Si vous avez passé des années à livrer des applications web, le déploiement mobile donne l'impression d'entrer dans un autre monde. Avec une application web, vous construisez, vous uploadez sur un serveur, et c'est terminé. Les utilisateurs actualisent leur navigateur et voient la dernière version. Vous contrôlez tout : le serveur, l'infrastructure, le moment de la mise en production.

Les applications mobiles ne fonctionnent pas comme ça. Et les différences sont suffisamment profondes pour que l'ensemble de votre pipeline CI/CD doive changer.

L'application vit sur l'appareil de quelqu'un d'autre

La première différence, la plus fondamentale, est l'endroit où l'application s'exécute réellement. Une application mobile ne vit pas sur un serveur que vous gérez. Elle vit sur un appareil dans la poche de quelqu'un. Vous ne pouvez pas échanger des fichiers sur un serveur. Vous ne pouvez pas pousser un correctif à chaud et le voir prendre effet immédiatement.

Chaque fois que vous voulez livrer une nouvelle version, vous devez reconstruire l'application, la signer numériquement et la soumettre à un magasin d'applications. Ensuite, l'utilisateur doit télécharger et installer la mise à jour lui-même. Certains utilisateurs mettront à jour immédiatement. D'autres ignoreront la notification pendant des semaines. Quelques-uns ne mettront jamais à jour.

Cela change votre façon de penser la livraison. Vous ne pouvez pas supposer que tout le monde est sur la dernière version. Vous ne pouvez pas corriger un bug critique et le faire parvenir à tous les utilisateurs en quelques minutes. Le contrôle que vous aviez avec la livraison web a disparu.

Deux plateformes, deux systèmes de build

La livraison mobile implique de gérer plusieurs systèmes de build. Android utilise Gradle. iOS utilise Xcode. Chacun a ses propres règles concernant les versions du SDK, les dépendances et les formats de sortie. Vous ne pouvez pas construire une application Android sur macOS et la livrer à des utilisateurs iOS, ou l'inverse.

Votre pipeline doit gérer deux chemins de build distincts. Ils peuvent s'exécuter en parallèle ou séquentiellement, selon votre configuration, mais ils ne sont jamais identiques. La configuration de build pour Android se trouve dans les fichiers Gradle. La configuration de build pour iOS se trouve dans les fichiers de projet Xcode et les schémas. Les dépendances sont gérées différemment. Le processus de signature est complètement différent.

Si vous supportez les deux plateformes, votre pipeline CI/CD devient effectivement deux pipelines qui partagent une partie de la logique de test et de notification, mais divergent à l'étape de build.

La signature n'est pas optionnelle

Avant qu'une application mobile puisse être installée sur l'appareil d'un utilisateur, elle doit être signée numériquement. Cette signature prouve que l'application vient de vous, et non de quelqu'un qui se fait passer pour vous. Android utilise un fichier keystore. iOS utilise des certificats et des profils de provisionnement.

Ce sont des fichiers secrets. S'ils fuient, quelqu'un d'autre peut publier des applications qui ressemblent aux vôtres. Si vous les perdez, vous ne pourrez plus jamais livrer de mise à jour à votre application existante sur le Play Store ou l'App Store. Il n'y a pas de récupération possible. Vous devriez créer une nouvelle fiche d'application et perdre tous vos utilisateurs existants.

Dans votre pipeline, ces fichiers doivent être stockés de manière sécurisée. Ne les codez jamais en dur dans votre dépôt. Ne les commitez jamais dans le contrôle de version. Utilisez un gestionnaire de secrets, un stockage chiffré dans votre système CI, ou un service de signature dédié. Le pipeline ne doit accéder à ces fichiers que pendant l'étape de signature, et nulle part ailleurs.

Le magasin contrôle le moment de votre mise en production

Vous ne pouvez pas simplement envoyer un fichier APK ou IPA aux utilisateurs. L'application doit passer par un magasin d'applications. Le Google Play Store et l'Apple App Store ont tous deux des processus de révision. Google Play examine généralement en quelques heures. La révision d'Apple peut prendre plus de temps et est souvent plus stricte.

Cela signifie que le temps entre la fin de votre build et le moment où les utilisateurs commencent à utiliser la nouvelle version n'est pas sous votre contrôle. Un tiers décide quand votre application est mise en ligne. S'ils rejettent votre soumission, vous devez corriger le problème, reconstruire et soumettre à nouveau. Le compteur se remet à zéro.

Cela affecte également votre stratégie de rollback. Sur le web, revenir en arrière signifie déployer la version précédente. Sur mobile, vous ne pouvez pas forcer les utilisateurs à revenir en arrière. Les utilisateurs qui ont déjà mis à jour resteront sur la version défectueuse jusqu'à ce que vous livriez un correctif. Et ce correctif doit à nouveau passer par la révision.

Les déploiements progressifs deviennent essentiels

Parce que vous ne pouvez pas facilement revenir en arrière, vous devez être prudent sur la façon dont vous publiez. Android et iOS supportent tous deux les déploiements progressifs. Android appelle cela un déploiement par étapes. iOS appelle cela une publication progressive.

L'idée est simple : vous publiez d'abord la nouvelle version à un petit pourcentage d'utilisateurs. Peut-être 1% ou 5%. Vous surveillez les rapports de crash, les taux d'erreur et les retours des utilisateurs. Si tout semble bon, vous élargissez le déploiement à 10%, puis 25%, puis 50%, puis 100%. Si quelque chose tourne mal, vous mettez le déploiement en pause. Seul le petit groupe d'utilisateurs qui a déjà reçu la mise à jour est affecté.

Ce n'est pas optionnel pour une livraison mobile sérieuse. C'est le principal moyen de réduire les risques quand vous ne pouvez pas revenir instantanément en arrière.

Ce que cela signifie pour votre pipeline

Toutes ces différences s'additionnent pour former un pipeline CI/CD qui ressemble très peu à un pipeline web. Votre pipeline mobile doit gérer :

Le diagramme suivant montre les deux chemins côte à côte, en soulignant où le mobile ajoute des étapes supplémentaires.

• Des builds spécifiques à chaque plateforme avec des chaînes d'outils différentes
• Une signature sécurisée avec des secrets qui ne doivent jamais fuiter
• L'upload vers les magasins d'applications avec soumission automatisée
• Des stratégies de déploiement progressif qui peuvent être mises en pause ou étendues

Vous devez aussi repenser les tests. Les émulateurs et simulateurs peuvent détecter de nombreux problèmes, mais ils ne sont pas parfaits. Certains bugs n'apparaissent que sur des appareils réels avec du matériel, des capteurs ou des conditions réseau spécifiques. Votre pipeline doit inclure à la fois des tests automatisés sur des appareils virtuels et un processus de test sur des appareils physiques avant la publication complète.

Une checklist rapide pour le CI/CD mobile

• Stockez les clés de signature et les certificats dans un gestionnaire de secrets sécurisé, pas dans votre dépôt
• Configurez des jobs de build séparés pour Android et iOS avec leurs chaînes d'outils respectives
• Automatisez l'upload vers la Google Play Console et l'App Store Connect
• Implémentez le déploiement progressif ou la publication progressive dans votre pipeline
• Ajoutez un rapport de crash et une surveillance qui déclenchent des alertes pendant le déploiement progressif
• Testez à la fois sur des émulateurs et des appareils réels avant d'étendre le pourcentage de publication

Ce qu'il faut retenir

La livraison mobile n'est pas une livraison web avec une étape de build différente. L'application vit sur des appareils que vous ne contrôlez pas. Le magasin contrôle le moment de votre mise en production. Le rollback n'est pas un bouton que vous pressez. Votre pipeline CI/CD doit tenir compte de ces réalités dès le départ. Construisez pour la plateforme, signez de manière sécurisée, publiez progressivement et surveillez sans relâche. C'est la seule façon de livrer des applications mobiles sans vous réveiller en pleine nuit à cause d'un incident de production que vous ne pouvez pas corriger avant le prochain cycle de révision.