Applications mobiles et Déploiement continu
Fastlane & GitHub Actions
Ecrit par Gaëlle
Dans le monde du développement, l’un des enjeux principaux est une livraison rapide et sans accroc du travail des développeurs. Du côté des applications mobiles, cette complexité se trouve multipliée par le nombre de plateformes supportées (iOS, Android, Web) et par les technologies utilisées (natif, React-Native, Flutter…).
Effectuer des livraisons de manière simplifiée, uniforme sur tous nos projets et sans forcément mobiliser un développeur ou un poste sous Mac sont quelques-uns des objectifs que nous nous sommes fixés chez Eurelis. Pour y répondre, nous avons mis en place un processus de déploiement continu, en utilisant Fastlane et GitHub Actions, ce qui nous permet de confier toute la partie compilation des applications à des services externes.
Qu’est-ce que le déploiement continu ?
Il s’agit d’une pratique permettant aux modifications du code d’être automatiquement déployées vers un environnement de test ou de production. Son objectif est de livrer de manière rapide et fiable de nouvelles fonctionnalités ou des correctifs aux utilisateurs.
Au-delà d’une livraison automatique et rapide, le déploiement continu permet également de diminuer les risques de bugs liés à un environnement local ou les erreurs humaines, ainsi que d’assurer une qualité de code correcte au fur et à mesure des modifications.
Fastlane
Fastlane est un outil open source permettant de simplifier le déploiement Android et iOS. Il permet d’automatiser chaque aspect de la compilation jusqu’à la livraison : génération de captures d’écrans, déploiement de versions de test, signature et publication sur les stores.
Chez Eurelis, nous utilisons Fastlane depuis des années, grâce à cet outil, nos techniques de livraisons étaient déjà simplifiées. En une ligne de commande, nous pouvons:
- vérifier et mettre à jour les numéros de version des applications
- effectuer la compilation Android et / ou iOS
- signer les applications avec des clés de développement ou de production
- publier sur les stores ou sur notre plateforme de tests
De plus, grâce à une configuration permettant de mettre en place plusieurs environnements de déploiement, nous pouvons faire la différence entre une version vouée à être testée en interne et une version devant être publiée. Ainsi nos applications de test disposent d’un numéro de version et/ou d’un nom spécifique, ce qui mène à une meilleure communication dans l’équipe et un bon suivi des évolutions.
Cet outil est donc extrêmement efficace et utilisé systématiquement sur tous nos projets mobiles, mais à lui seul reste limité car il doit être utilisé dans un environnement local pré-configuré. Nous devons donc l’utiliser sur nos machines de développement, ce qui reste parfois bloquant car peut prendre du temps et des ressource
GitHub Actions
GitHub Actions est une fonctionnalité intégrée à GitHub permettant de créer des workflows pour automatiser et simplifier les processus de déploiement logiciels. Intégré complètement aux dépôts GitHub de nos projets, nous pouvons grâce à cela créer des déclencheurs au moment où nous le désirons (merges, push, pull requests…), ou bien préférer conserver un déclenchement manuel en définissant les variables utiles lors du lancement.
L’outil dispose d’un marketplace permettant de trouver des workflows génériques pour gérer nos besoins spécifiques (installation de java, de node js, gestion de tags sur git….).
Étant intégrés à des dépôts privés, les workflows ont accès à un système de “secrets” pouvant être défini par projet et contenant les variables privées permettant de gérer les compilations et les signatures (comme le contenu des clés de signature ou les divers token de connexion pour permettre de publier les applications).
Les workflows ont accès à des serveurs privés ou génériques, sous Linux, Windows ou MacOS, ce qui permet les builds iOS autant qu’Android. L’activation manuelle permet également de laisser la main à des acteurs non développeurs à ces Actions, n’importe qui ayant ces droits sur le projet GitHub pouvant donc lancer un déploiement.
Fastlane + GA pour gérer le déploiement continu
Comme nous l’avons vu dans les paragraphes précédents, Fastlane permet une automatisation de tâches locale, tandis que GitHub Actions permet de gérer des déclencheurs liés directement au dépôt GitHub du projet ainsi qu’un accès aux variables secrètes. Il semble alors idéal de lier les deux pour effectuer un déploiement continu.
Pourquoi utiliser ces deux outils ?
Tous nos projets mobiles sont déjà configurés pour utiliser fastlane et hébergés sur GitHub, il suffit donc de lier les deux configurations pour déclencher les scripts fastlane dans les workflow GitHub.
La mise en place est donc simplifiée et permet de standardiser cette installation sur nos projets afin de conserver un fonctionnement unique et d’améliorer la maintenance de ce système sur le long terme.
Côté développeur
Pour mettre en place tout cela, il faut intégrer des fichiers YAML à la racine du projet. Chaque fichier YAML définit un type de déclencheur (la branche principale, détection des push, de merge requests…) et les actions qui seront effectuées lors de son activation.
Il s’agit alors, lors de chaque activation, de mettre en place l’environnement de build, indiquant quels outils installer : le runner (serveur utilisé par GitHub Actions) sera reset à chaque lancement, il faut donc détailler chaque outil à configurer dans le workflow.
Une fois l’environnement prêt, nous pouvons appeler les mêmes scripts fastlane que nous utilisons en local afin d’effectuer les changements de version, les builds, signatures et publications des fichiers finaux (sur le PlayStore, TestFlight ou toute autre plateforme d’hébergement d’applications)
Comme précédemment, nous pouvons définir des workflows différents selon l’environnement afin de pouvoir accéder à des builds de test ou de production.
Côté interface GitHub
Côté GitHub, l’accès se fait directement depuis le dépôt du projet, dans la partie Actions. Nous pouvons y retrouver la liste des workflows (fichiers .yml comme vu plus tôt) détectés par GitHub Actions ainsi que l’historique de leur activation. Cela permettra notamment de détecter les erreurs de compilation et d’intervenir.
Cet accès n’étant pas limité aux développeurs, n’importe quel acteur du projet peut alors avoir la vision sur ces activations, ou, si l’activation manuelle est activée, déployer manuellement les publications lorsqu’il le souhaite.
Conclusion
La mise en place d’un processus automatique pour compiler et publier des applications est un sujet au goût du jour, les problématiques sont nombreuses et l’utilisation de fastlane puis de GitHub Actions nous a permis de nous en affranchir en offrant des avantages considérables en termes de rapidité, de qualité et d’efficacité.
En automatisant les builds et les déploiements, les possibilités d’erreurs humaines sont diminuées et les limites d’un environnement local disparaissent. De plus, la complexité d’installation de ces outils est plutôt faible, étant donné qu’une configuration peut très facilement (en un copier coller, ou presque) être transférée d’un projet à un autre. Ceci le rend extrêmement valable dans un workflow complet de développement : le temps passé à le configurer en début de projet sera récupéré dès la première livraison.
Le plus long sera probablement la prise en main de fastlane et la configuration native des projets afin de les uniformiser et les rendre compatibles avec une installation unique, mais une fois tout cela assimilé, nous ne voyons à l’heure actuelle que du bonus dans ce processus et ces outils, qui ont transformé la manière dont nous développons et déployons vos applications mobiles.
Sources:
