Je travaille depuis quelque temps sur un projet WPF. Mon client nous met à disposition un automate d’intégration continu sur lequel nous n’avons pas la main en terme de customisation.
Ce dernier permet d’effectuer des étapes importantes telle que l’exécution de tests unitaires, couverture de code, vérification de la qualité de code, … cependant certaines étapes à mon sens sont manquantes.
Dans cet article je vais vous présenter un exemple de processus automatisé que j’utilise en complément qui me permet de sécuriser la livraison de l’application en environnement de test.
Je pars du postulat que sur mon poste de développement, seulement le framework .net et Visual Studio 2010 sont installés.
L’idée est de créer ce script le plus vite possible avec les outils en ma possession
=>Je vais donc créer un script MSBuild
Le script est structuré en sept étapes:
Ces targets permettent de réccupérer la dernière version du code et de faire un check-in du code modifié par ce processus. A ce niveau là tout dépend de votre gestionnaire de configuration.
Si vous utilisez Microsoft Team Foundation Server les Tasks sont disponibleq dans Microsoft.TeamFoundation.Build.targets (C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild pour une machine x64).
Sinon, pour les autres gestionnaires de configuration, il suffit d’obtenir des tasks tier:
Incrémente automatiquement le numéro de version des composants de la solution;
Soit une Custom Task peut être créée, soit les MSBuild Community Tasks offrent une tâche qui permet de modifier le fichier Assemblyinfo.
Nettoyage du bin des projets de la solutions. Tous les répertoires bin/debug et bin/release sont nettoyés avec la task suivante:
Cette simple target compile la solution dans la configuration définie:
La target Deploy copie les fichiers, présents dans le projet de démarrage de la solution, dans le répertoire de destination. Si le répertoire n’existe pas il est créé.
A ce niveau là, j’ai créé une custom task qui, à partir d’un fichier Xml, vérifie les fichiers déposés dans le répertoire de livraison.
Cette custom task vérifie:
Dans la partie suivante de ce post, je vais rentrer en détail sur la façon de faire une Custom Task MSBuild.
Dans ce script, deux patterns MSBuild sont vraiment intéressants:
Pour démarrer ce script, ouvrez le Visual Studio Command Prompt (2010) pour avoir MSBuild dans le path.
Naviguez jusqu’à votre fichier proj MyBuild.proj, lancez la ligne de commande suivante:
msbuild MyBuild.proj /p:Version=1.0.0.24
Cette ligne de commande lance le processus pour la version 1.0.0.24, la compilation est faite en release.
Créez un projet de classe de librairie nommé par exemple MyCustomTaskMSBuild.
Ajouter les références aux dlls Microsoft.Build.Framework.dll:
Renommez la classe Class1.cs en MyCustomTask.cs et faites la hériter de l’interface ITask.
Ensuite, à vous de jouer, après avoir surchargé les méthodes/propriétés de ITask, vous pouvez créer un code celui-ci:
Pour tout ce qui est logging de messages, utilisez la méthode Trace.
J’ai rajouté un MyInputParam, avec l’attribut Required il devient obligatoire lors de l’exécution du script MSBuild.
En entête du fichier proj, rajoutez la ligne suivante:
Cette ligne défini le lien avec la Custom Task, il suffit ensuite d’appeller cette Task dans une target comme suit:
Et maintenant, testez:
Ensuite, en vie réelle, vérifiez que le ficher proj est dans le même répertoire que la dll de la Custom Task.
Pour debugger cetteTask, forcez le projet MyCustomTaskMSBuild à Startup Project.
Etre sûr que le fichier proj est bien dans le répertoire bin\debug du projet MyCustomTaskMSBuild.
Dans l’onglet Debug des propriétés de ce projet. Sélectionner Start exsternal program et pointez vers l’exécutable MSBuild, dans mon cas C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
Dans les Command Line Arguments, il suffit de mettre le nom du fichier MSBuild avec les bons paramètres.
F5 et le debug peut commencer.
Documentation MSBuild sur MSDN :
Blog de l’équipe MSBuild
- Benoît Sarie -