TeamBuild 2010 : Présentation de l’architecture 1

Dans la version 2010 de TFS, TeamBuild a été entièrement revu. Le moteur est passé sous Workflow Foundation 4.0 et l’architecture des services est maintenant distribuée. Dans ce billet je vais vous présenter cette nouvelle architecture qui apporte beaucoup plus de souplesse.

TeamBuild 2010 est composé de deux composants liés aux Team Project Collections :

Le BuildController est lié à une collection (mais une collection peut avoir plusieurs BuildController) et s’occupe de toutes les tâches ne sollicitant pas de manière intensive le processeur ou le disque :

• La mise à jour du numéro de build.
• La création du répertoire de drop.
• Le choix d’un BuildAgent.
• L’exécution du build sur le BuildAgent.
• Le checkin du shelveset dans le cas d’un build en Gated Checkin.

Le BuildAgent est lié à un BuildController et s’occupe de toutes les tâches qui ne sont pas faites par le contrôleur :

• Création du workspace.
• Récupération des sources.
• Pose du label.
• Compilation.
• Tests.
• Liens avec les changesets.
• Publication des symboles.

Comme le montre le schéma, un BuildController peut avoir plusieurs BuildAgent associés ce qui permet d’avoir enfin de la répartition de charge de manière native En plus les BuildAgent peuvent être taggué afin de différencier des configuration de build et une définition de build pourra indiquer un ensemble de tag que devra avoir le BuildAgent.
Un exemple simple : vous installez sur une machine de build BizTalk afin de l’utiliser pour vos build de projet BizTalk. Il suffit alors de tagguer le ou les BuildAgent déployés sur ce serveur avec « biztalk » (par exemple) et d’indiquer dans les définitions de build des projets BizTalk qu’il faut obligatoirement utiliser un BuildAgent avec le tag « biztalk ». Le BuildController se chargera de trouver le bon BuildAgent libre

D’un point de vu physique, tous les composants ne doivent pas forcement être sur la même machine, chaque composant peut être sur une machine différente. La seul contrainte est qu’il ne peut y avoir qu’un BuildController par machine. Voila un petit exemple de déploiement :

Dans cette exemple chaque collection possède un BuildController :

• Le BuildController de la collection A est physiquement sur une autre machine avec ses deux BuildAgent associés.
• Le BuildController de la collection B est sur la même machine que la couche applicative de TFS mais ces deux BuildAgent sont sur deux machines différentes. Un des BuildAgent à un tag « biztalk » et est donc sur une machine configurée pour gérer les projets BizTalk.

Enfin, l’ensemble de la configuration des BuildController et BuildAgent est sauvée au niveau de TFS.

Je n’aurais que trois mots pour conclure : QUE DU BON

Carpe Diem.