Les nouveautés de Team Build 2013

Les nouveautés de Team Build 2013

Microsoft a mis à disposition depuis quelque temps la preview de Team Foundtion Server 2013 et Visual Studio 2013. Vous pouvez télécharger cette preview à l’adresse suivante :

http://www.microsoft.com/en-us/download/details.aspx?id=39323

Dans ce billet je vous propose de voir ce qui a changé autour de Team Build. Attention les informations données ici sont basées sur une version Preview et sont donc susceptibles de changer dans la version finale.

Installation, configuration et suivi

L’architecture générale de la plateforme Team Foundation Build n’a pas évoluée avec cette nouvelle version. Nous avons donc toujours des agents de build liés à un contrôleur de build lui-même rattaché à une collection de projet. L’architecture n’ayant pas changé, les services n’ont pas non plus changé. Pour résumer, les éléments suivant n’ont pas évolué :

  • Le process d’installation
  • La configuration du service
  • La configuration du contrôleur
  • La configuration d’un agent
  • Les interfaces de suivi et gestion (Team Explorer et WebAccess)

Si l’infrastructure n’a pas changé, qu’elles motivations m’ont poussé à écrire ce billet ? :)

Templates de build

Les nouveautés viennent en fait des templates de build par défaut ainsi que des différentes activités utilisées par ceux-ci.

TfvcTemplate.12.xaml

Avec cette nouvelle version de TFS Microsoft a entièrement revu son template de build par défaut ainsi que les activités utilisées. Voici une capture d’écran du template dans l’éditeur de Visual Studio 2013 :

image

Comme vous pouvez le voir le workflow est bien plus compact et linéaire. Cela est dû par une simplification du workflow et une réécriture des activités afin d’intégrer une partie de la logique précédemment en place dans le workflow lui-même. On notera plus particulièrement les activités :

  • RunMsBuild qui prend maintenant en charge toute la partie boucle pour compiler pour différentes plateformes et configurations ;
  • RunAgileTestRunner qui prend maintenant en charge toute la partie recherche des assemblies de tests et exécution pour les différentes plateformes et configurations ;
  • RunPublishSymbols qui prend maintenant en charge toute la partie recherche des PDB, indexation et publication.

Une notre grande nouveauté dans ce template est l’apparition de l’activité RunScript et de sa mise en place avant et après la compilation et les tests. Cette nouvelle activité permet de lancer indifféremment une ligne de commande ou un script PowerShell. Afin de voir leur intégration, le plus simple est d’étudier les paramètres de ce nouveau workflow :

image

Le nombre de paramètre a lui aussi fortement diminué et des regroupements ont été fait ; l’ensemble des paramètres avancés pour la build et les tests sont dans des objets distinct permettant des simplifier l’organisation des paramètres.

On retrouve aussi les paramètres pour la nouvelle activité RunScript :

  • Pre-build script path et pre-build script arguments : permet de lancer un script avant la compilation de l’ensemble des solutions/projets définit pour l’ensemble des configurations et plateformes ;
  • Post-build script path et post-build script arguments : permet de lancer un script après la compilation de l’ensemble des solutions/projets définit pour l’ensemble des configurations et plateformes ;
  • Pre-test script path et pre-test script arguments : permet de lancer un script avant l’exécution de l’ensemble des tests définit pour l’ensemble des configurations et plateformes ;
  • Post-test script path et post-test script arguments : permet de lancer un script après l’exécution de l’ensemble des tests définit pour l’ensemble des configurations et plateformes ;

Cela amène une nouvelle manière de voir la personnalisation des workflow de build, plutôt que de personnaliser le workflow en XAML on va pouvoir se baser sur un tronc commun stable et créer des scripts pre et post action afin d’ajouter des comportements spécifique tel que l’organisation des binaires, la mise à jour des numéros de version ou encore l’exécution de compilations non supportées par MsBuild.

L’utilisation de script va aussi répondre à un besoin qu’on ne pouvait avoir avec la personnalisation du workflow : l’exécution d’une build sur une ancienne version des sources en utilisant la version du workflow de build de l’époque. En effet Team Build récupère toujours la dernière version du workflow de build quel que soit la version des sources que l’on compile ; hors la dernière version du workflow peut être incompatible avec l’organisation des sources dans une version antérieure. Avec l’utilisation de script, ceux-ci sont récupérés via la workspace définit dans la build définition dans la même version que le code source, on aura donc bien la version des scripts adaptée au code de l’époque.

Une autre nouveauté est le paramètre OutputLocation :

SNAGHTML6b998a9

Ce paramètre permet de définir la manière dont Team Build surcharge le paramètre OutDir :

  • SingleFolder : il s’agit de la valeur par défaut, tous les projets sont compilés avec un unique répertoire de sortie. Il s’agit du mode historique de Team Build.
  • PerProject : chaque solution/projet définit dans le paramètre Projects à son propre répertoire de sortie. Remplace le paramètre de 2012 “Solution Specific Build Outputs”.
  • AsConfigured : les projets sont compilés tel que définit en interne, il s’agit d’une compilation comme sur un poste de travail.

L’ajout de la valeur AsConfigured et du script post-build va enfin nous permettre de gérer comme on le souhaite l’organisation des binaires en sorties de build :) !

GitTemplate.12.xaml

Depuis quelque temps Team Foundation Service supporte un nouveau type de contrôleur de sources : Git (http://git-scm.com/about). Git est un système distribué contrairement au contrôleur de sources historique de TFS qui lui est centralisé. Le contrôleur de sources de TFS existe toujours et porte le nom de TFVC.

Avec la version 2013 de Team Foundation Sevrer, Microsoft propose Git pour les installations sur site. Cela a pour effet d’avoir un nouveau template de build ainsi qu’une interface de création de build différente :

image

L’onglet Source est mis à jour afin de proposer des paramètres spécifique à Git :

  • Le nom du répository
  • La branche à utiliser
  • Les branches à surveiller pour l’intégration continue

Au niveau du workflow de build, on retrouve un process identique à celui pour TFVC à l’exception de la récupération des sources qui utilise une activité spécifique pour Git :

image

Metadata

Pour ceux qui voudront personnaliser le workflow de build afin d’y rajouter des paramètres par exemple, sachez qu’il y a des nouveautés très intéressantes au niveau des meta-data :

image

Premièrement on peut voir que les paramètres de Microsoft apparaissent en standard dans les meta-data (c’est un gros plus si l’on souhaite les personnaliser).

Vous pouvez maintenant définir des meta-data pour chaque propriété d’un paramètre complexe en utilisant la syntaxe Parametre.Propriété.

Il existe maintenant une nouvelle syntax pour l’éditeur afin simplifier certain cas basique :

  • Afficher une liste de choix pour un paramètre de type string : @DropDownList=valeur1,valeur2,valeur3
  • Afficher/éditer un type simple : @Type=TimeSpan

Il est aussi possible de personnaliser le texte affiché pour les objets sans avoir à surcharger la méthode ToString de l’objet via le paramètre Value format string. On peut utiliser la syntaxe {Property} permettant d’afficher la valeur d’une propriété.

 

Voilà c’est tout pour ce billet. Je vous rappelle que ce billet est basé sur une version Preview de Team Foundation Server 2013 et que la version finale contiendra peut être plus de nouveautés ou que certains éléments décrit ici seront mis à jour.

Carpe Diem.

Leave a Reply

  

  

  

CAPTCHA *