TeamBuild 2010 : Les nouveautés des définitions de build 3

Comme je le disais dans mon précédent billet le moteur du serveur de build de TFS 2010 se base désormais sur Workflow Foundation 4.0. Je vous propose donc de faire une série de billet sur les nouveautés de TeamBuild 2010 en commençant par la création d’un build.

La définition des build a été enrichi en 2010 afin de proposer de nouvelles options et de s’intégrer avec le nouveau moteur. La définition d’un build se fait en 6 étapes :

1. Information sur la définition.
2. Déclenchement.
3. Workspace.
4. Paramètre par défaut du build.
5. Paramètre du workflow.
6. Politique de rétention.

La partie sur les informations ne change pas et propose toujours de nommer la définition et de fournir une description :

Le déclenchement des builds contient les options connues (Manuel, Intégration continue, Intégration continue avec accumulation et Planifiée) et une nouvelle « Gated Check-in »:

Comme indiqué dans la petite description, le « Gated Checkin » permet de rejeter toutes modifications qui mettraient en erreur le build. Mon prochain billet sera sur le « Gated Checkin » et les « Private builds » donc je ne vais pas m’attarder sur cette option.

Une fois le type de déclenchement spécifié, on retrouve l’écran de création du workspace qui sera utilisé lors du build :

L’écran suivant permet de spécifier les paramètres par défaut vis-à-vis du contrôleur de build, quel contrôleur utiliser et l’emplacement ou copier le résultat du build. Il s’agit d’un écran similaire à celui de TeamBuild 2008 sauf qu’on parle de contrôleur et non plus d’agent. (Pour la différence entre un contrôleur et un agent avec TeamBuild 2010, voir mon billet TeamBuild 2010 : Présentation de l’architecture) :

L’avant dernier écran est tout nouveau et permet de sélectionner et configurer le workflow qui sera utilisé. La partie haute permet de choisir le template de workflow :

A la création d’un TeamProject, 3 templates sont créés :

• Default Template : un template par défaut correspondant à ce que l’on avait en 2008 (avec des amélioration quand même ).
• Upgrade Template : un template permettant de lancer ces anciens script TeamBuild 2008.
• LabDefaultTemplate : un template pour l’utilisation de Test and Lab Management (compilation, mise en place d’un environnement des tests et exécution des tests).

La partie basse de l’écran permet de spécifier les paramètres à fournir au workflow sélectionné. Le contenu de cette partie est donc dépendant du workflow choisi :

C’est là la grande force de l’utilisation de Workflow Foundation, on définit un template générique et paramétrable que l’on va pouvoir réutiliser pour tous nos build qui utilise le même workflow. Le paramétrage pour chaque build se fait dans sa définition. De plus cette liste de paramètre n’est pas statique et se base sur le workflow et pour une partie de ces paramètres ce sont des valeurs par défaut qui sont spécifiées et qui pourront être surchargées lors du lancement d’un build manuellement.

Le dernier écran permet de spécifier la rétention des builds en fonction de son statut et de son type :

Les builds déclenchés et manuels sont les builds habituels, les builds privés sont des builds lancé par un développeur à partir d’une étagère et donc le résultat n’est pas et ne sera pas checkin (cela permet de vérifier son code dans l’environnement standard du serveur de build). En plus de l’ajout de la gestion des builds privés une autre option est apparue, pouvoir spécifier ce que la suppression d’un build entraine :

Il est maintenant possible de spécifier ce qui sera ou non supprimer avec le build de manière plus fine et ce pour chaque build et en fonction du statut du build.

Voila c’est tout pour la création d’une définition de build avec TeamBuild 2010 et c’est déjà pas mal La prochaine fois je vous parlerai plus en détail du concept de « Gated checkin » et « Private builds ».

Carpe Diem.