TFS 2015: Customisation des activités de build (part1)

Auteur original, de notre ancien blog : Laurent Jacques

tfs9

Aujourd’hui nous allons discuter de la customisation des activités de build avec TFS 2015. En effet, alors que dans un prochain billet j’aborderai le tout nouveau système de build vNext ; il me semblait important de souligner une des (nombreuses) possibilités de customisation du mécanisme existant. Etant donné le volume d’étapes je présenterai la customatisation en 2 parties : 

  1. la création d’un nouvelle activité de build,
  2. l’intégration du workflow dans la définition de build.
PART1 : Création d’une nouvelle activité de build.

Qu’est-ce qu’une activité de build ?

Lors de la création d’une nouvelle build, le processus de génération est défini suivant le modèle de processus choisi (workflow template).

Des processus couvrant la plupart des cas d’utilisation sont fournis dans Team Foundation Server.

Il est aussi possible de créer son propre processus en fonction de ses besoins, en le constituant d’activités custom ou non.

Une activité de build n’est, en apparence, rien d’autre qu’une série de paramètres que l’on peut regrouper par thème.

tfs10

Sous le capot: à chaque bloc correspond un applicatif complet capable d’assurer l’ensemble de vos besoins… pour peu qu’on la développe.

Mise en oeuvre

Création de la solution et du projet hôte.

Il nous faut créer un nouveau projet, le type à choisir est : Bibliothèque d’activités
tfs11

Une fois le projet créé:  ajoutons le au contrôle de source. Ce détail à son importance, nous en reparlerons par la suite.
Pour les besoins de la démonstration, l’activité que nous créerons sera un simple envoi de mail…rien de follement excitant en somme mais nous allons poser les bases pour la réalisation de grandes choses.

 

Ajout du processus.

Il est nécessaire d’ajouter le processus que nous allons adapter. Comme je l’indiquai tous les processus par défaut sont disponibles et téléchargeables depuis Visual Studio.

Il faut donc récupérer celui qui nous servira de modèle en accédant à l’interface de build : soit par la création d’une nouvelle définition, soit par la modification d’une définition existante.

Un clic sur le lien Télécharger vous permettra de récupérer le fichier correspondant. Un conseil, prenez celui qui vous demandera le moins d’adaptation.

Pour notre exemple le modèle par défaut suffit largement à la tâche.

Sauvegardez-le dans votre projet, en renommant le fichier selon le nom que vous souhaiterez donner à votre processus custom.

Pensez à ajouter ce nouveau fichier dans votre solution VS.

 

A présent : nous nous retrouvons avec tous les éléments permettant de développer notre propre activité et de la mettre à disposition dans le serveur TFS.

Développons notre activité

Il faut ajouter une nouvelle classe à notre projet:

tfs14

Pour être considérée comme « Activité » par le processus TFS, la classe doit hériter de CodeActivity. Ce qui est fait par défaut par VS.

Et ensuite rien de plus simple 😉

Il s’agit de procéder au développement de l’application… On peut imaginer que cette classe soit plus complexe ou s’appuie sur n’importe quel service externe / interne, ou autre.

Pour cette démo voici le contenu de la classe :

tfs15

ici l’objectif de cette classe serait de générer un hypothétique fichier de Release note.

J’ai aussi crée une seconde classe d’activité pour gérer l’envoi de mail :

tfs16

En lecteurs assidus et codeurs chevronnés, vous noterez que ces classes ne font en fait rien du tout.. et vous avez donc bien vu. Elles ne sont la que pour illustrer les possibilités.. et non réaliser un vrai développement.

A noter :

InArgument<string>

OutArgument<bool>

Ces types de données permettent de définir les entrées sorties de la classe,ainsi, dans la classe GenerateReleaseNote, il y a :

1 argument en entrée ProjectName qui devra donc être paramétré lors de l’intégration de l’activité dans le workflow.

1 argument de sortie ReleaseNotePath qui pourra donc être lu après l’exécution de l’activité.

 

S’en est terminé de cette première partie. Dans la prochaine partie, nous verrons la mise au point du workflow, le paramétrage des entrées / sorties et l’intégration dans la définition de build.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s