Le 10 juin de 9 heures à 12 heures, nous organisons dans les locaux de Microsoft Toulouse, un séminaire autour de TFS 2010.
Nous vous proposons d’explorer la pertinence de ces nouvelles fonctionnalités pour vos projets et d’échanger avec nos partenaires experts sur les premiers retours d’expérience de mise en œuvre.
Vous pouvez encore vous inscrire ici.
Comme son nom l’indique le serveur Proxy TFS est un serveur proxy, comparable à un proxy web, permettant d’optimiser l’accès pour les développeurs distants au fichiers du contrôleur de code source.
En effet, l’utilisation d’un Proxy TFS n’est utile que pour l’accès au contrôleur de code source, l’accès aux autres artéfacts de TFS n’est pas pris en compte par le serveur Proxy.
Sur ce post, je vous propose de voir ensemble :
TFS proxy va être utilisé pour optimiser la récupération des fichiers stockés sur le contrôleur de code source. Il n’est pas utilisé pour toute les opérations d’archivage. L’intérêt de son utilisation réside donc dans certaines configurations seulement:
Si les développeurs distants travaillent sur des projets distincts, il n’y a donc pas d’intérêt.
Concrètement le serveur TFS Proxy expose des Web services utilisés par le client (nécessité de IIS sur le serveur Proxy) et utilise un espace de stockage (cache) lui permettant de stocker les fichiers récupérés de manière à les fournir aux différents clients.
L’installation fait partie de l’installation du serveur TFS 2010, c’est à dire que vous trouverez ce composant sur le DVD de TFS 2010 au même niveau que le serveur de Build. Le serveur ou vous installez le Proxy doit avoir IIS installé (pré-requis, l’installation ne le fait pas pour vous) puisque le Proxy exposera des Web services.
La configurationUne fois la “feature” installée, vous devez la configurer via la console d’administration de TFS (Team Foundation Administration Console).
- Définir le compte utilisé et le mode d’authentification
Une fois Proxy serveur configuré, la dernière étape consiste à renseigner, au niveau du fichier de configuration proxy.config, l’adresse du serveur TFS qui fournira les données. La particularité de TFS 2010 réside dans le fait qu’il faut préciser également la collection à utiliser. Vous pouvez bien sûr définir plusieurs URI.
Soit à partir du lien de l’assistant de configuration
Soit à partir de la console d’administration, une fois la configuration terminée
<?xml version="1.0" encoding="utf-8"?>
<ProxyConfiguration
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Servers>
<Server>
<Uri>serverTFS/tfs/maCollection</Uri>
</Server>
</Servers>
<!-- Proxy file cache root folder -->
<CacheRoot>C:\...\_tfs_data</CacheRoot>
<CacheLimitPolicy>
<!-- Cache limit expressed as percentage of disk space -->
<PercentageBasedPolicy>75</PercentageBasedPolicy>
<!-- Cache limit expressed as MB -->
<!-- <FixedSizeBasedPolicy></FixedSizeBasedPolicy> -->
</CacheLimitPolicy>
<!-- Percentage of cache size that needs to be freed up, on hitting cache limit -->
<CacheDeletionPercent>10</CacheDeletionPercent>
<!-- Indicates how often (number of hours) the proxy statistics information should be persisted to a file-->
<StatisticsPersistTime>1</StatisticsPersistTime>
<ReaderChunkSize>1048576</ReaderChunkSize>
<WriterChunkSize>1048576</WriterChunkSize>
</ProxyConfiguration>
Une fois la configuration du serveur TFS Proxy effectuée, il ne vous reste plus qu’à indiquer à Team Explorer et Visual Studio d’utiliser un Proxy TFS. Pour cela, dans Visual Studio, dans le menu Tools, cliquez sur Options, puis sélectionnez la rubrique Source Control et Visual Studio Team Foundation Server.
Il ne vous reste plus qu’à indiquer l’adresse du serveur Proxy que vous souhaitez utiliser.
L’utilisation du Proxy TFS permet donc d’optimiser les opérations de récupération de fichiers pour les développeurs distants. L’ensemble des autres opérations (archivages, gestion des branches, …) ne sont pas prises en compte. De même, la consultation des Workitem ou autres fonctionnalités de TFS ne sont pas possibles à travers ce dernier. Ce Proxy reste néanmoins intéressant à mettre en place pour des équipes distantes travaillant simultanément sur le même projet et dont la qualité de l’accès internet est faible.
Venez assister à une présentation autour de la mise en place des méthodes agiles à l'aide de la nouvelle version de Team Foundation Server 2010 dans le cadre des sessions proposées par l'association SigmaT.
Les sessions auront lieu le 11/12/2009.
Vous trouverez ici le lien pour l'inscription et le lien la pour le programme.
Je suis en train de m’amuser un peu avec TFS 2010 Béta 2 depuis sa sortie (le 19 oct.). Le produit est terrible, cependant on est encore sur de la Béta…
Lorsqu’on essaie de faire une TFS Build, nous avons un beau petit message d’erreur:
Après quelques recherches, il suffit juste de préciser le chemin de MSBuid.exe aux tâches de la définition de Build. Et oui, il est un peu perdu…
Pour cela, soit vous êtes un guerrier et vous éditez directement le fichier .xaml de la définition de build afin d’ajouter l’attribut “ToolPath” avec le chemin complet de MSBuild.exe
Ou si vous êtes comme moi, vous ne faites pas du Microsoft pour avoir à éditer des fichier .xaml de 12000 lignes, vous utilisez l’éditeur WF de TFS 2010.
Et voilà, ça marche.
La version 2010 de TFS fourmille de nouveautés. Je vous propose aujourd’hui de se concentrer sur les apports concernant la gestion des configurations : le contrôleur de code source.
Un vrai effort a été produit sur cette nouvelle version afin de mieux répondre aux attentes des développeurs et des chefs de projet concernant le travail parallèle. On ne parle pas ici de multi thread mais de gestion des versions d’une applications qui doivent vivre en parallèle, ou tout simplement, du travail simultané de n développeurs sur le même projet.
Le gestionnaire de configuration de TFS 2010 fournit les fonctionnalités classiques déjà présentes dans la version 2008, je vous propose de nous concentrer sur la gestion des branches qui a subit un sérieux lifting et sur des nouvelles fonctionnalités comme le “ChangeSet Tracking”.
L’idée de cet article n’est pas de vous convaincre de l’intérêt des branches, ceux qui ont été confrontés à la gestion des versions d’une application sont déjà convaincu.
Par contre, lors de l’utilisation de ces branches dans la version TFS 2008, plusieurs difficultés se présentaient:
Afin de répondre à ces problématiques plusieurs fonctionnalités ont été mises en place sur TFS 2010.
Tout d’abord, le truc bête mais très utile, on a maintenant des icones qui permettent de différencier de manière visuelle les branches des dossiers.
De plus, nous avons la possibilité de convertir un dossier en branche.
Une fois nos différentes branches crées, nous avons à notre disposition un ensemble d’outils permettant:
Autre point intéressant concernant la dite branche, nous disposons d’une fenêtre de propriété beaucoup plus complète permettant entre autre:
Les outils de comparaisons se sont aussi étoffés et proposent davantage de possibilités:
De plus, la possibilité de consulter l’historique de la branche permet d’accéder à l’ensemble des “Changesets” (jeu de modification issue de l’archivage) qui la constitue. En plus des opérations classiques sur ces “Changesets”, la nouvelle interface de VS 2010 introduit un concept très intéressant qui est le “Changeset Tracking”.
Un des gros inconvénients de la version 2008, lors de l’utilisation des branches, était d’arriver à savoir si une modification apportée sur une branche, l’avait été aussi sur d’autres.
En effet prenons un exemple concret, vous continuez à développer d’autres fonctionnalités d’une application qui est déjà livrée en production. Un utilisateur vous appelle pour vous signaler un Bug (pas bien !!!), vous faites la correction et attendez la prochaine livraison pour la mettre à disposition. Après la livraison, vous constatez que le Bug persiste alors que vous aviez corrigé. La conclusion est donc que votre modification n’a pas été intégré dans les différentes opérations de fusion.
VS 2010 propose donc un mécanisme simple vous permettant de suivre la propagation de vos corrections ou modifications dans l’ensemble des branches de votre projet : le Changeset Tracking.
A partir de l’historique, vous pouvez repérer le jeu de modifications que vous souhaitez suivre et ainsi visuellement, contrôler son intégration dans l’ensemble des branches. Les branches qui contiennent les modifications apparaitront en vert alors que les autres, en rouge, vous alerte sur le fait que vos corrections n’ont pas été appliquées.
Vous aurez à votre disposition:
Pour finir, en plus de ces fonctionnalités de contrôles visuels, vous pourrez effectuer votre opérations de fusion de manière graphique en faisant un cliquer-glisser du Changetset de la branche source vers la branche cible pour effectuer votre fusion.
En conclusion, de gros efforts ont été entrepris pour faciliter le travail de l’équipe de développement. Néanmoins ces outils ne remplaceront pas certaines bonnes pratiques qu’il faut mettre en place comme :
