Petit rappel des faits

Ceux qui ont survécu à TFS 2008 savent de quoi je parle, l’administration des Builds sous l’ancien gestionnaire de source de Microsoft nous a tous conduit à faire des cauchemars où on se faisait dévorer par un compilateur aux dents aiguisées puis digéré pour au final être abandonnés dans un coin au format XML ! Petit exemple en image pour les veinard qui n'ont pas connu !

Je pars du principe que vous avez déjà installé TFS mais dans le cas contraire n'hesitez pas a me contacter l'installation est plutot simple mais on ne sait jamais..

Une build pour du code personnel, pourquoi pas !

Lorsque vous êtes développeur, vous développez tout le temps, chez vous, dans le train, au bureau, en mangeant, en dormant, etc., pour en arriver toujours au même point. 250 Projets, qui courent votre site web personnel à votre mediatec en passant par votre maison (nous aurons l’occasion d’en reparler). Lorsqu’on est développeur, ceux sur quoi on veut passer du temps c'est du developpement, hors la compilation est souvent la tâche ingrate : il faut s’occuper du déploiement, de la configuration, des tests unitaires, etc., ET TOUS CA, BAH CA FAIT PERDRE DU TEMPS ! D’où la nécessité de la machine de Build. La machine de Build va tout faire pour vous : la compilation selon un ordre donné, le lancement de la campagne de test unitaire, le déploiement selon plusieurs modes... Ce que je vais tenter de vous expliquer ici est surtout comment vous allez pouvoir modifier un processus de « Build » sous TFS 2010 en utilisant Workflow Foundation.

Création d’une nouvelle définition de Build

Devant commencer quelque part, commençons par créer notre première Build. Dans l’onglet « Team Explorer » allez dans l’item « Build », faites un clic droit et créez une nouvelle définition de build. Nous allons maintenant configurer cette définition. Elle se présente de plusieurs onglets.

Le Workflow de base

Comme vous l’avez vu plus haut dans la configuration de la Build, quand nous avons défini les paramètres liés au processus de build nous avons utilisé des Workflow déjà existants qui nous ont permis de définir des variables pour paramétrer notre Build. Commençons par aller jeter un coup d’œil rapide sur la chose ! Pour ouvrir le WorkFlow vous avez deux solutions.

1. Vous allez le chercher directement dans le contrôle de source.
2. Vous retourner sur votre build dans processus et vous avez un lien qui vous y amène tout droit.

Modifier votre processus

La chose la plus importante à faire quand vous allez modifier un Workflow est de vous poser la question suivante : que vais-je lui faire faire ? Ici les modifications que nous allons apporter à notre processus sont les suivantes :

• Supprimer les fichiers d’un répertoire local & réseau.
• Puis nous allons copier les binaires de notre fraîche compilation vers ces répertoires.

Dans cet exemple l’utilisateur aura donc besoin de donner au processus deux informations supplémentaires : le répertoire, l’adresse complète du répertoire local et celle du répertoire réseau. Nous allons donc créer les arguments qui vont nous permettre de renseigner ces informations.

Maintenant nous allons également modifier les métas donnés pour que l’utilisateur puisse avoir des informations sur ces nouveaux arguments. Si vous vous savez à quoi ils servent viendra le jour où vous ferez ces modifications pour d’autres personnes. Il conviendra donc de documenter un peu vos modifications.

Côté Workflow, nous allons créer une séquence principale, à laquelle nous ajoutons deux sous- séquences. Pour chacune de ces séquences nous ajoutons le contrôle « Delete Directory » et « Copy Directory »

Ok, mais tous ça pour aller où ?

Sauvegardez votre travail, et retournez sur l’écran de configuration de votre build (Sélectionnez votre Build et modifiez-la.) Allez directement dans l’onglet processus. Vous voyez les nouvelles sections que nous avons créées. Le travail effectué sur les Arguments & Meta donnés prend ici tout son sens.

Et maintenant ?

Je suis tenté de dire que toutes tâches manuelles effectuées sur vos projets, fichiers, etc., en pré build et post build, devraient être déléguées à votre WorkFlow de build. Après tout, pourquoi le faire soi-même quand l’ordinateur peut s’en charger ? Si vous souhaitez aller plus loin n’hésitez pas à me contacter via mon site web, si vous avez des idées sur des sujets que vous souhaitez voir aborder prochainement.