Utilisation de TeamCity avec Xamarin

Ce guide décrit les étapes impliquées dans l’utilisation de TeamCity pour compiler des applications mobiles, puis les soumettre au test App Center.

Comme indiqué dans le guide d’introduction à l’intégration continue, l’intégration continue (CI) est une pratique utile lors du développement d’applications mobiles de qualité. Il existe de nombreuses options viables pour les logiciels de serveur d’intégration continue ; ce guide se concentrera sur TeamCity à partir de JetBrains.

Il existe plusieurs permutations différentes d’une installation TeamCity. La liste suivante décrit certaines de ces permutations :

• Service Windows : dans ce scénario, TeamCity démarre quand Windows démarre en tant que service Windows. Il doit être associé à un hôte de build Mac pour compiler toutes les applications iOS.

• Lancez daemon sur OS X : conceptuellement, cela est similaire à l’exécution en tant que service Windows décrit à l’étape précédente. Par défaut, les builds sont exécutées sous le compte racine.

• Compte d’utilisateur sur OS X : il est possible d’exécuter TeamCity sous un compte d’utilisateur qui démarre chaque fois que l’utilisateur se connecte.

Parmi les scénarios précédents, l’exécution de TeamCity sous un compte d’utilisateur sur OS X est la plus simple et la plus simple à configurer.

Il existe plusieurs étapes liées à la configuration de TeamCity :

• Installation de TeamCity : l’installation de TeamCity n’est pas décrite dans ce guide. Ce guide suppose que TeamCity est installé et exécuté sous un compte d’utilisateur. Vous trouverez des instructions sur l’installation de TeamCity dans la documentation TeamCity 8 par JetBrains.

• Préparation du serveur de build : cette étape implique l’installation des logiciels, outils et certificats nécessaires pour générer des applications mobiles et les préparer à la distribution.

• Création d’un script de build : cette étape n’est pas strictement nécessaire, mais un script de build est une aide utile pour créer des applications sans assistance. L’utilisation d’un script de build vous aidera à résoudre les problèmes de génération qui peuvent survenir et fournit un moyen cohérent et reproductible de créer les fichiers binaires pour la distribution, même si l’intégration continue n’est pas pratiquée.

• Création d’un projet TeamCity : une fois les trois étapes précédentes terminées, nous devons créer un projet TeamCity qui contiendra toutes les métadonnées nécessaires pour récupérer le code source, compiler les projets et soumettre les tests à App Center Test.

Spécifications

L’expérience avec le test App Center est requise.

La connaissance de TeamCity 8.1 est requise. L’installation de TeamCity dépasse le cadre de ce document. Il est supposé que TeamCity est installé sur OS X Mavericks et s’exécute sous un compte d’utilisateur standard et non le compte racine.

Le serveur de build doit être un ordinateur autonome, exécutant OS X, dédié à l’intégration continue. Dans l’idéal, le serveur de build ne sera responsable d’aucun autre rôle, tel qu’un serveur de base de données, un serveur web ou une station de travail développeur.

Important

Ce guide ne couvre pas une installation « sans tête » de Xamarin.

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

Préparation du serveur de build

Une étape cruciale de la configuration d’un serveur de build consiste à installer tous les outils, logiciels et certificats nécessaires pour générer les applications mobiles. Il est important que le serveur de build puisse compiler la solution mobile et exécuter tous les tests. Pour réduire les problèmes de configuration, les logiciels et les outils doivent être installés dans le même compte d’utilisateur qui héberge TeamCity. La liste suivante détaille les éléments requis :

1. Visual Studio pour Mac : cela inclut Xamarin.iOS et Xamarin.Android.
2. Connectez-vous au magasin de composants Xamarin : cette étape est facultative et uniquement requise si votre application utilise des composants à partir du magasin de composants Xamarin. La connexion proactive au magasin de composants à ce stade empêche tout problème lorsqu’une build TeamCity tente de compiler l’application.
3. Xcode : Xcode est requis pour compiler et signer des applications iOS.
4. Outils en ligne de commande Xcode : décrit à l’étape 1 de la section Installation du guide de mise à jour de Ruby avec rbenv .
5. Profils d’identité de signature et d’approvisionnement : importez les certificats et le profil d’approvisionnement via XCode. Pour plus d’informations, consultez le guide d’Apple sur l’exportation des identités de signature et des profils d’approvisionnement.
6. Magasins de clés Android : copiez les magasins de clés Android requis dans un répertoire auquel l’utilisateur TeamCity a accès, c’est-à-dire ~/Documents/keystores/MyAndroidApp1.
7. Calabash : il s’agit d’une étape facultative si votre application a des tests écrits à l’aide de Calabash. Pour plus d’informations, consultez le guide d’installation de Calabash sur OS X Mavericks et le guide de mise à jour de Ruby avec rbenv .

Le diagramme suivant illustre tous ces composants :

Une fois tous les logiciels installés, connectez-vous au compte d’utilisateur et vérifiez que tous les logiciels sont correctement installés et fonctionnent. Cela doit impliquer la compilation de la solution et l’envoi de l’application au test App Center. Cela peut être simplifié en exécutant le script de build, comme décrit dans la section suivante.

Créer un script de build

Bien qu’il soit possible pour TeamCity de gérer tous les aspects de la compilation et de l’envoi d’applications mobiles à App Center Test par lui-même ; Il est recommandé de créer un script de build. Un script de build offre les avantages suivants :

1. Documentation : un script de build sert de forme de documentation sur la façon dont le logiciel est généré. Cela supprime certaines des « magies » associées au déploiement de l’application et permet aux développeurs de se concentrer sur les fonctionnalités.
2. Répétabilité : un script de build garantit que chaque fois que l’application est compilée et déployée, elle se produit de la même façon, quelle que soit la personne ou la personne qui effectue le travail. Cette cohérence reproductible supprime tous les problèmes ou erreurs susceptibles d’apparaître en raison d’une erreur de build ou d’une erreur humaine incorrectement exécutée.
3. Contrôle de version : un script de build peut être inclus dans le système de contrôle de code source. Cela signifie que les modifications apportées au script de build peuvent être suivies, surveillées et corrigées si des erreurs ou des inexactitudes sont trouvées.
4. Préparer l’environnement : un script de build peut inclure une logique pour installer les dépendances tierces requises. Cela garantit que les applications sont générées avec les composants appropriés.

Le script de build peut être aussi simple qu’un fichier PowerShell (sur Windows) ou un script bash (sur OS X). Lors de la création du script de génération, il existe plusieurs choix pour les langages de script :

• Rake : il s’agit d’un langage spécifique au domaine (DSL) pour la création de projets, basé sur Ruby. Rake a l’avantage de la popularité et d’un écosystème riche de bibliothèques.

• psake : il s’agit d’une bibliothèque Windows PowerShell pour la création de logiciels

• FAKE : il s’agit d’une DSL basée sur F# qui permet d’utiliser des bibliothèques .NET existantes si nécessaire.

Le langage de script utilisé dépend de vos préférences et exigences.

Remarque

Il est possible d’utiliser un système de génération basé sur XML, tel que MSBuild ou NAnt, mais il manque l’expressivité et la maintenance d’une DSL dédiée à la création de logiciels.

Paramétrage du script de build

Le processus de création et de test de logiciels nécessite des informations qui doivent être conservées secrètes. La création d’un APK peut nécessiter un mot de passe pour le magasin de clés et/ou l’alias de clé dans le magasin de clés. De même, App Center Test nécessite une clé API unique à un développeur. Ces types de valeurs ne doivent pas être codés en dur dans le script de génération. Au lieu de cela, ils doivent être passés en tant que variables au script de génération.

Les valeurs moins sensibles sont des valeurs telles que l’ID d’appareil iOS ou l’ID d’appareil Android qui identifient les appareils qu’App Center doit utiliser pour les exécutions de test. Il ne s’agit pas de valeurs qui doivent être protégées, mais elles peuvent passer de la génération à la génération.

Le stockage de ces types de variables en dehors du script de génération facilite également le partage du script de génération au sein d’une organisation, avec des développeurs, par exemple. Les développeurs peuvent utiliser exactement le même script que le serveur de build, mais peuvent utiliser leurs propres magasins de clés et clés API.

Il existe deux options possibles pour stocker ces valeurs sensibles :

• Fichier de configuration : pour protéger la clé API, cette valeur ne doit pas être case activée dans le contrôle de version. Le fichier peut être créé pour chaque ordinateur. La façon dont les valeurs sont lues à partir de ce fichier dépend du langage de script utilisé.

• Variables d’environnement : elles peuvent être facilement définies par ordinateur et indépendantes du langage de script sous-jacent.

Il existe des avantages et des inconvénients pour chacun de ces choix. TeamCity fonctionne correctement avec les variables d’environnement. Ce guide recommande donc cette technique lors de la création de scripts de génération.

Étapes de génération

Le script de build doit effectuer les étapes suivantes :

• Compilez l’application : cela inclut la signature de l’application avec le profil d’approvisionnement correct.

• Envoyez l’application au cloud de test Xamarin : cela inclut la signature et la compression de l’APK avec le magasin de clés approprié.

Ces deux étapes seront expliquées plus en détail ci-dessous.

Compilation d’une application Xamarin.iOS

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.

Compilation d’une application Xamarin.Android

Pour compiler une application Android, utilisez xbuild (ou msbuild sur Windows) :

/Library/Frameworks/Mono.framework/Commands/xbuild /t:SignAndroidPackage /p:Configuration=Release /path/to/android.csproj

La compilation de l’application Android xbuild utilise le projet, tandis que l’application iOS xbuild utilise la solution.

Envoi de Xamarin.UITests à App Center

UiTests est envoyé à l’aide de l’interface CLI App Center, comme indiqué dans l’extrait de code suivant :

appcenter test run uitest --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --merge-nunit-xml report.xml --build-dir pathToUITestBuildDir

Lorsque le test est exécuté, les résultats du test sont retournés sous la forme d’un fichier XML de style NUnit appelé report.xml. TeamCity affiche les informations dans le journal de génération.

Pour plus d’informations sur l’envoi d’UITests à App Center, consultez Préparation d’applications Xamarin.Android ou préparation d’applications Xamarin.iOS.

Envoi de tests calabash à App Center

Les tests calabash sont envoyés à l’aide de l’interface CLI App Center, comme indiqué dans l’extrait de code suivant :

appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --project-dir pathToProjectDir

Pour soumettre une application Android au test App Center, il est nécessaire de reconstruire d’abord le serveur de test APK à l’aide de calabash-android :

$ calabash-android build </path/to/signed/APK>
$ appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK> --project-dir pathToProjectDir

Pour plus d’informations sur l’envoi de tests Calabash, consultez le guide de Xamarin sur l’envoi de tests Calabash à Test Cloud.

Création d’un projet TeamCity

Une fois TeamCity installé et Visual Studio pour Mac pouvez générer votre projet, il est temps de créer un projet dans TeamCity pour générer le projet et l’envoyer à App Center.

1. Démarré en vous connectant à TeamCity via le navigateur web. Accédez au projet racine :

   Sous le projet racine, créez un sous-projet :

   

2. Une fois le sous-projet créé, ajoutez une nouvelle configuration de build :

   

3. Attachez un projet VCS à la configuration de build. Pour ce faire, utilisez l’écran Paramètre de contrôle de version :

   

   S’il n’existe aucun projet VCS créé, vous pouvez en créer un à partir de la page Nouvelle racine VCS ci-dessous :

   

   Une fois la racine VCS attachée, TeamCity case activée le projet et tente de détecter automatiquement les étapes de génération. Si vous connaissez TeamCity, vous pouvez sélectionner l’une des étapes de génération détectées. Il est sûr d’ignorer les étapes de génération détectées pour l’instant.

4. Ensuite, configurez un déclencheur de build. Cela met en file d’attente une build lorsque certaines conditions sont remplies, par exemple lorsqu’un utilisateur valide le code dans le référentiel. La capture d’écran suivante montre comment ajouter un déclencheur de build :

   Vous pouvez voir un exemple de configuration d’un déclencheur de build dans la capture d’écran suivante :

   

5. La section précédente, paramétrage du script de build, suggère de stocker certaines valeurs en tant que variables d’environnement. Ces variables peuvent être ajoutées à la configuration de build via l’écran Paramètres. Ajoutez les variables de la clé API App Center, de l’ID d’appareil iOS et de l’ID d’appareil Android, comme illustré dans la capture d’écran ci-dessous :

   

6. La dernière étape consiste à ajouter une étape de génération qui appelle le script de build pour compiler l’application et mettre l’application en file d’attente dans App Center Test. La capture d’écran suivante est un exemple d’étape de génération qui utilise un Rakefile pour générer une application :

   

7. À ce stade, la configuration de build est terminée. Il est judicieux de déclencher une build pour confirmer que le projet est correctement configuré. Une bonne façon de procéder consiste à valider une petite modification insignifiante du référentiel. TeamCity doit détecter la validation et démarrer une build.

8. Une fois la build terminée, inspectez le journal de build et vérifiez s’il existe des problèmes ou des avertissements avec la build qui nécessitent une attention particulière.

Résumé

Ce guide a abordé comment utiliser TeamCity pour générer des applications Xamarin Mobile, puis les soumettre au test App Center. Nous avons discuté de la création d’un script de build pour automatiser le processus de génération. Le script de génération s’occupe de la compilation de l’application, de l’envoi au test App Center et de l’attente des résultats.

Nous avons ensuite abordé comment créer un projet dans TeamCity qui met en file d’attente une build chaque fois qu’un développeur valide le code et appelle le script de génération.

Liens associés

• Préparation des applications Xamarin.Android
• Préparation des applications Xamarin.iOS
• Installation et configuration de TeamCity