Présentation de l’intégration continue avec Xamarin
L’intégration continue est une pratique d’ingénierie logicielle dans laquelle une build automatisée compile et teste éventuellement une application lorsque du code est ajouté ou modifié par les développeurs dans le référentiel de gestion de versions du projet. Cet article décrit les concepts généraux de l’intégration continue et certaines des options disponibles pour l’intégration continue avec les projets Xamarin.
Il est courant sur les projets logiciels pour les développeurs de travailler en parallèle. À un moment donné, il est nécessaire d’intégrer tous ces flux de travail parallèles dans un code base qui constitue le produit final. Au début du développement de logiciels, cette intégration a été effectuée à la fin d’un projet, ce qui était un processus difficile et risqué.
L’intégration continue (CI) évite de telles complexités en fusionnant en continu les modifications de chaque développeur dans la base de code commune, généralement chaque fois qu’un développeur vérifie les modifications apportées au référentiel de code partagé du projet. Chaque case activée déclenche une build automatisée et exécute des tests automatisés pour vérifier que le code nouvellement introduit n’a pas rompu le code existant. De cette façon, CI détecte immédiatement les erreurs et les problèmes et garantit que tous les membres de l’équipe restent à jour avec le travail des autres. Il en résulte un codebase cohérent et stable.
Les systèmes d’intégration continue ont deux parties main :
- Gestion de version : le contrôle de version (VC), également appelé contrôle de code source ou gestion du code source, consolide tout le code d’un projet dans un référentiel partagé unique et conserve un historique complet de chaque modification apportée à chaque fichier. Ce dépôt, souvent appelé branche principale , contient le code source qui sera finalement utilisé pour générer la version de production ou de mise en production de l’application. Il existe de nombreux produits open source et commerciaux pour cette tâche, qui permettent généralement aux équipes ou aux individus de dupliquer une copie du code dans des branches secondaires où ils peuvent apporter des modifications importantes ou effectuer des expériences sans risque pour la branche main. Une fois les modifications d’une branche secondaire validées, elles peuvent être fusionnées dans la branche main.
- Serveur d’intégration continue : le serveur d’intégration continue est chargé de collecter tous les artefacts d’un projet (code source, images, vidéos, bases de données, tests automatisés, etc.), de compiler l’application et d’exécuter les tests automatisés. Là encore, il existe de nombreux outils de serveur CI open source et commerciaux.
Les développeurs ont généralement une copie de travail d’une ou plusieurs branches sur leurs stations de travail, où le travail est effectué initialement. Une fois qu’un ensemble de travail approprié est terminé, les modifications sont « archivées » ou « validées » dans la branche appropriée, ce qui les propage aux copies de travail d’autres développeurs. C’est ainsi qu’une équipe s’assure qu’elle travaille toutes sur le même code.
Là encore, avec l’intégration continue, le fait de valider les modifications amène le serveur CI à générer le projet et à exécuter des tests automatisés pour vérifier l’exactitude du code source. En cas d’erreurs de build ou d’échecs de test, un serveur CI avertit le développeur responsable (par e-mail, messagerie instantanée, Twitter, Growl, etc.) afin qu’il puisse corriger le problème. (Les serveurs CI peuvent même refuser la validation en cas d’échecs, ce qui est appelé « case activée-in contrôlé ».)
Le diagramme suivant illustre ce processus :
Les applications mobiles présentent des défis uniques pour l’intégration continue. Les applications peuvent nécessiter des capteurs tels que le GPS ou l’appareil photo qui ne sont disponibles que sur les appareils physiques. En outre, les simulateurs ou émulateurs ne sont qu’une approximation du matériel et peuvent masquer ou masquer des problèmes. En fin de compte, il est nécessaire de tester une application mobile sur du matériel réel pour être sûr qu’elle est vraiment prête pour le client.
Le test App Center résout ce problème particulier en testant des applications directement sur des centaines d’appareils physiques. Les développeurs écrivent des tests d’acceptation automatisés, qui permettent des tests d’interface utilisateur puissants. Une fois ces tests chargés dans App Center, le serveur CI peut les exécuter automatiquement dans le cadre d’un processus CI, comme illustré dans le diagramme suivant :
Composants de l’intégration continue
Il existe un vaste écosystème d’outils commerciaux et open source conçus pour prendre en charge l’intégration continue. Cette section décrit quelques-unes des plus courantes.
Gestion de version
Azure DevOps et Team Foundation Server
Azure DevOps et Team Foundation Server (TFS) sont les outils collaboratifs de Microsoft pour les services de génération d’intégration continue, le suivi des tâches, les outils de planification et de création de rapports agiles et le contrôle de version. Avec le contrôle de version, Azure DevOps et TFS peuvent travailler avec leur propre système (Team Foundation Version Control ou TFVC) ou avec des projets hébergés sur GitHub.
- Azure DevOps fournit des services via le cloud. Son principal avantage est qu’il ne nécessite aucun matériel ou infrastructure dédié et est accessible depuis n’importe où via des navigateurs web et des outils de développement populaires tels que Visual Studio, ce qui le rend attrayant pour les équipes qui sont géographiquement distribuées. Il est gratuit pour les équipes de cinq développeurs ou moins, après quoi des licences supplémentaires peuvent être achetées pour accueillir une équipe en pleine croissance.
- TFS est conçu pour les serveurs Windows locaux et accessible via un réseau local ou une connexion VPN à ce réseau. Son principal avantage est que vous contrôlez entièrement la configuration des serveurs de build et que vous pouvez installer tous les logiciels ou services supplémentaires nécessaires. TFS propose une édition Express d’entrée de gamme gratuite pour les petites équipes.
TFS et Azure DevOps sont étroitement intégrés à Visual Studio et permettent aux développeurs d’effectuer de nombreuses tâches de contrôle de version et d’intégration continue dans le confort d’un seul IDE. Le plug-in Team Explorer Everywhere pour Eclipse (voir ci-dessous) est également disponible. Visual Studio pour Mac dispose d’une préversion de TFVC.
Azure DevOps Pipelines prend en charge directement les projets Xamarin, au sein desquels vous créez une définition de build pour chaque plateforme que vous souhaitez cibler (Android, iOS et Windows). La licence Xamarin appropriée est nécessaire pour chaque définition de build. Il est également possible de connecter un serveur de build TFS local compatible Xamarin à Azure DevOps à cet effet. Avec cette configuration, les builds qui sont mises en file d’attente vers Azure DevOps sont déléguées au serveur local. Pour plus d’informations, consultez Agents de build et de mise en production. Vous pouvez également utiliser un autre outil de génération tel que Jenkins ou Team City.
Pour un résumé complet de toutes les fonctionnalités de gestion du cycle de vie des applications (ALM) de Visual Studio, Azure DevOps et Team Foundation Server, consultez DevOps avec Xamarin Apps.
Team Explorer Everywhere
Team Explorer Everywhere apporte la puissance de Team Foundation Server et d’Azure DevOps aux équipes qui se développent en dehors de Visual Studio. Il permet aux développeurs de se connecter à des projets d’équipe locaux ou dans le cloud à partir d’Eclipse ou du client de ligne de commande multiplateforme pour OS X et Linux. Team Explorer Everywhere fournit un accès complet au contrôle de version (y compris Git), aux éléments de travail et aux fonctionnalités de génération pour les plateformes non Windows.
Git
Git est une solution de gestion de versions open source populaire qui a été développée à l’origine pour gérer le code source du noyau Linux. Il s’agit d’un système très rapide et flexible qui est populaire auprès des projets logiciels de toutes tailles. Il se met facilement à l’échelle à partir de développeurs uniques avec un accès Internet médiocre à de grandes équipes qui s’étendent dans le monde entier. Git facilite également la création de branches, ce qui peut à son tour encourager des flux de développement parallèles avec un risque minimal.
Git peut fonctionner entièrement via des navigateurs web ou des clients d’interface utilisateur utilisateur qui s’exécutent sur Linux, Mac OSX et Windows. Il est gratuit pour les dépôts publics ; Les dépôts privés nécessitent un plan payant.
Les versions actuelles de Visual Studio pour Windows et Mac fournissent une prise en charge native de Git. Microsoft fournit une extension téléchargeable pour Git pour les versions antérieures de Visual Studio. Comme indiqué ci-dessus, Azure DevOps et TFS peuvent utiliser Git pour le contrôle de version au lieu de TFVC.
Subversion
Subversion (SVN) est un système de gestion de version populaire open source qui est utilisé depuis 2000. SVN s’exécute sur toutes les versions modernes d’OS X, Windows, FreeBSD, Linux et Unix. Visual Studio pour Mac prend en charge SVN en mode natif. Il existe des extensions tierces qui apportent la prise en charge de SVN à Visual Studio.
Environnements d’intégration continue
La configuration d’un environnement d’intégration continue implique de combiner un système de gestion de versions avec un service de build. Pour ce dernier, les deux plus courants sont :
- Azure Pipelines est le système de build d’Azure DevOps et TFS. Il est étroitement intégré à Visual Studio, ce qui permet aux développeurs de déclencher des builds, d’exécuter automatiquement des tests et de voir les résultats.
- Jenkins est un serveur CI open source avec un riche écosystème de plug-ins pour prendre en charge tous les types de développement de logiciels. Il s’exécute sur Windows et Mac OS X. Jenkins n’est pas intégré à un IDE spécifique. Au lieu de cela, il est configuré et géré via une interface web. Jenkins CI est également facile à installer et à configurer, ce qui le rend attrayant pour les petites équipes.
Vous pouvez utiliser TFS/Azure DevOps par lui-même, ou vous pouvez utiliser Jenkins en combinaison avec TFS/Azure DevOps ou Git, comme décrit dans les sections suivantes.
Azure DevOps et Team Foundation Server
Comme indiqué, Azure DevOps et Team Foundation Server fournissent des services de gestion de version et de génération. Les services de build nécessitent toujours une licence Xamarin Business ou Enterprise pour chaque plateforme cible.
Avec Azure DevOps, vous créez une définition de build distincte pour chaque plateforme cible et entrez la licence appropriée. Une fois configuré, Azure DevOps exécute des builds et des tests dans le cloud. Pour plus d’informations, consultez Azure Pipelines .
Avec Team Foundation Server, vous configurez une machine de build comme suit pour des plateformes cibles spécifiques :
- Android et Windows : Installez Visual Studio et les outils Xamarin (pour Android et Windows) et configurez avec vos licences Xamarin. Il est également nécessaire de déplacer le SDK Android vers un emplacement partagé sur le serveur où l’agent de build TFS peut le trouver. Pour plus d’informations, consultez Configuration de TFVC.
- iOS et Xamarin : Installez Visual Studio et les outils Xamarin sur le serveur Windows avec la licence appropriée. Ensuite, installez Visual Studio pour Mac sur un ordinateur Mac OS X accessible en réseau, qui servira d’hôte de build et créera le package d’application final (IPA pour iOS, APP pour OS X).
Le diagramme suivant illustre cette topographie :
Il est également possible de lier un serveur TFS local à un projet Azure DevOps afin que les builds Azure DevOps soient déléguées au serveur local. Pour plus d’informations, consultez Agents de génération et de mise en production.
Azure DevOps et Jenkins
Si vous utilisez Jenkins pour créer vos applications, vous pouvez stocker votre code dans Azure DevOps ou Team Foundation Server et continuer à utiliser Jenkins pour vos builds CI. Vous pouvez déclencher une build Jenkins lorsque vous envoyez du code au dépôt Git de votre projet d’équipe ou lorsque vous case activée du code dans TFVC. Pour plus d’informations, consultez Jenkins avec Azure DevOps.
Git et Jenkins
Un autre environnement CI courant peut être entièrement basé sur OS X. Ce scénario implique l’utilisation de Git pour le contrôle de code source et Jenkins pour le serveur de build. Les deux s’exécutent sur un seul ordinateur Mac OS X sur lequel Visual Studio pour Mac est installé. Ceci est très similaire à l’environnement Azure DevOps + Jenkins abordé dans la section précédente :
Important