Calabash Xamarin. UITest Microsoft a investi très tôt dans le domaine des apps mobiles, en proposant une des premières solutions de développement multi-plateformes : Xamarin, puis son propre OS mobile qui a désormais disparu. Avec l'avènement du cloud et des solutions Saa S de build, ils proposent désormais une solution complète d'intégration/déploiement continu qui présente de nombreux avantages pour les développeurs d'applications mobiles. Azure Pipelines Mise en place La solution Azure Pipelines présente de nombreuses similarités avec des solutions concurrentes comme Gitlab CI ou Github Actions. Le paramétrage s'effectue via un fichier YAML déposé à la racine de votre dépôt :.azure_pipelines.yml. Runners Une des forces de la solution de pipelines d'Azure est la mise à disposition de machines hebergées dans le cloud pour exécuter les builds, et en particulier des machines tournant sous mac OS , indispensables pour les applications i OS ou cross-platform. De nombreuses stacks sont disponibles, et les dernières versions des SDK mobiles et des OS sont rapidement proposées, il existe même des runners tournant sur les Bêta de ces outils. Les Différents Types De Machines Disponibles Sont Image Spécification de l’agent d’éditeur classique Étiquette d’image de machine virtuelle YAML Windows Server 2022 avec Visual Studio 2022 windows-2022 windows-latest OU windows-2022 Windows Server 2019 avec Visual Studio 2019 windows-2019 windows-2019 Ubuntu 20.04 ubuntu-20.04 ubuntu-latest OU ubuntu-20.04 Ubuntu 18.04 ubuntu-18.04 ubuntu-18.04 mac OS 11 Big Sur mac OS-11 mac OS-latest OU mac OS-11 mac OS X Catalina 10.15 mac OS-10.15 mac OS-10.15 Ceux qui nous intéressent dans le cadre d'une CI mobile sont macos-latest et éventuellement ubuntu-latest pour des builds Android, le plus simple étant de faire tourner tous les builds sur macos-latest, capable de compiler à la fois des apps Android et i OS. Ces machines virtuelles tournent sur des Mac Pro, disposent d'un v CPU de 3 coeurs de 14 Go de RAM, 14 Go de stockage et sont hébergées aux états-unis, quelle que soit la région choisie pour le projet Azure. Etapes pré-définies Plusieurs actions sont complètement automatisées et maintenues par les équipes de Microsoft : par exemple, la compilation d'une target spécifique d'un projet i OS ou d'une flavor Android, l'installation de certificats de build, la récupération de dépendances via les outils classiques (Gradle, Cocoapods, SPM...), l'envoi du code dans un outil de qualimétrie comme Sonar, ou l'envoi sur les plateformes des stores (App Store et Google Play Store).



Ces actions ne nécessitent aucun développement pour être utilisées : il suffit simplement de renseigner les paramètres nécessaires à leur fonctionnement. Une interface graphique est même disponible pour aider à la création des différentes étapes qui constituent vos scripts d'intégration continue. Ci-dessus une partie des différents scripts de base proposés par Azure Devops, avec ceux adaptés au mobile encadrés en rouge. Variables & Secure files Lors de l'exécution, votre chaîne de CI aura besoin de fournir des paramètres tels que des clés d'API, des jetons de Webhooks, des clés de signature, des certificats etc... Ces paramètres peuvent varier en fonction de l'environnement souhaité au moment du build (intégration, QA, UAT, pré-production, production etc...). Azure propose un système de gestion de ces paramètres via les Variables et les Secure Files. Les variables sont définies dans des Variable Groups, qui peuvent être dupliqués environnement par environnement, comme suit : A L'intérieur De Chaque Variable Group, Chaque Variable Est Définie Dans Un Système De Clés/valeurs Qui Est Ensuite Accessible Aux Scripts Du Pipeline Via Des Variables D'environnement Déclenchements Les actions de build peuvent bien évidemment être déclenchées manuellement, mais l'intérêt d'une integration continue est d'automatiser leur exécution. Plusieurs types de triggers existent : sur certaines branches (par exemple, après un merge sur develop, ou à chaque push sur les branches de recette release/), ou à horaire fixe (pour produire des builds de type nightly builds), via une syntaxe CRON. Pricing Azure Dev Ops Pipelines est un service payant en fonction du nombre de builds concurrents dont on a besoin. Le free-tier comprend un seul build en simultané. Pour plus de builds en parallèle, il faut débourser 40 $ par mois par build concurrent sur des runners hébergés par Microsoft, ou à 15 $ par mois si vous gérez vos propres runners on-premise. Concernant les artefacts des builds, ils sont facturés 2 $ par mois et par Go de stockage au delà des premiers 2 Go. A cette gestion de pipelines s'ajoute un environnement complet comprenant un outil d'issue-tracking, de documentation, des dépôts Git pour le code.



L'ensemble de ces outils permet de s'affranchir des solutions concurrentes telles que Jira, Confluence et Bitbucket d'Atlassian, ou Git Lab par exemple. Le détail du pricing est disponible à l'adresse suivante : Azure App Center En complément d'Azure Pipelines , Azure propose une solution dédiée aux développeurs d'applications mobiles qui permet d'héberger des builds de recette, de les partager aux équipes de QA et de réaliser des tests automatisés : Azure App Center . Cet outil permet de créer différentes apps : sur l'exemple ci-dessous, il y a 6 apps, 3 pour i OS, 3 pour Android, sur 3 environnements : recette, pré-production et production : Builds de test et QA App Center s'intègre très facilement à Azure Pipelines, en fin de build, il suffit d'ajouter une étape d'upload, de fournir un token d'API et le tour est joué. App Center permet de définir des groupes de testeurs qui peuvent être invités automatiquement à chaque build et reçoivent un mail ainsi qu'un accès à une interface qui leur permet de télécharger les derniers builds issus de la CI. Tests automatisés Azure dispose d'une ferme de devices permettant de réaliser des tests automatisés de non-regression. De nombreux types de devices sont disponibles, sur plusieurs versions d'OS, et du matériel plus ou moins récent permettant de tester vos applications en conditions réelles sans pour autant devoir maintenir un parc de devices physiques important chez vous. Plusieurs ensembles de devices peuvent être créés, plus ou moins limités : par exemple, un parc de quelques devices suffit pour valider la non-régression à chaque merge request, mais en cas de déploiement d'une release-candidate, un parc plus large (et donc plus coûteux et plus long en temps d'exécution) permettra de détecter les derniers bugs avant une mise en production. Les tests sont compatibles avec la plupart des solutions existantes sur le marché : Appium (Java avec JUnit) Calabash Expresso (Android uniquement) Xamarin. UITest XCUITest (i OS uniquement) Conclusion Les outils Azure Devops permettent de très facilement mettre en place une CI mobile. Le free-tier, bien que limité, notamment en temps d'exécution sur un seul build en simultané, est suffisant pour des petits projets, et sur des projets plus conséquents, le coût des runners hébergés comparé à une solution on-premise qui nécessite de la maintenance et un investissement initial en matériel est très vite rentabilisé. Désormais, plus aucune excuse pour ne pas déclencher une batterie de tests avant chaque release, ou pour produire des builds de production sur les postes de vos développeurs ! #J-18808-Ljbffr

📌 Supercharge your mobile ci with azure devops (Ejidal)
🏢 Niji Tech
📍 Ejidal