Article tagué TeamBuild 2010

Un billet rapide pour vous indiquer que Mike vient de publier hier une nouvelle version stable des Community TFS Build Extensions. Au programme quelque corrections de bogues et nouvelles fonctionnalités.

Nous restons sur un planning de livraison tout les 2 ou 3 mois. Vos retours et suggestions sont les bienvenus ; vous pouvez utiliser le forum sur le site pour cela

Carpe Diem.

Je viens de publier la version 1.1 de mon activité pour TeamBuild 2010 permettant de mettre à jour les attributs de version d’un fichier AssemblyInfo. Cette nouvelle version apporte les modifications suivantes :

• Ajout du support de l’attribut AssemblyInformationalVersion avec les tokens suivant :
  • $(version) : la valeur de AssemblyVersion après mise à jour.
  • $(fileversion) : la valeur de AssemblyFileVersion après mise à jour.
  • $(date:<format>) : la date courante.
• Le niveau de log des messages de succès de mise à jour est passé de High à Normal.
• Ajout de la classe VersionSettings afin de regrouper les paramètres nécessaire à l’activité pour simplifier le paramétrage du workflow.

Le projet d’exemple de workflow a aussi été mis à jour pour utiliser la classe VersionSettings. Si vous avez des remarques, des bogues ou des demandes, n’hésitez pas à passer sur le forum ou saisir une issue sur codeplex.

Carpe Diem.

Comme promis je vais vous décrire un exemple d’utilisation de l’activité UpdateAssemblyInfo que j’ai publié sur codeplex.

Commençons d’abord par décrire ce que l’on attend :

1. Incrémenter le build number de mon AssemblyFileVersion automatiquement de tous les projets d’une solution lors d’une build. Les numéros de version majeure et mineure pour l’AssemblyVersion et l’AssemblyFileVersion doivent être constants et le numéro de révision doit être à 0.
2. Ne pas modifier les sources de la solution afin de laisser les développeurs faire ce qu’ils veulent.
3. Le BuildNumber de ma build doit contenir la valeur de AssemblyFileVersion afin que le nom de la build, le label et la drop location soient facilement identifiables.
4. Ne pas modifier les numéros de version pour les build de type gated-checkin et les build privées.
5. Pouvoir lancer une build en spécifiant qu’il ne faut pas mettre à jour les numéros de version.

Avant de mettre à jour notre template de build je vais configurer la solution pour rendre la mise à jour des versions pour l’ensemble des projets plus simple. Pour cela on ajoute un fichier GlobalAssemblyInfo.cs (ou .vb si vous faite du VB.Net) à la solution en tant que solution items :

Ce fichier va contenir l’ensemble des attributs au niveau assembly que nous voulons voir partager par tous nos projets :

using System.Reflection;

[assembly: AssemblyDescription("Sample project for UpdateAssemblyInfo activity.")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("Qetza")]
[assembly: AssemblyProduct("UpdateAssemblyInfoSample")]
[assembly: AssemblyCopyright("Copyright © Guillaume Rouchon 2010")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

Dans le cas présent nous partageons l’ensemble des attributs décrivant l’assembly à l’exception du titre (AssemblyTitle) et bien entendu les versions d’assembly et de fichier. Il ne reste plus qu’à modifier les projets pour utiliser ce fichier. Pour cela, pour chaque projet on va rajouter ce fichier en tant que lien :

Il est important d’ajouter le fichier en lien afin de ne pas le dupliquer ! Il faut ensuite modifier les fichiers AssemblyInfo.cs des projets afin de supprimer les attributs en doublon. Voila notre solution est prête.

Il est maintenant temps de personnaliser notre template de build. Pour cela le plus simple est de :

1. Créer un projet de type Workflow/ActivityLibrary.
2. Mettre à jour le Framework visé en spécifiant .Net Framework 4.
3. Ajouter les références suivantes :
   • Depuis C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies
     • Microsoft.TeamFoundation.Build.Workflow.dll
     • Microsoft.TeamFoundation.TestImpact.BuildIntegration.dll
   • Depuis C:\Windows\assembly\GAC_MSIL\Microsoft.TeamFoundation.TestImpact.Client\10.0.0.0__b03f5f7f11d50a3a
     • Microsoft.TeamFoundation.TestImpact.Client.dll
   • Qetza.TeamFoundation.Build.UpdateAssemblyInfo.dll
   • Microsoft.TeamFoundation.Build.Client.dll
   • Microsoft.TeamFoundation.VersionControl.Client.dll
   • Microsoft.TeamFoundation.WorkItemTracking.Client.dll
   • System.Drawing.
4. Supprimer l’activité par défaut.
5. Ajouter une copie du fichier DefaultTemplate.xaml au projet.

Nous sommes maintenant près à personnaliser le template afin d’y ajouter la mise à jour des numéros de version. Voyons comment le faire en répondant aux exigences définit au début du billet :

1. L’exigence 1 nous précise comment doivent être mis à jour les numéros de version. Pour répondre à cette exigence nous passerons à l’activité UpdateAssemblyInfo les paramètres suivants :
   • AssemblyVersionFormat : “$(current).$(current).0.0″
   • AssemblyFileVersionFormat : “$(current).$(current).$(increment).0″
2. Afin que le numéro de build soit incrémenté à chaque build, il va falloir stocker quelque part le dernier numéro utilisé. L’exigence 2 nous apporte une contrainte, nous ne pouvons pas utiliser le fichier GlobalAssemblyInfo de la solution car la build ne doit modifier les sources. Le plus simple est donc de stocker une copier du fichier GlobalAssemblyInfo qui sera utilisé uniquement lors de la build. TeamBuild 2010 ne fournissant pas d’activité permettant de faire un check-in le plus simple est de garder ce fichier sur un partage réseau. Il faudra faire attention à ce que le compte de build est les droits de lecture et d’écriture sur ce fichier.
3. L’exigence 3 va nous imposer l’endroit où nous allons personnaliser notre template. En effet si nous voulons respecter cette exigence nous allons devoir mettre à jour les numéros de versions avant la mise à jour du BuildNumber, le label et la drop location étant dépendant de cette valeur.
4. Pour l’exigence 4 il faudra utiliser des séquences de type InvokeForReason et les paramétrer sur la raison Triggered.
5. Enfin pour l’exigence 5 il faudra ajouter des If basé sur un paramètre du workflow.

Avant de modifier le workflow il nous faut définir les paramètres suivant au niveau du workflow afin de le configurer pour chaque BuildDefinition :

• AssemblyVersionFormat : le format de mise à jour du numéro d’assembly.
• AssemblyFileVersionFormat : le format de mise à jour du numéro de fichier.
• AssemblyInfoFilePattern : le pattern de recherche utilisé pour trouver les fichiers à mettre à jour.

Il va aussi nous falloir des variables :

• UpdateAssemblyInfo : un booléen qui indiquera s’il faut ou non faire du versionning. Il sera paramétré en fonction de la valeur de AssemblyInfoFilePattern, si celui-ci est vide on ne fera pas de versionning.
• AssemblyInfoFiles : pour stocker les fichiers à mettre à jour.
• MaxAssemblyVersion : pour stocker le numéro max d’assembly après mise à jour.
• MaxAssemblyFileVersion : pour stocker le numéro max de fichier après mise à jour.

Nous devons donc ajouter le workflow suivant :

• If UpdateAssemblyInfo
  • Then
    • InvokeForReason Triggered
      • FindMatchingFile AssemblyInfoFilePattern
      • UpdateAssemblyInfo
      • Assign BuildNumberFormat = “$(BuildDefinitionName)_v” + MaxAssemblyFileVersion

Ce workflow est à ajouter juste avant la séquence “Update Drop Location” :

Avec ce workflow nous avons mis à jour notre fichier GlobalAssemblyInfo et avons personnalisé le BuildNumber et par conséquent le label et la drop location. Mais il faut encore faire une modification au template. En effet pour l’instant la compilation de la solution ne prendra pas en compte notre fichier. Il va donc falloir modifier la partie sur le BuildAgent pour écraser le fichier GlobalAssemblyInfo de la solution après l’avoir récupéré de TFS mais avant de compiler :

• If UpdateAssemblyInfo
  • Then
    • InvokeForReason Triggered
      • CopyDirectory Path.GetDirectoryName(AssemblyInfoFilePattern) to SourcesDirectory

Ce workflow est à ajouter avant le “If CreateLabel” :

Voila nous avons maintenant un template qui utilise l’activité UpdateAssemblyInfo afin de mettre à jour les numéros de version automatiquement.

Afin de faire ressortir le versionning nous allons modifier le paramètre Metadata du workflow pour ajouter nos paramètres dans une catégorie “versionning” :

Notre template est maintenant fini, il ne reste plus qu’à tout mettre dans TFS :

• Ajoutez le template en remplaçant le DefaultTemplate.xaml ou ajoutez-le sous un nouveau nom.
• Ajoutez l’activité Qetza.TeamFoundation.Build.UpdateAssemblyInfo.dll dans TFS pour que le process de build y ait accès. (par exemple dans BuildProcessTemplate/CustomActivities).
• Mettez à jour le build controller afin de lui indiquer le répertoire dans TFS ou se trouve les activités personnalisées :

Et voilà, il ne reste plus qu’à définir une BuildDefinition sur un projet et lancer la build. Lors du lancement d’une build il est possible de surcharger les valeurs par défaut (par exemple pour forcer un changement de version majeure ou mineure) :

Et voilà le résultat :

Maintenant c’est à vous de mettre en place vos politiques de versionning et d’intégrer tout cela dans TeamBuild 2010 !

Carpe Diem.

Vous retrouverez la solution que j’ai utilisée pour ce billet à l’adresse http://blog.qetza.net/wp-content/uploads/2010/08/UpdateAssemblyInfo_v1.0.1.0_Sample.zip.