Utilisation de Jenkins avec Xamarin

2023-07-13

Ce guide montre comment configurer Jenkins en tant que serveur d’intégration continue et automatiser la compilation d’applications mobiles créées avec Xamarin. Il explique comment installer Jenkins sur OS X, le configurer et configurer des travaux pour compiler des applications Xamarin.iOS et Xamarin.Android lorsque des modifications sont validées dans le système de gestion du code source.

Introduction à l’intégration continue avec Xamarin introduit l’intégration continue en tant que pratique de développement logiciel utile qui fournit un avertissement précoce du code rompu ou incompatible. CI permet aux développeurs de résoudre les problèmes et les problèmes à mesure qu’ils surviennent, et conserve le logiciel dans un état approprié pour le déploiement. Cette procédure pas à pas explique comment utiliser le contenu des deux documents ensemble.

Ce guide montre comment installer Jenkins sur un ordinateur dédié exécutant OS X et le configurer pour qu’il s’exécute automatiquement au démarrage de l’ordinateur. Une fois Jenkins installé, nous allons installer des plug-ins supplémentaires pour prendre en charge MS Build. Jenkins prend en charge Git prête à l’emploi. Si TFS est utilisé pour le contrôle de code source, un plug-in supplémentaire et des utilitaires de ligne de commande doivent également être installés.

Une fois Jenkins configuré et tous les plug-ins nécessaires installés, nous allons créer un ou plusieurs travaux pour compiler les projets Xamarin.Android et Xamarin.iOS. Un travail est une collection d’étapes et de métadonnées nécessaires pour effectuer un travail. Un travail se compose généralement des éléments suivants :

Gestion du code source (SCM) : il s’agit d’une entrée de méta-données dans les fichiers de configuration Jenkins qui contient des informations sur la connexion au contrôle de code source et les fichiers à récupérer.
Déclencheurs : les déclencheurs sont utilisés pour démarrer un travail en fonction de certaines actions, par exemple lorsqu’un développeur valide les modifications apportées au référentiel de code source.
Instructions de génération : il s’agit d’un plug-in ou d’un script qui compile le code source et produit un binaire qui peut être installé sur des appareils mobiles.
Actions de génération facultatives : cela peut inclure l’exécution de tests unitaires, l’exécution d’une analyse statique sur le code, la signature de code ou le démarrage d’un autre travail pour effectuer d’autres travaux liés à la génération.
Notifications : un travail peut envoyer un type de notification concernant l’état d’une build.
Sécurité : bien que facultative, il est fortement recommandé d’activer les fonctionnalités de sécurité Jenkins.

Ce guide explique comment configurer un serveur Jenkins couvrant chacun de ces points. À la fin de celle-ci, nous devrions avoir une bonne compréhension de la configuration et de la configuration de Jenkins pour créer des ADRESSES IPA et APK pour nos projets mobiles Xamarin.

Spécifications

Le serveur de build idéal est un ordinateur autonome dédié à l’objectif unique de la génération et éventuellement de tester l’application. Un ordinateur dédié garantit que les artefacts qui peuvent être requis pour d’autres rôles (comme celui d’un serveur web) ne contaminent pas la build. Par exemple, si le serveur de build agit également en tant que serveur web, le serveur web peut nécessiter une version conflictuelle de certaines bibliothèques courantes. En raison de ce conflit, le serveur web peut ne pas fonctionner correctement ou Jenkins peut créer des builds qui ne fonctionnent pas lors du déploiement sur les utilisateurs.

Le serveur de build pour les applications mobiles Xamarin est configuré très comme la station de travail d’un développeur. Il dispose d’un compte d’utilisateur dans lequel Jenkins, Visual Studio pour Mac et Xamarin.iOS et Xamarin.Android seront installés. Tous les certificats de signature de code, les profils d’approvisionnement et les magasins de clés doivent également être installés. En règle générale, le compte d’utilisateur du serveur de build est distinct de vos comptes de développeur : veillez à installer et configurer tous les logiciels, clés et certificats lors de la connexion avec le compte d’utilisateur du serveur de build.

Le diagramme suivant illustre tous ces éléments sur un serveur de build Jenkins classique :

Les applications iOS ne peuvent être générées et signées que sur un ordinateur exécutant macOS. Un Mac Mini est une option raisonnable à moindre coût, mais tout ordinateur capable d’exécuter OS X 10.10 (Yosemite) ou version ultérieure est suffisant.

Si TFS est utilisé pour le contrôle de code source, vous devez installer Team Explorer Everywhere. Team Explorer Everywhere fournit un accès multiplateforme à TFS sur le terminal dans macOS.

Configuration du pare-feu

Pour que les tests soient envoyés à Xamarin Test Cloud, l’ordinateur qui envoie les tests doit être en mesure de communiquer avec les serveurs de cloud de test. Les pare-feu doivent être configurés pour autoriser le trafic réseau vers et depuis les serveurs situés à testcloud.xamarin.com sur les ports 80 et 443. Ce point de terminaison est géré par DNS et l’adresse IP est susceptible de changer.

Dans certains cas, un test (ou un appareil exécutant le test) doit communiquer avec les serveurs web protégés par un pare-feu. Dans ce scénario, le pare-feu doit être configuré pour autoriser le trafic à partir des adresses IP suivantes :

195.249.159.238
195.249.159.239

Installation de Jenkins

La première tâche à utiliser Jenkins consiste à l’installer. Il existe trois façons d’exécuter Jenkins sur OS X :

En tant que démon, en cours d’exécution en arrière-plan.
À l’intérieur d’un conteneur servlet tel que Tomcat, Jetty ou JBoss.
En tant que processus normal s’exécutant sous un compte d’utilisateur.

La plupart des applications d’intégration continue traditionnelles s’exécutent en arrière-plan, en tant que démon (sur OS X ou *nix) ou en tant que service (sur Windows). Cela convient aux scénarios où aucune interaction de l’interface utilisateur utilisateur n’est requise et où la configuration de l’environnement de build peut être facilement effectuée. Les applications mobiles nécessitent également des magasins de clés et des certificats de signature susceptibles d’être problématiques d’accès lorsque Jenkins s’exécute en tant que démon. En raison de ces problèmes, ce document se concentre sur le troisième scénario : l’exécution de Jenkins sous un compte d’utilisateur sur le serveur de build.

Jenkins.App est un moyen pratique d’installer Jenkins. Il s’agit d’un wrapper AppleScript qui simplifie le démarrage et l’arrêt d’un serveur Jenkins. Au lieu d’exécuter dans un interpréteur de commandes bash, Jenkins s’exécute en tant qu’application avec une icône dans le Dock, comme illustré dans la capture d’écran suivante :

Le démarrage ou l’arrêt de Jenkins est aussi simple que le démarrage ou l’arrêt de Jenkins.App.

Pour installer Jenkins.App, téléchargez la dernière version à partir de la page de téléchargement du projet, illustré dans la capture d’écran ci-dessous :

Extrayez le fichier zip dans le /Applications dossier sur votre serveur de build et démarrez-le comme n’importe quelle autre application OS X. La première fois que vous démarrez Jenkins.App, une boîte de dialogue vous informe qu’elle télécharge Jenkins :

Une fois que Jenkins.App a terminé son téléchargement, il affiche une autre boîte de dialogue vous demandant si vous souhaitez personnaliser le démarrage Jenkins, comme illustré dans la capture d’écran suivante :

La personnalisation de Jenkins est facultative et n’a pas besoin d’être effectuée chaque fois que l’application est démarrée . Les paramètres par défaut pour Jenkins fonctionnent pour la plupart des situations.

S’il est nécessaire de personnaliser Jenkins, cliquez sur le bouton Modifier les valeurs par défaut. Cela vous présente deux boîtes de dialogue consécutives : une qui demande des paramètres de ligne de commande Java et une autre qui demande des paramètres de ligne de commande Jenkins. Les deux captures d’écran suivantes montrent ces deux boîtes de dialogue :

Une fois Jenkins en cours d’exécution, vous souhaiterez peut-être le définir en tant qu’élément de connexion afin qu’il démarre chaque fois que l’utilisateur se connecte à l’ordinateur. Pour ce faire, cliquez avec le bouton droit sur l’icône Jenkins dans le dock et choisissez Options... > Ouvrez à l’adresse Login, comme illustré dans la capture d’écran suivante :

Cela entraîne Jenkins.App lancer automatiquement chaque fois que l’utilisateur se connecte, mais pas lorsque l’ordinateur démarre. Il est possible de spécifier un compte d’utilisateur que OS X utilisera pour se connecter automatiquement au moment du démarrage. Ouvrez les préférences système, puis sélectionnez l’icône Utilisateurs &Groupes , comme illustré dans cette capture d’écran :

Cliquez sur le bouton Options de connexion, puis choisissez le compte que OS X utilisera pour la connexion au moment du démarrage.

À ce stade, Jenkins a été installé. Toutefois, si nous voulons créer des applications mobiles Xamarin, nous devons installer certains plug-ins.

Installation de plug-ins

Une fois le programme d’installation Jenkins.App terminé, il démarre Jenkins et lance le navigateur web avec l’URL http://localhost:8080, comme illustré dans la capture d’écran ci-dessous :

Dans cette page, sélectionnez Jenkins > Manage Jenkins > Manage Plugins dans le menu dans le coin supérieur gauche, comme illustré dans la capture d’écran ci-dessous :

Cette opération affiche la page Gestionnaire de plug-in Jenkins. Si vous cliquez sur l’onglet Disponible, vous verrez une liste de plus de 600 plug-ins qui peuvent être téléchargés et installés. Ceci est illustré dans la capture d’écran ci-dessous :

Le défilement de tous les 600 plug-ins pour trouver quelques-uns peut être fastidieux et sujet aux erreurs. Jenkins fournit un champ de recherche de filtre dans le coin supérieur droit de l’interface. L’utilisation de ce champ filtre pour rechercher simplifie la localisation et l’installation d’un ou de tous les plug-ins suivants :

Plug-in Jenkins MSBuild : ce plug-in permet de générer Visual Studio et Visual Studio pour Mac solutions (.sln) et des projets (.csproj).
Plug-in Injector d’environnement : il s’agit d’un plug-in facultatif mais utile qui permet de définir des variables d’environnement au niveau du travail et de la génération. Il offre également une protection supplémentaire pour les variables telles que les mots de passe utilisés pour signer l’application. Il est parfois abrégé en tant que plug-in EnvInject .
Plug-in Team Foundation Server : il s’agit d’un plug-in facultatif obligatoire uniquement si vous utilisez Team Foundation Server ou Team Foundation Services pour le contrôle de code source.

Jenkins prend en charge Git sans plug-ins supplémentaires.

Après avoir installé tous les plug-ins, vous devez redémarrer Jenkins et configurer les paramètres globaux pour chaque plug-in. Vous trouverez les paramètres globaux d’un plug-in en sélectionnant Jenkins Manage Jenkins >> Configure System dans le coin supérieur gauche, comme illustré dans la capture d’écran ci-dessous :

Lorsque vous sélectionnez cette option de menu, vous accédez à la page Configurer le système [Jenkins]. Cette page contient des sections pour configurer Jenkins lui-même et définir certaines des valeurs globales du plug-in. La capture d’écran ci-dessous illustre un exemple de cette page :

Configuration du plug-in MSBuild

Le plug-in MSBuild doit être configuré pour utiliser /Library/Frameworks/Mono.framework/Commands/xbuild pour compiler Visual Studio pour Mac solutions et fichiers projet. Faites défiler la page Configurer le système [Jenkins] jusqu’à ce que le bouton Ajouter MSBuild s’affiche, comme illustré dans la capture d’écran ci-dessous :

Cliquez sur ce bouton, puis renseignez les champs Nom et Chemin d’accès aux champs MSBuild du formulaire qui s’affiche. Le nom de votre installation MSBuild doit être significatif, tandis que le chemin d’accès à MSBuild doit être le chemin d’accès xbuild, qui est généralement /Library/Frameworks/Mono.framework/Commands/xbuild. Après avoir enregistré les modifications en cliquant sur le bouton Enregistrer ou Appliquer en bas de la page, Jenkins sera en mesure d’utiliser xbuild pour compiler vos solutions.

Configuration du plug-in TFS

Cette section est obligatoire si vous envisagez d’utiliser TFS pour votre contrôle de code source.

Pour qu’une station de travail macOS interagisse avec un serveur TFS, Team Explorer Everywhere doit être installé sur la station de travail. Team Explorer Everywhere est un ensemble d’outils de Microsoft qui inclut un client de ligne de commande multiplateforme pour accéder à TFS. Team Explorer Everywhere peut être téléchargé à partir de Microsoft et installé en trois étapes :

Décompressez le fichier d’archive dans un répertoire accessible au compte d’utilisateur. Par exemple, vous pouvez décompresser le fichier sur ~/tee.
Configurez l’interpréteur de commandes ou le chemin d’accès système pour inclure le dossier qui contient les fichiers qui ont été décompressés à l’étape 1 ci-dessus. Par exemple,
```
echo export PATH~/tee/:$PATH' >> ~/.bash_profile
```
Pour vérifier que Team Explorer Everywhere est installé, ouvrez une session de terminal et exécutez la tf commande. Si tf est correctement configuré, vous verrez la sortie suivante dans votre session de terminal :
```
$ tf
Team Explorer Everywhere Command Line Client (version 11.0.0.201306181526)

Available commands and their options:
```

Une fois le client de ligne de commande pour TFS installé, Jenkins doit être configuré avec le chemin complet du client de tf ligne de commande. Faites défiler la page Configurer le système [Jenkins] jusqu’à ce que vous trouviez la section Team Foundation Server, comme illustré dans la capture d’écran suivante :

Entrez le chemin complet de la tf commande, puis cliquez sur le bouton Enregistrer .

Configurer la sécurité Jenkins

Lors de la première installation, Jenkins a la sécurité désactivée. Il est donc possible pour tout utilisateur de configurer et d’exécuter n’importe quel type de travail anonymement. Cette section explique comment configurer la sécurité à l’aide de la base de données utilisateur Jenkins pour configurer l’authentification et l’autorisation.

Vous trouverez les paramètres de sécurité en sélectionnant Jenkins Manage Jenkins >> Configure Global Security, comme illustré dans cette capture d’écran :

Dans la page Configurer la sécurité globale, case activée la boîte de réception Activer la sécurité case activée et le formulaire Contrôle d’accès doit apparaître, comme dans la capture d’écran suivante :

Activez la case d’option pour la base de données utilisateur de Jenkins dans la section Domaine de sécurité et vérifiez que les utilisateurs autorisés à s’inscrire sont également case activée ed, comme illustré dans la capture d’écran suivante :

Enfin, redémarrez Jenkins et créez un compte. Le premier compte créé est le compte racine, et ce compte sera automatiquement promu à un administrateur. Revenez à la page Configurer la sécurité globale et case activée hors de la case d’option de sécurité basée sur matrice. Le compte racine doit disposer d’un accès complet et le compte anonyme doit disposer d’un accès en lecture seule, comme illustré dans la capture d’écran suivante :

Une fois ces paramètres enregistrés et Jenkins redémarré, la sécurité est activée.

Désactivation de la sécurité

En cas de verrouillage à l’échelle de Jenkins ou d’un mot de passe oublié, il est possible de désactiver la sécurité en procédant comme suit :

Arrêtez Jenkins. Si vous utilisez Jenkins.app, vous pouvez le faire en cliquant avec le bouton droit sur l’icône Jenkins.App dans le Dock, puis en sélectionnant Quitter dans le menu qui s’affiche :
Ouvrez le fichier ~/.jenkins/config.xml dans un éditeur de texte.
Remplacez la valeur de true l’élément <usesecurity></usesecurity> par false.
Supprimez les éléments et les <authorizationstrategy></authorizationstrategy><securityrealm></securityrealm> éléments du fichier.
Redémarrez Jenkins.

Configuration d’un travail

Au niveau supérieur, Jenkins organise toutes les différentes tâches requises pour générer des logiciels dans un travail. Un travail a également des métadonnées associées, fournissant des informations sur la génération, telles que la façon d’obtenir le code source, la fréquence à laquelle la build doit s’exécuter, les variables spéciales nécessaires à la génération et la façon d’avertir les développeurs si la build échoue.

Les travaux sont créés en sélectionnant Jenkins > New Job dans le menu dans le coin supérieur droit, comme illustré dans la capture d’écran suivante :

Jobs are created by selecting Jenkins New Job from the menu in the upper right hand corner

La page Nouveau travail [Jenkins] s’affiche. Entrez un nom pour le travail, puis sélectionnez la case d’option Générer un projet logiciel de style gratuit. La capture d’écran suivante montre un exemple de ceci :

Enter a name for the job, and select the Build a free-style software project radio button

Cliquez sur le bouton OK pour afficher la page de configuration du travail. Cela doit ressembler à la capture d’écran suivante :

This should resemble this screenshot

Jenkins organise les travaux dans un répertoire sur le disque dur situé sur le chemin suivant : ~/.jenkins/jobs/[JOB NAME]

Ce dossier contient tous les fichiers et artefacts spécifiques au travail, tels que les journaux, les fichiers de configuration et le code source à compiler.

Une fois le travail initial créé, il doit être configuré avec un ou plusieurs des éléments suivants :

Le système de gestion du code source doit être spécifié.
Une ou plusieurs actions de génération doivent être ajoutées au projet. Il s’agit des étapes ou des tâches requises pour générer l’application.
Le travail doit être affecté à un déclencheur de build : un ensemble d’instructions indiquant à Jenkins la fréquence à laquelle récupérer le code et générer le projet final.

Configuration du contrôle de code source

La première tâche que Jenkins effectue est de récupérer le code source du système de gestion du code source. Jenkins prend en charge la plupart des systèmes de gestion de code source populaires disponibles aujourd’hui. Cette section couvre deux systèmes populaires, Git et Team Foundation Server. Chacun de ces systèmes de gestion du code source est abordé plus en détail dans les sections ci-dessous.

Utilisation de Git pour le contrôle de code source

Si vous utilisez TFS pour le contrôle de code source, ignorez cette section et passez à la section suivante à l’aide de TFS.

Jenkins prend en charge Git prête à l’emploi : aucun plug-in supplémentaire n’est nécessaire. Pour utiliser Git, cliquez sur la case d’option Git et entrez l’URL du dépôt Git, comme illustré dans la capture d’écran suivante :

To use Git, click on the Git radio button and enter the URL for the Git repository

Une fois les modifications enregistrées, la configuration Git est terminée.

Utilisation de TFS pour la gestion du code source

Cette section s’applique uniquement aux utilisateurs TFS.

Cliquez sur la case d’option Team Foundation Server et la section de configuration TFS doit apparaître, comme dans la capture d’écran suivante :

Click on the Team Foundation Server radio button and the TFS configuration section should appear

Fournissez les informations nécessaires pour TFS. La capture d’écran suivante montre un exemple de formulaire terminé :

This screenshot shows an example of the completed form

Test de la configuration du contrôle de code source

Une fois le contrôle de code source approprié configuré, cliquez sur Enregistrer pour enregistrer les modifications. Cette opération vous renvoie à la page d’accueil du travail, qui ressemble à la capture d’écran suivante :

This will return you to the home page for the job, which will resemble this screenshot

La façon la plus simple de vérifier que le contrôle de code source est correctement configuré consiste à déclencher une build manuellement, même s’il n’existe aucune action de génération spécifiée. Pour démarrer manuellement une build, la page d’accueil du travail comporte un lien Générer maintenant dans le menu situé à gauche, comme illustré dans la capture d’écran ci-dessous :

To start a build manually, the home page of the job has a Build Now link in the menu on the left hand side

Quand une build a été démarrée, la boîte de dialogue Historique des builds affiche un cercle bleu clignotant, une barre de progression, le numéro de build et l’heure à laquelle la build a démarré, comme dans la capture d’écran suivante :

When a build has been started, the Build History dialog displays a flashing blue circle, a progress bar, the build number and the time that the build started

Si le travail réussit, un cercle bleu s’affiche. Si le travail échoue, un cercle rouge s’affiche.

Pour vous aider à résoudre les problèmes qui peuvent survenir dans le cadre de la build, Jenkins capture toutes les sorties de la console pour le travail. Pour afficher la sortie de la console, cliquez sur le travail dans l’historique des builds, puis sur le lien Sortie de la console dans le menu de gauche. La capture d’écran suivante montre le lien Sortie de la console, ainsi que la sortie d’un travail réussi :

This screenshot shows the Console Output link, as well as some of the output from a successful job

Emplacement des artefacts de build

Jenkins récupère l’intégralité du code source dans un dossier spécial appelé espace de travail. Ce répertoire se trouve à l’intérieur du dossier à l’emplacement suivant :

~/.jenkins/jobs/[JOB NAME]/workspace

Le chemin d’accès à l’espace de travail sera stocké dans une variable d’environnement nommée $WORKSPACE.

Il est possible de parcourir le dossier de l’espace de travail dans Jenkins en accédant à la page d’accueil d’un travail, puis en cliquant sur le lien Espace de travail dans le menu de gauche. La capture d’écran suivante montre un exemple d’espace de travail pour un travail nommé HelloWorld :

This screenshot shows an example of the workspace for a job named HelloWorld

Déclencheurs de build

Il existe plusieurs stratégies différentes pour lancer des builds dans Jenkins : elles sont appelées déclencheurs de build. Un déclencheur de build permet à Jenkins de décider quand démarrer un travail et de générer le projet. Deux des déclencheurs de build les plus courants sont les suivants :

Générer régulièrement : ce déclencheur entraîne le démarrage d’un travail à intervalles spécifiés, par exemple toutes les deux heures ou à minuit les jours de semaine. La build démarre, qu’il y ait eu des modifications dans le référentiel de code source.
Poll SCM : ce déclencheur interroge régulièrement le contrôle de code source. Si des modifications ont été validées dans le référentiel de code source, Jenkins démarre une nouvelle build.

L’interrogation de SCM est un déclencheur populaire, car il fournit des commentaires rapides lorsqu’un développeur valide les modifications qui provoquent l’arrêt de la build. Cela est utile pour alerter les équipes que du code récemment validé provoque des problèmes et permet aux développeurs de résoudre le problème alors que les modifications sont toujours fraîches à l’esprit.

Les builds périodiques sont souvent utilisées pour créer une version de l’application qui peut être distribuée aux testeurs. Par exemple, une build périodique peut être planifiée vendredi soir afin que les membres de l’équipe de l’AQ puissent tester le travail de la semaine précédente.

Compilation d’applications Xamarin.iOS

Les projets Xamarin.iOS peuvent être compilés sur la ligne de commande à l’aide xbuild ou msbuild. La commande shell s’exécute dans le contexte du compte d’utilisateur qui exécute Jenkins. Il est important que le compte d’utilisateur ait accès au profil d’approvisionnement afin que l’application puisse être correctement empaquetée pour la distribution. Il est possible d’ajouter cette commande shell à la page de configuration du travail.

Faites défiler vers le bas jusqu’à la section Build . Cliquez sur le bouton Ajouter une étape de génération et sélectionnez Exécuter l’interpréteur de commandes, comme illustré par la capture d’écran suivante :

Click the Add build step button and select Execute shell

Ligne de commande suivante pour spécifier une build Release de la solution SOLUTION_FILE.sln pour i Téléphone. L’emplacement de l’IPA peut être défini en spécifiant la IpaPackageDir propriété sur la ligne de commande :

Sur mac, à l’aide de xbuild :

xbuild /p:Configuration="Release" \ 
       /p:Platform="iPhone" \ 
       /p:IpaPackageDir="$HOME/Builds" \
       /t:Build MyProject.sln

La commande xbuild se trouve généralement dans le répertoire /Library/Frameworks/Mono.framework/Commands.

Sur Windows, à l’aide de msbuild :

msbuild /p:Configuration="Release" 
        /p:Platform="iPhone" 
        /p:IpaPackageDir="%USERPROFILE%\Builds" 
        /p:ServerAddress="192.168.1.3" /p:ServerUser="macuser"  
        /t:Build MyProject.sln

msbuild ne développe $( ) pas automatiquement les expressions passées par la ligne de commande. Pour cette raison, il est recommandé d’utiliser un chemin complet lors de la définition de IpaPackageDir la ligne de commande.

Pour plus d’informations sur la IpaPackageDir propriété, consultez les notes de publication pour iOS 9.8.

Création d’un projet Xamarin.Android

La création d’un projet Xamarin.Android est très similaire au concept de création d’un projet Xamarin.iOS. Pour créer un APK à partir d’un projet Xamarin.Android, Jenkins doit être configuré pour effectuer les deux étapes suivantes :

Compiler le projet à l’aide du plug-in MSBuild
Signez et zip alignez l’APK avec un magasin de clés de mise en production valide.

Ces deux étapes seront abordées plus en détail dans les deux sections suivantes.

Création de l’APK

Cliquez sur le bouton Ajouter une étape de génération, puis sélectionnez Générer un projet ou une solution Visual Studio à l’aide de MSBuild, comme illustré dans la capture d’écran ci-dessous :

Creating the APK Click on the Add build step button, and select Build a Visual Studio project or solution using MSBuild

Une fois l’étape de génération ajoutée au projet, renseignez les champs de formulaire qui s’affichent. La capture d’écran suivante est un exemple du formulaire terminé :

Once the build step is added to the project, fill in the form fields that appear

Cette étape de génération s’exécute xbuild dans le dossier $WORKSPACE . Le fichier de build MSBuild est défini sur le fichier Xamarin.Android.csproj . Les arguments de ligne de commande spécifient une build de mise en production du packageForAndroid cible. Le produit de cette étape est un APK qui se trouve à l’emplacement suivant :

$WORKSPACE/[PROJECT NAME]/bin/Release

La capture d’écran suivante montre un exemple de cet APK :

This screenshot shows an example of this APK

Cet APK n’est pas prêt pour le déploiement, car il n’a pas été signé avec un magasin de clés privé et doit être aligné sur zip.

Signature et zipaligning de l’APK pour la version

La signature et le zipaligning de l’APK sont techniquement deux tâches distinctes effectuées par deux outils en ligne de commande distincts du Kit de développement logiciel (SDK) Android. Toutefois, il est pratique de les effectuer dans une seule action de génération. Pour plus d’informations sur la signature et le zipaligning d’un APK, consultez la documentation de Xamarin sur la préparation d’une application Android à des fins de publication.

Ces deux commandes nécessitent des paramètres de ligne de commande qui peuvent varier du projet au projet. De plus, certains de ces paramètres de ligne de commande sont des mots de passe qui ne doivent pas apparaître dans la sortie de la console lorsque la build est en cours d’exécution. Nous allons stocker certains de ces paramètres de ligne de commande dans les variables d’environnement. Les variables d’environnement requises pour la signature et/ou l’alignement zip sont décrites dans le tableau ci-dessous :

Variable d’environnement	Description
KEYSTORE_FILE	Il s’agit du chemin d’accès au magasin de clés pour la signature de l’APK
KEYSTORE_ALIAS	Clé dans le magasin de clés qui sera utilisée pour signer l’APK.
INPUT_APK	APK créé par `xbuild`.
SIGNED_APK	L’APK signé produit par `jarsigner`.
FINAL_APK	Il s’agit de l’APK aligné zip produit par `zipalign`.
STORE_PASS	Il s’agit du mot de passe utilisé pour accéder au contenu du magasin de clés pour chanter le fichier.

Comme décrit dans la section Configuration requise, ces variables d’environnement peuvent être définies pendant la génération à l’aide du plug-in EnvInject. Le travail doit avoir une nouvelle étape de génération ajoutée en fonction des variables d’environnement Inject, comme illustré dans la capture d’écran suivante :

The job should have a new build step added based on the Inject environment variables

Dans le champ de formulaire Contenu des propriétés qui s’affiche, les variables d’environnement sont ajoutées, une par ligne, au format suivant :

ENVIRONMENT_VARIABLE_NAME = value

La capture d’écran suivante montre les variables d’environnement requises pour signer l’APK :

This screenshot shows the environment variables that are required for signing the APK

Notez que certaines des variables d’environnement pour les fichiers APK sont basées sur la variable d’environnement WORKSPACE .

La variable d’environnement finale est le mot de passe pour accéder au contenu du magasin de clés : STORE_PASS. Les mots de passe sont des valeurs sensibles qui doivent être masquées ou omises dans les fichiers journaux. Le plug-in EnvInject peut être configuré pour protéger ces valeurs afin qu’elles ne s’affichent pas dans les journaux.

Juste avant la section Build de la configuration du travail est une section Environnement de build . Lorsque la boîte de passe Injecter des mots de passe case activée box est activée, certains champs de formulaire s’affichent. Ces champs de formulaire sont utilisés pour capturer le nom et la valeur de la variable d’environnement. La capture d’écran suivante illustre l’ajout de la variable d’environnement STORE_PASS :

This screenshot is an example of adding the STOREPASS environment variable

Une fois que les variables d’environnement ont été initialisées, l’étape suivante consiste à ajouter une étape de génération pour la signature et le zip alignant l’APK. Immédiatement après l’étape de génération pour insérer les variables d’environnement, il s’agira d’une autre build de commande Exécuter l’interpréteur de commandes qui s’exécutera jarsigner et zipalign. Chaque commande prend une ligne, comme indiqué dans l’extrait de code suivant :

jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore $KEYSTORE_FILE -storepass $STORE_PASS -signedjar $SIGNED_APK $INPUT_APK $KEYSTORE_ALIAS
zipalign -f -v 4 $SIGNED_APK $FINAL_APK

La capture d’écran suivante montre un exemple de saisie des jarsigner commandes et zipalign des commandes à l’étape :

This screenshot shows an example of how to enter the jarsigner and zipalign commands into the step

Une fois toutes les actions de génération en place, il est recommandé de déclencher une build manuelle pour vérifier que tout fonctionne. Si la build échoue, la sortie de la console doit être examinée pour plus d’informations sur ce qui a provoqué l’échec de la build.

Envoi de tests au cloud de test

Les tests automatisés peuvent être envoyés à Test Cloud à l’aide de commandes Shell. Pour plus d’informations sur la configuration d’une série de tests dans le cloud de test Xamarin, consultez Préparation des applications Xamarin.Android et préparation des applications Xamarin.iOS.

Résumé

Dans ce guide, nous avons introduit Jenkins en tant que serveur de build sur macOS et l’avons configuré pour compiler et préparer les applications mobiles Xamarin pour la mise en production. Nous avons installé Jenkins sur un ordinateur macOS, ainsi que plusieurs plug-ins pour prendre en charge le processus de génération. Nous avons créé et configuré un travail qui extrait du code à partir de TFS ou Git, puis compilez ce code dans une application prête pour la mise en production. Nous avons également exploré deux façons différentes de planifier l’exécution des travaux.

Partager via