Team Foundation Server, connu pour sa plateforme de travail collaboratif puissante, possède un Software Development Kit. Ce dernier nous permet de profiter pleinement des ressources qu’il met à notre disposition afin de l’intégrer, par exemple, dans un environnement de développement existant et hétérogène.
Introduction
Visual Studio Team System est l’outil d’industrialisation des développements Microsoft.
Il est composé d’un serveur nommé Team Foundation server et de clients tels que les différentes éditions de Visual studio, ou encore Excel et Microsoft Project.
Si Visual Studio Team System est aujourd’hui bien connu, le Software Development Kit (SDK) qui l’accompagne l’est un peu moins.
La première chose qui vient à l’esprit quand on l’apprend est « Mais à quoi peut servir le SDK de Team Foundation Server ? ».
Tout d’abord, il permet d’accéder aux services, fournis par Team Foundation server voire encore de créer son propre client à l’image de Team Explorer ou de Microsoft Team System Web Access.
Mais surtout, il vous permet d’intégrer plus simplement Team System au sein de votre plateforme de développement d’entreprise, comme, par exemple, récupérer les temps de travaux de chaque tâche afin de les intégrer dans un outil d’entreprise de gestion d’activité.
Cet article vous présente ce SDK. Dans un premier temps nous verrons l’architecture Technique de Team Foundation Server. Puis nous regarderons la composition de ce SDK, enfin nous réaliserons un outil permettant de créer des work items et de récupérer les informations essentielles qu’ils contiennent.
Tous les exemples présentés dans cet article sont réalisés à partir du Visual Studio SDK en version de février 2007.
LE TEAM FOUNDATION SERVER SDK
Visual Studio Team System est basé sur une architecture 3-tiers et multicouches (possibilité de l’installer sur 2 serveurs séparés, un serveur de données et un serveur de services).
L’architecture technique de la plateforme est la suivante :
Figure 1: Architecture de Team foundation Server
Dans la partie cliente le modèle objet permet d’encapsuler l’accès aux services du second tiers, détaillons-le.
Ce Modèle objet est découpé en 5 services comme suit :
· Les Services du noyau,
· Le contrôleur de sources,
· Le suivi des Works items,
· Team Build,
· Team Foundation Data Warehouse,
Les services du noyau :
Ils nous permettent d’établir une connexion avec un serveur ou encore de récupérer toutes les informations nécessaires sur les « Team Project ». Ci-dessous la connexion à un Team Foundation server.
Public TeamFoundationServer server;
server= TeamFoundationServerFactory.GetServer("NomDeMonServeur");
On y trouve aussi les services d’abonnement, nous permettant d’être notifié dès qu’une action s’exécute sur le serveur. Mais aussi les services liés à la sécurité et droit d’accès au Serveur.
Le contrôleur de sources :
Ce modèle objet met à disposition l’ensemble des moyens permettant de piloter le contrôleur de sources, ci-dessous l’instanciation de ce service :
public static VersionControlServer vcStore;
vcStore=server.GetService(typeof(VersionControlServer))as VersionControlServer;
Via ce service nous pouvons accéder au(x) Workspsace(s) référencé(s) sur le serveur mais aussi aux branches, aux merges ou encore aux ChangeSet. Nous pouvons donc piloter la création d’étiquettes ou la récupération de l’historique.
Le suivi des Works items :
Ce modèle permet toutes les manipulations concernant les éléments de travail pour vérifier des liens ou encore lister les works items. Ci-dessous l’accès à ce service
public WorkItemStore wiStore;
wiStore = server.GetService(typeof(WorkItemStore)) as WorkItemStore;
Comme nous le verrons plus loin dans cet article, ce service très complet nous permet de créer des Work items, de les lister et donc de récupérer les informations associées.
Team Build :
Ce modèle objet permet d’enrichir l’ensemble des builds automatiques paramétrés avec TFS builds.
public BuildStore bStore;
bStore = server.GetService(typeof(BuildStore)) as BuildStore;
Team Foundation Data Warehouse :
TFS regroupe les données issues des Work items, du contrôleur de sources, des builds et des outils de tests dans un DataWharehouse (cube OLAP). Il est alors possible d’interagir avec, par l’intermédiaire d’un modèle objet dédié, et notamment d’ajouter des informations directement dans cet entrepôt de données via une interface.
private IDataStore dataStore;
dataStore.BeginTransaction();
//Action d'ajout d'information
dataStore.LogEvent(AdapterEventLevel.Warning,"mon Message de log");
dataStore.CommitTransaction();
EXEMPLE D’UTILISATION DU TFS SDK
Afin de mieux faire connaissance avec ce SDK, je vous propose de réaliser un outil qui récupère une liste de Work items et qui crée un Workitem. L’objectif ici est de vous présenter une classe nommée « TFSManager » possédant les fonctions statiques qui nous intéressent.
Les Assemblies à référencer :
Microsoft.TeamFoundation.WorkItemTracking.Client.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.Client.dll
Les namespaces : Les namespaces nécessaires à la bonne exécution du code sont les suivants
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Server;
using Microsoft.TeamFoundation.WorkItemTracking.Client;
La classe TFSManager possède des propriétés permettant de garder des références vers le projet en cours d’utilisation, mais aussi des variables statiques référençant le serveur et les services utilisés. Cela se présente de la façon suivante :
Référence vers les services :
private static string currentProject;
public static string CurrentProject
{
get
{
return currentProject;
}
set
{
if (wiStore == null)
throw new Exception("Impossible d'affecter cette valeur tant que vous n'êtes pas connecté à un Team Foundation Server");
currentProject = value;
}
}
private static Hashtable context;
Première étape : La connexion à un Team Foundation Server et la récupération du service WorkItem Tracking via le constructeur de notre classe.
Figure 2: Connection au serveur
public static void Connect(string serverName)
{
//connection au Serveur
server = Microsoft.TeamFoundation.Client.TeamFoundationServerFactory.GetServer(serverName);
//Chargement du service Work Item Tracking
wiStore = server.GetService(typeof(WorkItemStore)) as WorkItemStore;
}
La connexion à un Team Foundation Server se fait à l’aide d’une Factory et prend en paramètre soit l’URI, soit le nom d’un serveur TFS comme ici (une identité peut, bien sûr, lui être communiquée pour l’authentification).
Une fois connecté au serveur, il nous reste à récupérer le(s) service(s) que l’on souhaite utiliser dans la suite de notre application. Dans notre cas le service de suivi des Work Items.
Deuxième étape : Récupération de la liste des Team Projects à partir du service de suivi des Work Items
public static ProjectCollection GetProjects()
{
if (wiStore == null)
return null;
return wiStore.Projects;
}
Comme présentée ici, la liste des projets est accessible par le service de suivi des Work items et nous retourne une collection de projets.
Troisième étape: Listons les work items associés à un team project. On utilise pour cela la variable currentProjet vue plus haut dans la définition de TFSManager.
private static String QueryOfTeamProject = "SELECT [System.Id], [System.WorkItemType], [Microsoft.VSTS.Common.Rank], [System.State], [System.AssignedTo], [System.Title] FROM WorkItems WHERE [System.TeamProject] = @project";
public static WorkItemCollection GetWorkItems()
{
if (wiStore == null)
return null;
context = new Hashtable();
context.Add("project", currentProject);
return wiStore.Query(QueryOfTeamProject, context);
}
Pour lister les Work items d’un Team Project il est nécessaire d’utiliser une requête (« Query » au sein de Team system). Dans l’exemple précédent, la requête utilisée se nomme «QueryOfTeamProject » Cette requête peut prendre, comme dans notre cas, un ensemble de paramètres qui sont alors spécifiés au sein d’une Hashtable ici nommée « context ».
Notre requête pour sa part, prend un seul paramètre qui est le Team Project, sur lequel elle doit récupérer ses informations.
Quatrième étape : Créer un Work item de type « Tâche » à partir d’une liste de champs renseignés par un utilisateur.
public static void AddTask()
{
if (!String.IsNullOrEmpty(currentProject))
{
WorkItemType wiType = wiStore.Projects[currentProject].WorkItemTypes["Task"];
WorkItem wi = wiType.NewWorkItem();
wi.Fields["Title"].Value = "Nouveau Work Items";
wi.Fields["Description"].Value = "Test de la création d'un Work Item";
wi.Fields["State"].Value = "Active";
wi.Save();
}
}
Créer un Work Item nécessite plusieurs éléments. Tout d’abord la spécification du type de WorkItem que l’on veut créer comme par exemple : « Tâche » ou « Bogue ».
Une fois le type défini, nous pouvons récupérer les champs disponibles et renseigner chacun d’eux pour le Work item que nous avons initialisé. Il faut bien sûr appeler la méthode « save » du Work item pour l’enregistrer dans le projet en cours.
CONCLUSION
Nous avons vu au cours de cet article, une utilisation simple du SDK de Team Foundation Server. Ce dernier, nous permet donc d’étendre la plateforme Team System sans avoir à connaître ni le schéma de la base de données, ni les services exposés par la couche de services.
Nous aurons l’occasion lors d’un prochain article d’approfondir chacun des services cités précédemment. Nous pourrons alors enrichir TFSManager d’une gestion avancée du contrôleur de sources ou encore la souscription à des alertes retournées par TFS.