CI/CD et automatisation dans le développement mobile : qu'est-ce que c'est, comment ça marche et pourquoi c'est nécessaire

Qu'est-ce que le CI/CD ?

Continuous Integration

Continuous Integration est le fondement de l'automatisation CI/CD pour les applications mobiles. C'est une pratique où chaque développeur fusionne son code dans un dépôt partagé plusieurs fois par jour. Après chaque push, le serveur CI build automatiquement le projet et exécute les tests. Si les tests échouent, le build est considéré comme cassé et l'équipe corrige le problème immédiatement. Le CI empêche la situation « ça marche sur ma machine » où le code d'un développeur casse celui d'un autre.

Build Pipeline — une séquence d'étapes exécutées à chaque push : linting du code → tests unitaires → build debug APK/IPA → tests d'intégration → build release. Chaque étape s'exécute uniquement après la réussite de la précédente. Les artefacts de build — APK, IPA, AAB, rapports de test — sont sauvegardés et disponibles au téléchargement.

Continuous Delivery vs Continuous Deployment

Continuous Delivery — le code est automatiquement buildé et testé, mais un humain décide de la mise en production. Continuous Deployment — chaque build réussi est automatiquement mis en production. Pour les applications mobiles, le CD (livraison aux stores) via TestFlight ou Internal Testing est plus courant, car la décision finale de publication est prise par le développeur ou le manager. Staging — environnement aussi proche que possible de la production, utilisé pour tester le build avant la release.

GitHub Actions et GitLab CI

GitHub Actions

GitHub Actions est un système CI/CD intégré pour automatiser les applications mobiles sur GitHub. Actions utilise la configuration YAML (.github/workflows) pour définir les pipelines. Des actions prêtes à l'emploi sont disponibles pour le développement mobile : actions/setup-java, gradle-build-action pour Android, xcodebuild-action pour iOS. GitHub Actions offre 2000 minutes gratuites par mois pour les dépôts privés.

Exemple : un workflow Android inclut le checkout du code, la configuration JDK 17, la mise en cache des dépendances Gradle, l'exécution du lint et des tests unitaires, le build APK et le téléchargement des artefacts. Pour iOS — checkout, configuration Xcode, pod install, exécution XCTest, archivage et export IPA. GitHub Actions s'intègre avec GitHub Releases, Slack et Telegram pour les notifications.

GitLab CI

GitLab CI est un système CI/CD intégré dans GitLab, configuré via .gitlab-ci.yml. GitLab CI utilise des runners — des agents qui exécutent les jobs. Pour le développement mobile, vous pouvez utiliser des runners partagés (Linux pour Android) ou vos propres runners (macOS pour iOS). GitLab CI prend en charge les jobs parallèles, les artefacts, les environnements et l'approbation manuelle pour les releases de production.

Bitrise pour les applications mobiles

Pourquoi Bitrise ?

Bitrise est une plateforme CI/CD spécialisée dans l'automatisation des applications mobiles. Bitrise propose des Steps prêts à l'emploi pour Android, iOS, Flutter et React Native : Gradle Runner, Xcode Archive, Flutter Test, CocoaPods Install. Bitrise configure automatiquement la signature de code pour iOS (via Codesigndoc) et fournit des machines virtuelles avec Xcode, Android SDK, Flutter et d'autres outils préinstallés.

Avantages de Bitrise : configuration simple via l'éditeur visuel de Workflow, prise en charge des builds parallèles, intégration avec Firebase Test Lab, App Store Connect et Google Play Console. Bitrise offre 90 minutes gratuites par mois pour les projets personnels. Chez IT Sectr, nous utilisons Bitrise pour tous les projets mobiles — il simplifie considérablement le CI/CD par rapport à la configuration manuelle de GitHub Actions.

Fastlane : automatisation des builds mobiles

Qu'est-ce que Fastlane ?

Fastlane est un outil d'automatisation d'applications mobiles pour iOS et Android, écrit en Ruby. Fastlane se compose d'un système d'actions prêtes à l'emploi (plus de 200) et d'un DSL pour décrire des scénarios via Fastfile. Fastlane résout les tâches que chaque développeur mobile effectue manuellement : signature de code, génération de captures d'écran, téléchargement vers TestFlight et Google Play, gestion des certificats et des profils de provisionnement.

Composants clés de Fastlane

Lane — un scénario nommé dans Fastfile. Exemple : lane :release do — une chaîne d'actions pour publier une version. Match — un outil pour stocker et synchroniser en toute sécurité les certificats et les profils de provisionnement via un dépôt Git crypté. Gym — build et archivage d'applications iOS (un wrapper autour de xcodebuild). Pilot — téléchargement et gestion des builds dans TestFlight. Deliver — téléchargement de l'application et des métadonnées dans App Store Connect. Snapshot — génération automatique de captures d'écran dans toutes les langues. Screengrab — génération automatique de captures d'écran pour Android.

Exemple de Fastfile pour Android : lane :beta appelle gradle (assembleRelease), puis firebase_app_distribution pour la distribution aux testeurs. Pour iOS : lane :beta appelle match (téléchargement des certificats), gym (archivage) et pilot (téléchargement dans TestFlight). Fastlane peut s'exécuter localement et sur un serveur CI — ce qui en fait un outil universel dans tout projet mobile.

Canary Release et Feature Flags

Canary Release

Canary Release est une stratégie d'automatisation CI/CD pour déployer une nouvelle version de l'application auprès d'un petit pourcentage d'utilisateurs (1–5%) avant la sortie complète. Dans Google Play Console, cela est implémenté via Staged Rollout : vous publiez une mise à jour auprès de 5% de votre audience, surveillez les crashes et les métriques, et augmentez le pourcentage si aucun problème n'est détecté. Dans App Store Connect — via Phased Release for Automatic Updates.

A/B Testing — comparaison de deux versions d'une fonctionnalité sur des groupes d'utilisateurs aléatoires. Dans le développement mobile, les tests A/B sont effectués via Feature Flags, Firebase Remote Config ou la logique serveur. Canary Release et les tests A/B minimisent les risques lors du déploiement de nouvelles fonctionnalités.

Feature Flags

Feature Flag (Feature Toggle) — activation conditionnelle d'une fonctionnalité sans déploiement de nouveau code. Un Feature Flag est une vérification dans le code : if (featureFlag.isEnabled()) { /* nouveau code */ } else { /* ancien code */ }. Les flags sont gérés via des services : LaunchDarkly, Split.io, Firebase Remote Config. Les Feature Flags permettent aux développeurs de fusionner le code dans main même si la fonctionnalité n'est pas encore prête pour les utilisateurs.

LaunchDarkly — la plateforme de gestion de Feature Flags la plus populaire. LaunchDarkly fournit des SDK pour iOS, Android, Flutter et React Native. Vous pouvez activer des fonctionnalités pour des utilisateurs, segments, régions spécifiques ou un pourcentage de l'audience. Les Feature Flags sont également utilisés comme kill switch — désactivation instantanée d'une fonctionnalité problématique sans publier une nouvelle version de l'application.