Build personnalisable : utiliser NAnt avec TeamBuild

Le processus de build en Workflow foundation est très puissant mais il n’est pas adapté à de la personnalisation solution par solution. Dans ce cas là on arrive finalement à avoir un process de build pour chaque solution à compiler, et comme il manque de lisibilité, on est vite perdu.

Changer le process de Build

Une solution est de modifier le process de build pour, non pas écrire des activités spécifiques à une solution, mais pour avoir la capacité de brancher des opérations spécifiques à chaque solution. Le process de build reste ainsi générique. Pour ce billet, j’ai choisi d’utiliser NAnt, mais on aurait pu tout aussi bien utiliser powershell.

L’idée est la suivante: pour une solution donnée, je veux pouvoir avoir la possibilité d’éxecuter après la compilation un script NAnt pour me permettre d’effectuer des opérations particulières (copies de fichiers, minification de javascripts, création de zip…) Je vais donc partir sur un paramétrage par convention qui ne permettra d’éviter de paramétrer la build: si pour une solution foo.sln, il existe un script foo.build, je demande à NAnt de l’exécuter. Je vais aussi passer des paramètres spécifiques à NAnt comme le chemin vers la solution, ainsi que la sortie de compilation.

Pour cela je vais utiliser les tâches NAnt qui se trouvent ici: http://tfsbuildextensions.codeplex.com.

Première étape: identifier l’endroit dans le workflow de build où est compilée la solution. Elle se situe dans la séquence “try to compile the project” :

L’activité MSBuild utilise une variable localProject qui contient le chemin vers la solution. Nous allons nous en servir pour trouver le chemin vers notre script Nant. Le chemin vers le script NAnt va être stocké dans une variable localNAnt :

Une fois la variable créée, il suffit de tester si le fichier existe pour savoir si l’on doit exécuter NAnt :

Ensuite, on ajoute les variables qui nous intéressent: solution.path pour le chemin de la solution (le fichier sln lui-même) et solution.output pour le chemin vers la sortie de compilation de la solution :

Et :

Dernière étape: la création d’un fichier de log pour la sortie de build :

Tout est prêt pour appeler la tâche Nant :

Si l’on regarde le paramétrage de la tâche, je considère que Nant se trouve dans la variable d’environnement “%NantDirectory%” sur le serveur de build. Une fois la build lancée sur une solution, on obtient le log suivant dans la sortie de build (le script NAnt ne fait qu’afficher les paramètres):

Buildfile: file:///C:/Builds/1/Scrum/MonApp/src/MonApp/MonApp.build
Target framework: Microsoft .NET Framework 4.0
Target(s) specified: main_target

main_target:

     [echo] Solution: C:\Builds\1\Scrum\MonApp\src\MonApp\MonApp.sln
[echo] Output: C:\Builds\1\Scrum\MonApp\bin

BUILD SUCCEEDED

Total time: 0.1 seconds.

La conclusion de ce genre de modification est qu’il est tout à fait possible de modifier le process de build pour y injecter des comportements. C’est même, sur le long terme, plus efficace que de créer un processus par solution car dans mon cas, il n’y a qu’un seul process de build à faire évoluer.

Le source du billet (application vide de démo + build process template + programme d’édition) est sur GitHub: https://github.com/Cellenza/BLOG-NantAndTeamBuild.

@+