Article tagué Workflow Foundation 4.0

Ce billet fait parti d’une série sur TeamBuild 2010 :

• TeamBuild 2010 : Présentation de l’architecture
• TeamBuild 2010 : Les nouveautés des définitions de build
• TeamBuild 2010 : Gated Check-in et Private Build

Il est temps de reprendre un peu ma présentation des nouveautés de TeamBuild 2010

TeamBuild étant maintenant basé sur Workflow Foundation 4.0, Microsoft propose de base un ensemble d’activités écrites spécifiquement pour TeamBuild. Ces activités correspondent grosso-modo aux tâches qui existaient pour TeamBuild 2008 :

Comme on peut le voir sur la capture d’écran précédente ces activités sont divisées en deux catégories : celles pour la build et celles pour LabManagement. Dans ce billet je ne parlerai que de la première catégorie.

Les premières activités à connaître sont les activités permettant de définir des séquences :

• AgentScope
• InvokeForReason
• SharedResourceScope

Comme je l’ai expliqué dans le premier billet de cette série le processus de build est exécuté en partie sur le contrôleur de build et en partie sur l’agent de build, la séquence AgentScope permet tout simplement d’indiquer au moteur de build que ses activités devront être exécutées sur l’agent de build. La séquence InvokeForReason permet de spécifier un ensemble d’activités qui ne devront être exécutées qu’en fonction du type de build actuellement en cours. Pour cela l’activité InvokeForReason possède un paramètre de type énumération acceptant une ou plusieurs valeurs parmi les suivantes permettant d’indiquer pour quel type de build elle sera exéctuée :

• None : la séquence n’est jamais exécutée.
• All : la séquence est toujours exécutée.
• BatchedCI : pour une build configurée en “Rolling build” (intégration continue avec accumulation des builds).
• CheckInShelveset : pour une build configurée en “Gated Check-in” (build d’un shelveset avant checkin).
• IndividualCI : pour une build configurée en “Continuous Integration” (build à chaque checkin).
• Manual : pour une build configurée en “Manual”.
• Schedule : pour une build configurée en “Schedule” et qui a été déclenché car un changement a eu lieu.
• ScheduleForce : pour une build configurée en “Schedule” et qui a été déclenché alors qu’aucun changement n’a eu lieu.
• Triggered : regroupe les types BatchedCI, CheckInShelveset, IndividualCI, Manual, Schedule, ScheduleForce et UserCreated.
• UserCreated : j’avoue que je n’ai pas encore trouvé comment obtenir ce type de build
• ValidateShelveset : pour une build configurée autrement qu’en “Gated Check-in”, lancée manuellement en spécifiant un shelveset. Il s’agit des Private build.

La dernière séquence, SharedResourceScope, permet d’exécuter une séquence d’activité de manière synchrone par rapport à une ressource. Il s’agit d’un équivalent au lock de csharp afin de synchroniser l’accès à une ressource pendant l’exécution de la séquence.

En plus de ces séquences nous allons retrouver tout un ensemble d’activités permettant de gérer les Workspace :

• ConvertWorkspaceItem : converti un chemin serveur ($/server/…) en un chemin local en se basant sur le mapping d’un workspace et vis-versa.
• ConvertWorkspaceItems : idem à ConvertWorkspaceItem mais acceptant une collection de chemins.
• CreateWorkspace : crée un workspace sur la machine locale en se basant sur la définition de build courante.
• DeleteWorkspace : supprime un workspace.
• GetWorkspace : récupère la définition d’un workspace.
• RevertWorkspace : annule toutes les modifications faites dans un workspace.
• SyncWorkspace : synchronise un workspace en local. L’ensemble des modifications effectuées sont accessibles (ajout, suppression ou modification de fichiers).

Ces activités couvrent la plupart des besoins mais on pourra regretter l’absence d’une activité de création de workspace indépendante du build. En effet l’activité CreateWorkspace est, de manière interne, fortement couplée au build en ayant besoin d’une définition de build et en proposant des paramètres spécifique au build tel qu’un répertoire pour les sources et un répertoire pour les binaires à générer.

Une autre catégorie d’activité présente est celle liée au label :

• LabelSources : pose un label sur un ensemble de fichier spécifiés.
• LabelWorkspace : pose un label pour sur l’ensemble des fichiers du workspace spécifié.

On va aussi retrouver des activités pour gérer les répertoires :

• CopyDirectory : copie un répertoire.
• CreateDirectory : crée un répertoire.
• DeleteDirectory : supprime un répertoire.

Concernant les fichiers c’est un peu plus pauvre, on ne retrouvera en effet que des activités liées à la récupération de fichier dans le contrôleur de sources et la recherche de fichier :

• DownloadFile : récupère une fichier du contrôleur de sources.
• DownloadFiles : récupère un ensemble de fichiers du contrôleur de sources.
• FindMatchingFiles : récupère l’ensemble des fichiers suivant un modèle.

On pourra, la aussi, regretter le manque d’activités permettant la copie, le déplacement ou la suppression d’un fichier ou d’un ensemble de fichier.

La plupart des autres activités sont pour la gestion et la récupération d’informations pour la build :

• AssociateChangesetAndWorkitems : associe à la build les changeset et work item (comme avec TeamBuild 2008).
• CheckInGatedChanges : checkin les modifications qui ont déclanchées une build de type Gated Check-In.
• EvaluateCheckInPolicies : évalue les politiques de checkin vis-à-vis du workspace spécifié.
• GetBuildAgent : récupère l’agent de build courant. Cette activité ne renvoi une valeur que si elle est appelée dans une séquence de type AgentScope.
• GetBuildDetail : récupère le détail de la build en cours tel que l’agent de build, la définition de build, le statut, …
• GetBuildDirectory : récupère le répertoire de build pour l’agent de build courant et met à jour l’ensemble de variable en remplaçant les token par des valeurs réelles spécifique au contexte courant.
• GetBuildEnvironment : récupère l’environnement courant. C’est à dire si le contexte actuel est un contrôleur de build ou un agent de build et le chemin vers des assemblies personnalisées.
• GetTeamProjectCollection : récupère la collection de TeamProject pour la build courante.
• MSBuild : appel la commande msbuild.
• OpenWorkItem : crée un work item de n’importe quel type.
• SetBuildProperties : met à jour les propriétés du détail de la build tel que le numéro de build, le statut de la compilation, le répertoire de dépose des binaires, la version des sources à récupérer, …
• TfsBuild : lance un build en se basant sur un projet de build TeamBuild 2008. Cette activité est utilisée lors de la mise à jour de TFS 2008 vers TFS 2010 afin de ne pas avoir à réécrire l’ensemble de vos builds
• UpdateBuildNumber : met à jour le numéro de la build en fonction du modèle fournit.

Les tests ayant une grandes importance dans VS 2010, on retrouve aussi quelques activités pour ceux-ci :

• GetImpactedTests : renvoi le code mis à jour ainsi que les tests impactés par ces mises à jour pour la build.
• MSTest : lance la commande mstest.

Petite nouveauté dans TeamBuild 2010, la gestion de l’indexation des sources (ajout dans les fichiers de symboles de l’adresse des sources directement dans TFS) et des serveurs de symboles :

• IndexSources : indexe les sources avec l’adresse des fichiers dans TFS (chemin du fichier et numéro de changeset).
• PusblishSymbols : publication des symboles sur un serveur de symboles.

Grâce à ces deux activités il n’y a plus besoin d’installer les outils de débogages de Windows et de personnaliser ces build de manière assez embêtante

Les dernières activités sont liées à la gestion des logs :

• WriteBuildError : log une erreur.
• WriteBuildInformation : log une information.
• WriteBuildMessage : log un message.
• WriteBuildWarning : log un avertissement.

Et voila on a fait le tour des différentes activités présente en standard dans TeamBuild 2010

Il y en a pas mal mais je regrette que seules celles nécessaires à la création des templates de build proposés par Microsoft soient fournit et que certaines soient un peu trop liées au build pour pouvoir être réutilisé en dehors. Mais dans l’ensemble je dirai quand même : “Chapeau Microsoft, TeamBuild 2010 est vraiment bien !”

Carpe Diem.