Archives par étiquette : TFS

[Tips] Erreur ANDROID_HOME is not set lors du zipalign d’un package Xamarin Android

Dans la série des erreurs que vous pouvez rencontrer lors de la mise en place d’une build Xamarin Android, après : [Tips] No agent could be found with the following capabilities AndroidSDK, MSBuild, Xamarin.Android, JDK puis, [Tips] Signature package Xamarin Android en erreur : jarsigner failed ENOENT

Le nouvel épisode concerne la tâche de zipalign indispensable l’optimisation de vos packages et pour s’assurer du bon fonctionnement de vos applications sur les devices.

Lors de l’activation de cette tâche sur votre processus de build vous pouvez vous retrouver avec l’erreur suivante :

##[error]ANDROID_HOME is not set
##[error]Return code: 1

image

Vous l’aurez vite compris, il est ici nécessaire de créer une nouvelle variable d’environnement nommée ANDROID_HOME contenant le chemin du SDK d’Android (ex : C:\Program Files (x86)\Android\android-sdk). Redémarrez ensuite les agents de build pour que la modification soit prise en compte.

A bientôt pour une nouvelle erreur Xamarin Smile

[Tips] Signature package Xamarin Android en erreur : jarsigner failed ENOENT

Lors de la mise en place d’une build Xamarin Android avec Team Foundation Server, vous pouvez vous retrouver avec une erreur lors de l’étape de Signature de votre package.

Une erreur “jarsigner failed. spawn jarsigner ENOENT” peut être levée.

En version détaillée dans mon cas :

##[error]Error: C:\Program Files\Microsoft Team Foundation Server 15.0\Search\Java\jre1.8.0_111\bin\jarsigner failed. spawn C:\Program Files\Microsoft Team Foundation Server 15.0\Search\Java\jre1.8.0_111\bin\jarsigner ENOENT

image

Comme l’indique l’erreur ENOENT, quelqu’un manque à l’appel, et dans le cas présent c’est tout simplement le jarsigner.exe qui est absent du dossier dans lequel TFS recherche l’outil de signature de package java.

TFS cherche en effet étrangement cet outil dans l’environnement java installé avec Code Search, la nouvelle fonctionnalité de TFS qui permet d’indexer le code présent dans les repositories et d’effectuer des recherches. Cet environnement ne comprenant pas l’outil jarsigner, toute signature est impossible depuis vos builds.

Vous pouvez donc rencontrer un conflit entre la fonctionnalité Code Search et les tâches de signature de Xamarin Android.

Pour corriger le problème, vous devez modifier la variable d’environnement JAVA_HOME afin de l’uniformiser avec vos autres variables liées à Java, dans mon cas :

image

Redémarrez ensuite les services windows correspondant à vos agents de builds afin que cette modification soit prise en compte.

[Tips] Arrêter une collection TFS afin d’indiquer un message de coupure de service

Si après une migration de votre serveur TFS “On Prem” vers une nouvelle machine (et si vous n’utilisez malheureusement pas d’alias DNS pour accéder à celui-ci) et que vous souhaitez ne pas couper brutalement votre serveur TFS et ainsi laisser l’équipe avec des messages d’erreur bizarres s’ils ouvrent des projets mappés avec l’ancien serveur, vous pouvez utiliser une fonctionnalité de TFS : l’arrêt de collection.

Ainsi même si vous n’utilisez qu’une seule collection de Team Projects vous pouvez tout à fait l’arrêter via la console d’administration de TFS :

image

Lorsque vous l’arrêtez vous pouvez saisir un message d’information à destination de tous les utilisateurs de cette collection :

image

Ce message est alors repris dans Visual Studio lorsque vous connectez au Team project, mais surtout également depuis le Team Explorer pour chaque action effectuant un accès serveur à la collection :

image

Bye, bye les builds XAML !

C’est enfin officiel, nous avons à présent le planning définitif de l’arrêt du support des builds XAML au sein de Team Foundation Server et de Visual Studio Team Services.

Comme vous le savez, Microsoft a ajouté à partir de TFS 2015, une refonte complète du moteur de build serveur intégré à TFS, afin de ne plus utiliser celui basé sur les définitions de builds construites en XAML.

image

L’idée était simple : proposer un système de build beaucoup plus simple à personnaliser, extensible, et multi-plateforme.

Alors que les deux systèmes cohabitent encore jusqu’à aujourd’hui, Microsoft vient de publier le planning de l’arrêt du support des builds XAML. Tenez en bien compte pour migrer l’ensemble de vos définitions de builds si ce n’est pas encore fait !

En résumé pour Team Foundation Server (On-Premise) :

  • Dans TFS 2017, possible d’utiliser des builds XAML en utilisant un agent de build TFS 2015,  TFS 2017 n’étant pas livré avec un agent compatible
  • Dans la prochaine version majeure, plus de support des builds XAML, ni en intégré, ni via un agent TFS 2015

En résumé pour Visual Studio Team Services :

  • Arrêt du support des agents XAML au 1er Juillet 2017, si vous souhaitez utiliser des builds XAML à partir de cette date vous devrez installer votre propre serveur de builds privé.
  • Fin 2018, arrêt total du supports des builds XAML

Pour plus d’infos :  https://blogs.msdn.microsoft.com/bharry/2017/05/30/evolving-tfsteam-services-build-automation-capabilities/

Dépasser les limites de planification de Team Build

Team Build permet de planifier le déclenchement de Builds via un scheduler assez basique :

image

Nous avons la possibilité de planifier à intervalles régulier le déclenchement d’une build selon deux critères : le jour et l’heure.

Impossible donc de planifier depuis cette interface une build afin qu’elle soit déclenchée toutes les deux heures, toutes les demi-journées ou selon des critères plus complexes.

Afin de pouvoir déclencher une build à sa guise il est donc nécessaire d’utiliser une technique. Il est par exemple possible de lancer un build grâce au SDK de TFS, grâce aux services web, ou aux API REST, mais encore plus simplement via l’outil en ligne de commande TFSBuild.exe.

Il est donc possible de programmer vos builds comme vous le souhaitez grâce aux tâches planifiées proposées par Windows !

Exemple de commande :

« C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\TFSBuild.exe » start https://moncompte.visualstudio.com/DefaultCollection TeamProject NomDefinitionBuild /queue

La solution la plus simple pour définir la version des assemblys générées

Que cela soit pour la maintenance technique ou même pour le support fonctionnel d’un produit, il est souvent important d’être capable d’identifier la version d’une application en cours d’exécution.

Ce numéro de version est souvent défini avec la structure suivante :

Major.Minor.Build.Revision

Pour ma part, j’ai opté pour le nommage suivant :

Année.Mois.Jour.Revision

D’un point de vue technique, il existe plusieurs techniques pour définir le numéro de version des assemblys :

  • Modification Manuelle des fichiers AssemblyInfo (il n’y a donc rien d’automatique)
  • Modification des fichiers AssemblyInfo via une activité MSBuild ou une Activité Workflow Foundation, et pourquoi pas checkin de la modification pour que le source control reflète bien le numéro de version
  • Modification des fichiers AssemblyInfo via un script en pre-build

Et sur cette dernière solution que je vais m’attarder aujourd’hui car elle est très simple à mettre en oeuvre ! Vous pouvez en effet appliquer un numéro de Version à toutes les assemblies que vous compilez en moins de 10 minutes de mise en oeuvre grâce à cette méthode.

L’idée est simple, comme la plupart des systèmes de builds, TFS vous permet d’appeler des scripts batch ou powershell en action pre-build ou post-build.

Dans notre cas, nous allons exécuter un script Powershell qui va effectuer la modification des fichiers AssemblyInfo récupéré via un Get par le processus de Build, fichiers qui une fois modifiés seront compilés de manière traditionnelle.

Afin de récupérer les informations du numéro de Version à injecter, ce script va récupérer quelques variables d’environnement fournis par TFS.

1ère Etape : Mise à disposition du script d’injection de numéro de Version

J’ai indiqué que cette solution était simple et rapide à mettre en oeuvre pour une raison simple : il existe un script Powershell d’injection du numéro de Version prêt à l’emploi et fourni par des MVPs ALM à cet emplacement : https://github.com/tfsbuildextensions/CustomActivities/blob/master/Source/Scripts/ApplyVersionToAssemblies.ps1

Télécharger ce fichier, et faites un checkin de ce fichier dans un dossier sur votre source control afin qu’il soit disponible par votre serveur de build.

2ème Etape : Paramétrage de votre définition de Build

Et enfin dernière étape, rendez vous dans le paramétrage de votre définition de build, et plus précisément dans le paramétrage du process, définissez votre script en pre-build et définissez le format de numéro de version souhaité.

image

Et c’est terminé, lors de votre prochaine Build vous pourrez constater que vos assemblys possèdent bien le numéro de version souhaité.