Les Services Web de Team Foundation Server (TFS) - Première partie

  • Article

Author Noham Choulant, Consultant - ExpertEase

Aout 2007

Noham Choulant travaille sur la plateforme DotNet depuis quelques années. Noham est responsable du département développement de la société ExpertEase. Passionné par les technologies Microsoft il est administrateur du site Team System. Il participe également à l'élaboration du club VSTS. ExpertEase, créée en 1989, est une société de services et de formation en informatique, spécialisée dans les prestations techniques et pédagogiques en environnement technologique Microsoft.

Résumé : Team Foundation Server regorge d’informations et d’actions. Dans cet article nous allons mettre en avant le Web Service BUILDCONTROLLER.ASMX, concernant la gestion des BUILD. Nous traiterons les autres Services Web dans les prochains articles.

Sommaire

  1. Introduction
  2. Etude de BUILD
  3. BuildController.asmx
    • BuildCompleted
    • DeleteBuild
    • InsertBuildQuality
    • RemoveBuildQuality
    • RemoveRun
    • ReportBuildError
    • StartBuild
    • StopBuild
    • ValidateBuildStart

Introduction

Team Foundation Server fait partie de la famille de Visual Studio Team System. Team Foundation Server est le serveur collaboratif de la gamme. Il permet d’archiver les sources, de créer un portail par projet, de gérer les anomalies, de faire de l’intégration continue, de piloter des projets.

Je ne vais pas vous faire une nouvelle présentation de Team Foundation Server et de tous les avantages que pourrait amener Team Foundation Server dans vos projets et notamment pour en assurer la réussite car c’est bien cela le plus important. Pour en savoir plus, je vous recommande la lecture du livre blanc « Approches pragmatiques pour industrialiser le développement d’applications (Nouvelle version) » que vous pouvez télécharger à l’adresse suivante :

Cette série d’articles est conçu comme un lexique et va se centrer sur les Web Services que Team Foundation Server met à votre disposition. Toute personne ayant travaillé avec une version de Team System a déjà utilisé Team Explorer. Team Explorer utilise les web services pour se connecter à TFS et pour vous fournir les informations. Cela signifie que par le biais de ses WS, il est possible de développer une application personnalisée permettant d’interagir avec Team Foundation Server. J’apprécie les Web Services dans le sens ou cela permet l’interaction entre TFS et des produits développés dans d’autre technologie. Dans mes projets les Web Services de TFS me permettent de développer une application WEB légère me d’administration et de surveillance de TFS.

Vous trouverez dans cette série d’articles une explication de chaque Web Service et des méthodes qui y sont proposées. Cet article est destiné à une population technique qui a déjà une première connaissance de TFS et qui souhaite aller plus loin.

Pour la réalisation de ces articles j’utilise la version de Visual Studio 2008 Team Foundation Server (VS 2008 est le nom final d’« Orcas »). Dans cette nouvelle version TFS utilise Windows Communication Foundation pour interroger les Web Services. Pour en savoir plus sur WCF, vous pouvez lire mon article à l’adresse suivante :

Les technologies de Microsoft les plus récentes sont donc bien utilisées par les nouvelles versions des produits.

La configuration de l’APP.CONFIG ou du WEB.CONFIG se fait automatiquement lors de l’enregistrement de la référence. Dans le cas des tests suivant, la vérification de l’authentification ce fait avec « Ntlm » pour les balises suivante :

  • clientCredentialType="Ntlm"
  • proxyCredentialType="Ntlm"

Etude de BUILD

Dans ce premier article nous allons étudier le Web Service BUILDCONTROLLER.ASMX qui permet la gestion des BUILDs. Nous allons mettre en pratique ce Web Service dans une application.

Comme je l’ai expliqué dans l’introduction, VS2008 permet d’interroger les Web Services par le biais de Windows Communication Foundation. Lors de l’enregistrement d’un nouveau service, le fichier de configuration (app.config ou web.config) est généré automatiquement avec le « ENDPOINT » client nécessaire. L’utilisation ensuite du service est relativement simple, ce n’est qu’une question d’habitude. Pour exécuter l’exemple proposé, il vous faudra disposer d’un serveur ayant TFS 2008, disponible en machine virtuelle à l’adresse suivante :

https://www.microsoft.com/downloads/details.aspx?FamilyId=60A5B34B-98B0-4702-B2DD-6FC0BEF7E494&displaylang=en

Pour modifier l’application fournit en exemple il vous faudra disposer d’une version de Visual Studio 2008, disponible à l’adresse suivante :

https://msdn2.microsoft.com/fr-fr/vstudio/aa700831.aspx

Ensuite il vous faudra modifier le fichier de configuration au niveau de l’adresse IP, pour qu’il puisse interroger votre serveur.

Pour utiliser une méthode du service enregistré, il nous suffit de mettre en place :

  • Le CHANNELFACTORY du type du service :

                //Création du client
             ChannelFactory<BuildControllerSoap> Service;

  • D’instancier le CHANNELFACTORY avec le ENDPOINT généré :

    //Récupération du EndPoint
            Service = new ChannelFactory<BuildControllerSoap>("BuildControllerSoap");

  • De créer le Channel :

                //Création du canal de discussion
             BuildControllerSoap buildController= Service.CreateChannel();

  • Appeler la méthode souhaitée, à ce moment il y a deux cas :

    • Récupérer une réponse (Dans cette exemple nous récupérons un tableau d’objets de type CHANGESETDATA) :
    • Exécuter une méthode sans retour (l’ajout d’un objet de type CHANGESET):

BUILDCONTROLLER.ASMX

Lien: https://localhost:8080/Build/V1.0/buildcontroller.asmx

Classe: Microsoft.TeamFoundation.Build.Server.BuidController

BUILDCOMPLETED

            void BuildCompleted ([ClientType(typeof(Uri))] string buildUri)

Cette méthode permet la génération d’une Build sur Team Foundation Server. En paramètre la méthode prend une URI sous la forme d’une chaine de caractère. Nous pouvons voir que cette chaîne de caractères est TYPE URI.

C’est intéressant lorsque l’on souhaite créer des BUILDs liés par exemple à une étape majeure d’un projet pour y associer des résultats de test qui ne sont pas exécutés via un BUILD.

Pour récupérer l’URI de BUILD vous pouvez vous servir du WS BuildStore.asmx et de la méthode GetBuildUri.

DELETEBUILD

            bool DeleteBuild ([ClientType(typeof(Uri))] string buildUri, out string failureMessage)

Cette méthode permet la suppression d’une BUILD sur le serveur. Elle prend deux paramètres, un pour l’URI de la BUILD et le second paramètre étant un string passé avec OUT permettant de récupérer le message d’erreur.

Pour récupérer l’URI de BUILD vous pouvez vous servir du WS BuildStore.asmx et de la méthode GetBuildUri.

INSERTBUILDQUALITY

            void InsertBuildQuality (string teamProject, string buildQuality)

Cette méthode permet d’ajouter un nouveau niveau de qualité de BUILD au projet de Team Foundation Server.
Elle prend deux paramètres :

  • Le nom du projet.
  • Le nouveau niveau de qualité.

REMOVEBUILDQUALITY

void RemoveBuildQuality (string teamProject, string buildQuality)

Cette méthode permet de supprimer un niveau de qualité d’un projet de Team Foundation Server.
Elle prend deux paramètres :

  • Le nom du projet.
  • Le nouveau niveau de qualité.

REMOVERUN

bool RemoveRun ([ClientType(typeof(Uri))] string buildUri, Guid runId)

Cette méthode permet de supprimer l’exécution d’une BUILD.
Elle prend deux paramètres :

  • L’URI de la BUILD.
  • Identifiant de l’exécution.

Pour récupérer l’URI de BUILD vous pouvez vous servir du WS BuildStore.asmx et de la méthode GetBuildUri.

REPORTBUILDERROR

void ReportBuildError ([ClientType(typeof(Uri))] string buildUri, int exitCode)

Cette méthode permet de connaître les raisons de l’échec d’un BUILD.

Pour récupérer l’URI de BUILD vous pouvez vous servir du WS BuildStore.asmx et de la méthode GetBuildUri.

STARTBUILD

string StartBuild (BuildParameters buildParameters)

Cette méthode permet de démarrer l’exécution d’une BUILD.
Elle prend en paramètre :

  • Un objet de type BUILDPARAMETERS dont voici la structure :
            // Properties
            public string BuildDirectory { get; set; }
            public string BuildMachine { get; set; }
            public string BuildNumber { get; set; }
            public string BuildType { get; set; }
            public string BuildUri { get; set; }
            public string DropLocation { get; set; }
            public string LastBuildNumber { get; set; }
            public string LastGoodBuildNumber { get; set; }
            public string RequestedBy { get; set; }
            public string TeamFoundationServer { get; set; }
            public string TeamProject { get; set; }

STOPBUILD

bool StopBuild ([ClientType(typeof(Uri))] string buildUri, out string failureMessage)

Cette méthode permet d’arrêter la génération d’une BUILD. Deux paramètres sont nécessaires :

  • l’URI de la BUILD
  • Une chaîne de caractères pour récupérer le message si besoin.

Pour récupérer l’URI de BUILD vous pouvez vous servir du WS BuildStore.asmx et de la méthode GetBuildUri.

VALIDATEBUILDSTART

bool ValidateBuildStart (string teamProject, string buildType, string buildMachine)

Cette méthode permet de savoir si une BUILD est bien en cours d’exécution.