Batswirl

KB947455 - Actions "Delete" répétées durant les fusions

2008-07-21T12:00:25Z

Petit rappel : Une fusion dans Team Foundation Version Control est constituée d'une liste de "jeux de modifications" (ChangeSets en anglais) que l'on souhaite reporter d'une branche à l'autre. Les jeux de modifications comporte des actions (ajout, renommage, édition...) appliquées à des Items(les fichiers et les dossiers). La fusion consiste donc à répéter les différentes actions sur les items d'un jeu de modifications sur les items communs entre les branches.

Problème : Les actions de suppression des fichiers ne sont pas répétés durant les fusions dans TFVC 2005 et TFVC 2008. Les fichiers qui ont été supprimés dans la branche de destination seront donc toujours présents malgré le report de l'ensemble des modifications dans la branche Cible. Le problème est connu et une KB est disponible ici : http://support.microsoft.com/default.aspx/kb/947455/en-us

Résolution : Microsoft vient de publier un correctif visant à permettre de reporter les opérations de suppression à l'aide d'une opération de fusion. Ce correctif est disponible ici : http://code.msdn.microsoft.com/KB947455/Release/ProjectReleases.aspx?ReleaseId=1127 .

Il permet donc de voir apparaître des actions de suppression lors de la fusion entre deux branches.

Dans l'exemple ci-dessous, il s'agit du fichier web.config qui devra être supprimé après la fusion.

Nous avons bien l'effet attendu en vérifiant après la fusion les modifications en attentes sur l'espace de travail :

A noter toutefois que ce correctif ne permet pas de reporter des suppressions entre deux dossiers à l'aide de l'option /Baseless disponible à l'aide de l'outil en ligne de commande tf.exe, comme en témoigne le résultat des modifications en attentes ci-dessous.

Après exécution de la commande :

On constate donc que le fichier qui a été supprimé dans la branche source a donc été ignoré lors de la fusion.

Bientôt un nouveau projet TFS sur Codeplex

2008-04-29T20:55:04Z

En avant première, je vous parle d'un petit outil que je suis en train de réaliser pour les développeurs disposant de Team Foundation Version Control comme contrôleur de code source.

Si la mise sur étagère constitue une fonctionnalité interessante et aux multiples applications, je trouve qu'elle est sous exploitée par la majorité des équipes. Si l'on peut programmer celle-ci afin d'automatiser la sauvegarde du travail réalisé sur les machines de développement, j'ai eu l'idée de l'utiliser pour une tout autre application, faire de vos journées de code la même expérience que Marty Mac Fly au cours d'une célèbre trilogie.

Ne vous êtes jamais dit que le code que vous aviez écrit à 11h00 était meilleur que celui que vous avez devant vous alors qu'il est 18h30, que vous aimeriez archiver et rentrer chez vous mais que ce dernier ne compile pas, qu'il est trop compliqué, que les tests à réaliser seront trop longs à écrire et que finalement : Dérivez de cette classe abstraite plutôt que d'implementer l'interface ISuperMegaExtraAbstraction n'est pas si grave...

Le problème dans pareil cas est de retrouver cette version de 11h00. Si cela vous pose problème, MyStream sera là pour vous. MyStream est une application s'exécutant dans la barre des tâches de Windows qui scanne les espaces de travail que vous avez sélectionnés à intervalles réguliers. Si une modification a été opérée sur ce dernier, un ShelveSet (une mise sur étagère) est créé.

Vous pourrez alors revenir très facilement à cette version par la suite en effectuant une extraction spécifique de ces modifications.

On disposera également d'une suppression automatique des mises sur étagères créés par MyStream au délà d'un délai configurable afin de limiter le volume et le nombre des éléments sauvegardés.

Voilà pour la présentation.

Publication de l'outil avant le 5 mai (date limite avant suppression du projet sur Codeplex ;) )

N'hésitez pas à me faire part de vos commentaires et sur les fonctionnalités liées dont vous pourriez rêver.

Get Lastest on Check-out

2008-04-29T19:41:00Z

Ou pourquoi je ne recommande pas une nouvelle fonctionnalité de Microsoft Visual Studio Team Foundation Server 2008.

Rappel : la fonctionnalité permet d'extraire la dernière version du fichier lorsque vous demandez son extraction pour modificaiton. Il s'agit du comportement par défaut de Visual Source Safe et a été largement demandé par un certain nombre d' utilisateurs de TFVC 2005 qui n'en disposait pas

Il est désormais connu de tous qu'au cours de la planification d'un projet il est indispensable de fixer des jalons, des points de repère qui nous permettront de vérifier que nous ne nous sommes pas écartés du droit chemin, de notre objectif initial. Si tel est le cas, nous corrigerons notre route, nos tâches à faire afin de reprendre la bonne direction.

Cette technique, bien connue des adeptes de la navigation aérienne, nous l'utilisons tous les jours, à tout moment, dans chacune de nos actions. Nous établissons un plan de route que nous nous efforçons de tenir. Les imprévus font que nous devons nous positionner puis nous réorienter avant de pouvoir reprendre notre route.

Et en quoi cela concerne-t-il un contrôleur de code source ou un développeur me direz-vous?

Les développeurs n'échappent pas à la règle.

Je me place rarement derrière une machine, dans un environnement de travail sans savoir ce que je vais réaliser. A partir d'un objectif, je vais placer mes jalons, les sous-modules, les types, les routines qui me permettront de mener à bien ma tâche et faire progresser mon produit.

Je commence donc mon travail, je crée des classes, des interfaces,bref... Je crée des fichiers. Tout irait pour le mieux jusqu'à ce que j'aie à travailler en équipe et que j'utilise un contrôleur de code source et/ou que je doive prendre en compte l'existant.

Je m'apprête à modiifer cette classe abstraite dont je dérive afin que cette dernière me fournisse un service bien sympathique et là... c'est le drame.

Un développeur a mis à jour cette classe depuis ma dernière extraction du fichier et j'ai activé l'option Get lastest on Check-out. Je dois désormais prendre en compte dans mon plan, cette nouvelle méthode à implémenter, les modifications du contexte etc...

Qu'à cela ne tienne, les obstacles ne m'effraient guère et je consens à implémenter cette méthode et à modifier les paramètres d'appel des différentes méthodes.

Pourtant, au cours de la journée, l'incident se répète sans cesse et je commence à ne plus trop cerner mon plan d'action initial. J'en arrive même à faire des concessions dans ma conception initiale afin de me plier aux apports des autres développeurs. Soit.

Le constat

Le constat que nous pouvons tirer de cette journée de travail type est que le report des modifications d'un référentiel commun dans notre espace de travail et sans intervention de notre part nous force à intégrer ces modifications dans notre travail en cours.

Pourtant, je l'avoue, je ne suis pas thread safe et l'accumulation de paramètres à prendre en compte réduit ma capacité à prendre les bonnes décisions sur le sous système que je suis en train de concevoir.

Les différentes déviations que me font prendre ces modifications, m'eloignent petit à petit de ma route que je distingue de moins en moins. Imaginez qu'au cours de ces déviations, un golf s'offre à moi et vous comprendrez le retard que je pourrais prendre (les personnes me connaissant feront le rapprochement).

En bref, si les méthodes agiles préconisent une réactivité face au changement, elles permettent également d'organiser ce changement. Après tout, durant mon développement si je pressens devoir prendre en compte des modifications présentes sur le serveur, rien ne m'empêche de les récupérer. Cependant, je ne vois aucun intérêt à subir les affres d'un quelconque automatisme dans cette opération.

Une des valeurs agiles : Le courage

N'ayez crainte, il ne s'agit pas d'un article uniquement réservé aux adeptes des méthodes agiles, certains frileux des termes itérations et incrémentales ont déjà approuvé mes propos concernant mon point de vue sur cette option de TFS.

Le courage, c'est aussi être honnête et reconnaître ses fautes. Ainsi, il m'arrive, parfois, durant mon développement, d'être lassé de cette "intégration" continue (notez bien les guillemets et ne me faites pas dire ce que je n'ai pas dit).

Lassé, au point de tout faire pour en arriver à ce que je veux : Compiler, tester.

Alors que fait le développeur dans ce cas?

Il intègre me direz vous. Non monsieur, il corrige, atténue, prend en compte pour palier son besoin primaire : Compiler et voir si ce qu'il a écrit marche.

Certains appellent cela une intégration, pour ma part, j'appellerais ça une rustine.

Ne nous y trompons pas, le changement et l'intégration non organisés sont des virus qui peuvent mettre à mal votre volonté de bien faire.

Et l'intégration alors?

J'entends alors au loin les discours moqueurs me signalant que je n'ai toujours pas intégré mon code avec le référentiel et que je vais en mettre du temps. Ma réponse est Oui, je vais mettre du temps pour intégrer, mais aussi prendre le temps d'intégrer.

L'intégration consiste à confronter vos réalisations face aux modifications apportées par vos coéquipiers. Une partie de mon planning quotidien ou hebdomadaire devra être réservée à cela. Si, en plus, ces créneaux horaires sont communs à l'ensemble de l'équipe, je disposerais de collègue entièrement disponibles pour parler de telle abstraction à revoir ou de telle librairie que j'ai utilisée et qui leur permettrait d'archiver et donc d'intégrer plus rapidement. Encore une fois, déranger un développeur par vos propres soucis durant son développement ne provoquera que deux choses :

Vous parlerez dans le vide ou presque
Il ne vous invitera pas à son mariage se rappellant de ce petit bug que vous l'avez aidé à glisser dans sa fonctionnalité et qui a coûté si cher en production

Voilà pourquoi je ne recommande pas et je n'active pas l'option Get lastest on Check Out dans Team Foundation Version Control 2008.

Dans une prochaine publication, je confronterai mes résultats de test de QI à ceux de Visual Studio afin d'expliquer pourquoi je ne laisse jamais l'IDE s'occuper de mon espace de travail.

Erreur 32000 lors de la migration de TFS 2008

2008-04-28T20:25:04Z

Voici une entrée dans laquelle je vais présenter un problème que vous pourriez rencontrer lors d'une migration de votre serveur Team Foundation.

Bien que dans la majorité des migrations que nous effectuons, la procédure se résume à la simple exécution du programme d'installation, certaines petites manipulations ou configurations peuvent vous posait problèmes durant cette opération. Il semblerait que ce soit le cas pour la migration que j'ai opéré aujourd'***. Il s'agit d'une instance installée il y a de cela deux ans, qui n'a jamais posé de problème particulier hormis peut être avec Analysis Services. La remise en état du Warehouse se résumait à une reconstruction de l'entrepôt de données.

Voici donc l'erreur rencontrée durant la phase d'installation / migration:

Erreur 32000 : The Commandline '"C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Tools\TfsDb.exe" upgrade /server:"SERVER" /property:"TFS_SERVICE_ACCOUNT=SERVER\TFSSERVICE;TFS_REPORTING_ACCOUNT=SERVER\TFSREPORTS;LCID=1033;VSTF_AS_INSTANCE=SERVER;VSTF_AS_DATABASE=TFSWarehouse" /showui:196682' returned non-zero value: 100.

Cette erreur apparaît lors de la mise à jour de l'entrepôt de données, tiens, tiens...

La consultation des logs de l'installation présents dans les fichiers temporaires de l'utilisateur procédant à la migration nous révèle un premier indice :

Erreurs dans le gestionnaire de métadonnées. Une erreur s'est produite lors de l'instanciation d'un objet de métadonnées du fichier, « \\?\E:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Data\TFSWarehouse.0.db\Today.1452.dim.xml ».

En allant consulter le fichier indiqué dans le journal d'installation, j'ai pu constater qu'il s'agissait des informations de construction de la dimension Today du cube de Team Foundation Server. Dans ce fichier, qui semble être le fruit d'une sérialisation XML, l'erreur se comprend enfin : le fichier n'est pas valide, plus encore, il ne possède pas de balise de fin et n'est donc pas bien formé.

Après avoir pris conseil auprès de certains collègues plus au fait que moi dans les affaires de cubes et d'entrepôts, je prends mon courage à deux mains et renomme la dizaine de fichiers *.dim.xml qui semblent poser problèmes pour constater :

Que l'installation s'achève sans autre avertissemnet
Que les fichiers *.dim.xml ont été regénérés

L'architecture de Team Foundation est venue à notre rescousse car l'entrepôt de données et le cube peuvent être regénérés uniquement à l'aide des données présentes dans les différentes bases relationnelles (les données opérationnelles de TFS). Le fichier WareHouseSchema.xml, présent dans le répertoire d'installation de TFS, contient l'intégralité des définitions nécessaires à sa reconstruction et bien entendu , nous n'aurions pas pu supprimer la définition des dimensions dans une définition standard d'un entrepôt.

En espérant que vous n'ayez pas à vous servir de ce post...

Étendre les attributs des méthode de tests dans MsTest

2008-04-27T22:30:23Z

Un article très sympa de Justin Burtch est disponible ici.

Ce dernier a en effet développé quelques bouts de code permettant d'étendre les fonctionnalités de MsTest et permettre certaines configurations possibles avec mbUnit par exemple. Le code source est disponible en version Visual Studio 2005 mais la conversion ne m'a posé aucun problème.

Team Foundation Version Control : les bonnes surprises de la version 2008

2008-04-27T19:46:50Z

Complètement passée inaperçue lors de mon analyse des nouvelles fonctionalités de Visual Studio 2008, une limitation de la version 2005 du produit a disparu.

Rappel des faits

Les espaces de travail permettent de définir la liaison entre votre système de fichiers et votre contrôleur de source. Les liaisons multiples permettent de construire une vue de votre contrôleur, éventuellement composée d' éléments de différents projets d' équipe.

Revenons sur un cas d' utilisation, le Shared Source.

Imaginons un plateau de développement composé de deux équipes distinctes, une équipe "Framework" et une équipe "Applicatif". L'équipe "Framework" met à disposition des développeurs de l'équipe "Applicatif" un certain nombre de composants, facitlitant l'implémentation des applications et favorisant un développement homogène pour l'ensemble du plateau de développement.

Chaque équipe travaille dans son propre projet d'équipe.

Afin de faire partager leurs expériences de l'utilisation des composants, il a été décidé de mettre à disposition de l'équipe "Applicatif" les différents sources des composants qu'ils utilisent. Ils peuvent ainsi à tout moment effectuer des corrections qui seront potentiellement intégrées au code du framework après acceptation de l'équipe "Framework".

Une solution est de créer une branche du code source disponible du "Framework" dans le projet d'équipe "Applicatif". Cependant, cela impose aux développeurs de l'équipe "Applicatif" de mettre à jour le source à partir de la branche mère à chaque modification du framework et la gestion devient difficile si les équipes consommant le framework viennent à se multiplier.

Une autre solution consiste à créer une branche du code principal (branche Main) du framework directement dans le projet d'équipe "Framework" et à utiliser cette branche afin de permettre la diffusion et l'édition du source dans un référentiel partagé par toutes les équipes de développement. On utilise alors les liaisons multiples pour que les développeurs possèdent dans leur espace de travail :

le code de l'application en cours de réalisation

le code du framework utilisé

Problème avec TFS 2005

Le problème survient lorsque le code du framework doit faire partie de la solution de l' application afin de pouvoir travailler en mode projet sur les références du framework. En effet, il n'est pas possible de définir qu'une entrée du contrôleur de code source soit liée à votre système dans un sous dossier d' un dossier déjà utilisé dans un espace de travail.

Et pourtant, les développeurs ont l'habitude de retrouver dans une solution : 1 ou plusiers fichiers Sln à la racine et les dossiers contenant les projets.

Résolution TFS 2008

Cette limitation n'existe donc plus et nous pouvons donc allègrement définir ce genre de choses :

Soit le projet applicatif SmallBusiness dont voici la structure :

et un projet Framework dont la structure vous est ici présentée :

Nous pouvons maintenant définir un espace de travail permettant à l'équipe SmallBusiness de travailler avec le dossier LogTool directement dans le dossier Main :

Le résultat sur le système de fichier parle de lui même, le développeur pourra attacher très facilement le projet LogTool dans la solution SmallBusiness.sln.

Et la concurrence dans tout çà

Cette nouvelle fonctionnalité fait voler en éclats l'un des arguments de la concurrence. Certes il ne s'agissait pas d'une grosse limitation mais comme elle était âprement critiquée par certaines comparaisons entre TFS et plus particulièrement TFVC avec d'autres contrôleurs de source, certains clients me posaient la question.

Pour preuve, voilà un extrait d'un comparatif disponible ici : http://www.perforce.com/perforce/comparisons/perforce_mstfs.pdf http://www.perforce.com/perforce/comparisons/perforce_mstfs.pdf

TFS does not support sparse branching.
A user can individually “cloak” or “uncloak”
project folders. However, the same set of
files from two different repository folders
(for example, main and branch_x) cannot
be mapped to the same local folder in a
workspace.

Je connais quelques personnes ayant un document à mettre à jour...

Images VPC de test de Visual Studio Team System

2008-04-24T13:34:00Z

Ces images fournies par Microsoft permettent de tester l'intégralité des fonctionnalités de la plate-forme (clients et serveurs). Elles disposent également d'un ensemble d'ateliers permettant de prendre en main le produit.

L'image est disponible ici : http://www.microsoft.com/downloads/details.aspx?FamilyID=c7a809d8-8c9f-439f-8147-948bc6957812&displaylang=en et la dernière version expirera en décembre 2008.

Techdays 2008 - C'est fini pour moi

2008-02-13T09:15:11Z

L'édition 2008 s'achève dès ce matin pour moi. Après avoir donner deux sessions concernant Team System, je suis dès à présent de retour chez nos clients.

J'aimerais remercier tout le monde de l'accueil, l'engouement et la bonne humeur qui marqua cette édition et plus particulièrement les personnes qui m'ont accompagné durant les sessions, Vianney Lemaire d'Artegos et Florent Santin de Winwise.

Les sessions seront probablement disponibles d'ici un à deux mois sur le site média Microsoft.

Bien entendu, l'aventure ne s'arrête pas là et l'on pourra très prochainement se rencontrer, très prochainement...

Mais on y reviendra :D

Gauntlet passera sur TFS

2007-12-13T11:33:06Z

Si cela vous interesse bien entendu...

Construire ses versions à la hache?

Brian Harry vient d'annoncer la bonne nouvelle sur son blog. Le projet Gauntlet trouvera son implémentation dans Rosario, la future version de TFS.

Gauntlet

L'idée de Gauntlet vient modifier le processus de validation des builds dans le cadre de l'intégration (en particulier dans les grosses équipes).

En effet, comme on peut le constater dans TFS 2008 (avec la règle d'archivage "Builds") lorqu'une build qui n'a pas passé les critéres du processus automatisé (échec de compilation, de l'analyse statique, de l'exécution des tests unitaires ou le nom respect des QoS... ) on peut décider de bloquer la chaîne de production en interdisant tous les archivages sur le contrôleur de code source (sauf les tentatives de réparation de la build).

Cette technique trouve son origine dans les processus de Toyota qui stoppe la chaîne de production dès qu'une alerte est émise. Cependant et plus particulièrement dans les grosses équipes de développement ou dans les équipes réparties géographiquement, cette option perd de son sens et est très risquée.

Exemple : Pourquoi retarder la mise à disposition d'une fonctionnalité de l'équipe de Paris parce qu'un archivage de l'équipe de New York a provoqué l'échec de l'intégration continue? D'autant que les développeurs de Paris n'auront pas forcement les moyens d'y remedier pour pousser leurs modifications sur le référentiel.

Un projet communautaire permet dores et déjà tester cette politique : Open Gauntlet

les avantages

La démarche de Gauntlet est tout autre, quasiment l'inverse puisqu'elle revient à dire que si les modifications apportées n'ont pas respecté les critères de sortie d'une version, ces modifications doivent tout simplement être supprimées de la liste des modifications à constuire. On exclut donc le code défectueux pour donner la possibilité aux autres équipes ou autres développeurs de voir leur code être intégré.

Deuxième effet pertinent, l'intégration en tant que telle. Si l'équipe A a fournit un code défectueux et que l'équipe B doit attendre la résolution de ce code pour archiver, l'effort d'intégration reviendra à l'équipe B (qui n'a pour l'instant pas commi d'erreur). En revanche, dans la démarche de Gauntlet et de Gated Checkin de Rosario, l'effort d'intégration sera réalisé par l'équipe A, fautive dans le scénario présent, et avouons que cela semble plus juste.

Entre les lignes

Ce que l'on peut deviner également à la lecture de ce post de Mr Hary, c'est qu'une telle fonctionnalité réclame l'implémentation d'un mécanisme de comparaison des versions de notre projet afin d'exclure l'archive fautive. Cela nous laisse présager de grands changements dans l'avenir de TFVC (Team Foundaiton Version Control) et de Team Build et pourquoi pas les prémisses d'une approche de construction par composant de notre projet. Alléchant...

Fin de semaine de formation

2007-12-07T18:29:48Z

Cette semaine avait lieu, à l'initiative de Microsoft et plus particulièrement d'Eric Le Loc'h, 2 ateliers à destination des consultants des centres de compétences Team System.

Le premier avait pour objectif d'ouvrir de nouvelles possibilités de personnalisation et d'extension des projets d'équipes TFS en introduisant les concepts BI d'Analysis Services et de Reporting Services et leur fonctionnement autour des produits Team System.

Le second avait pour but de préparer au passage de la certification 70-510, concernant l'administration d'un serveur TFS.

Ayant co-animé la première et animé la seconde, j'aimerais remercier les participants pour le partage et l'ouverture d'esprit dont ils ont su faire preuve durant ce stage. Les questions posées étaient toutes pertinentes, la passion et le sérieux au rendez vous, et je dois avouer que donner des formations dans ce contexte fût un réel plaisir.

Un nouveau compagnon Outlook pour Team Foundation Server

2007-10-16T10:18:26Z

Annonce officielle de la sortie de Team Companion par la société Ekobit, plugin Outlook permettant la connexion à votre base de données d'éléments de travail à partir de Microsoft Outlook.

Références Team System

2007-10-04T12:33:00Z

Afin de parfaire votre apprentissage de Team System, voici quelques liens et recommandations de lectures :

Sites

MSDN Team System : le site MSDN France des produits Team System

Team System Rocks : regroupe les posts de blogs les plus interessants concernat Team System

Brian Harry : Le blog du Program Manager le plus actif de Team System qui publie notamment les comptes rendus sur l'utilisation en interne (chez Microsoft) de Team System

Channel 9 - Visual Studio : Découvrez les nouveautés et le futur de la gamme à l'aide des reportages vidéos de Channel 9

Articles

Cyclomatic complexity : La définition du SEI de la complexité cyclomatique que nous retrouvons maintenant dans Visual Studio Team System For Software Developper avec les Code Metrics.

Index maintainability : La définition officielle d'une autre métrique interessante des Code Metrics.

Outils

Power tools : le site des extensions proposées par Microsoft pour Team Foundation Server

Attrice Corporation : auteur des outils Team Foundation SideKicks et Team Build SideKicks

TFS Admin : outil d'administration de TFS

TFS Event Subscription Tool : outil d'abonnement aux évènements TFS

Automaton : outil d'intégration continue

CI par Microsoft : le tutorial et le code associé à la mise en place d'une build continu

Team Build

Community Tasks : Librairie de tâches MSBuild

SDC Tasks : Librairie de tâches MSBuild

Livres

Gestion de configuration

Configuration Management Principles and Practice par Anne Mette Hass et Glenn Hass

The Build Master: Microsoft's Software Configuration Management Best Practices par Vincent Maraia

Software Configuration Management Patterns: Effective Teamwork, Practical Integration par Stephen P. Berczuk, Steve Berczuk, et Brad Appleton

Team System

Visual Studio Team System: Better Software Development for Agile Teams par Will Stott et James W. Newkirk

Software Engineering With Microsoft Visual Studio Team System par Sam Guckenheimer et Juan J. Perez

Professional Visual Studio 2005 Team System par Jean-Luc David, Tony Loton, et Erik Gunvaldson

Tests

Test-Driven Development: By Example par Kent Beck

Test-Driven Development in Microsoft .Net par James W. Newkirk et Alexei A. Vorontsov

Builder une solution à partir d'un Label

2007-08-15T20:47:00Z

Un petit truc dont de nombreux clients ayant fait appel à Team Build pour la construction de leur solution s'étonnent, à savoir la possibilité de modifier le comportement par défaut lors de la récupération des sources. En effet, par défaut, Team Build récupère la dernière version des fichiers composants la solution. Or vous voudriez peut être récupéèer la version correspondant à un label flottant (ex : Production).

Si tel est le cas, il vous faudra effectuer deux choses :

Surcharger la tâche Get de Team Build afin de lui préciser que vous allez vous occuper de la récupération des sources
Appeler la tâche Get en précisant la version souhaitée

Pour surcharger l'étape de récupération des sources, tout est prévu dans Team Build, il suffit d'ajouter un propriété SkipGet dans votre projet de Build :

...

<PropertyGroup>
<SkipGet>true</SkipGet>
...

Ensuite, il ne vous reste plus qu'à récupèrer le code correspondant à votre projet en spécifiant la verison spécifique, ici, je le fais avant la création du label fixe créé par Team Build :

<Target Name="BeforeLabel" >
<Get Condition="" Workspace="$(WorkspaceName)" Recursive="$(RecursiveGet)" Force="$(ForceGet)" Version="LClean@"/>
</Target>

Toutes les propriétés sont celles par défaut sauf pour l'attribut Version. Clean est le nom de mon label flottant permettant de définir les versions à compiler pour la clean build (build intégrale de la solution et exécution de l'ensembles des tests, configurations, automatisations etc...).

Cette propriété prend donc en paramètre : "L" + "<Nom du label>" + "@" + "<Scope>"

Le "L" définit que nous souhaitons récupérer les sources à partir d'un label dont le nom est indiqué. Vous pouvez également récupére le source à partir d'une date ("D"), d'un change set ("C") etc...

Le scope est optionnel et permet de restreindre la récupération des sources (on aurait pu fournir une url du contrôleur de code source, ex : $/mon projet/Main/DAL).

Label Flottant et Label Fixe :

De nombreux contrôleur de code source fournissent un mécanisme permettant de rassembler un ensemble de fichier d'une version particulière sous un nom commun. Les étiquettes de Visual Source Safe sont reprises dans Team Foundation Version Control. Un Label (étiquette) se construit en sélectionnant les fichiers qui le compose mais vous pourez par la suite modifier ces fichiers.

Ainsi, il apparaît que les équipes de développement ou les administrateurs du contrôleur définissent deux types de label :

Label fixe : Définit un fois pour toute, permet de gérer les différentes versions livrées. L'objectif étant de permettre une récupération rapide de la version d'un environnement, actuellement chez un client ou qui a vu une modificaiton notoire. Exemples de noms de labels fixes ( Livraison Mars 2007, Correctif Client Dupond, Publication Site Avril 2006, Main 2.1.0..., Modification provider). Les labels fixes étant par définition, non modifié, sont les seuls garants de récupérer une version stable après un régression.

Label flottant : Définit au fur et à mesure des itérations et de la progression du projet. Le label flottant est une référence pour l'équipe de développement qui lui permet de récupérer une version des sources en rapport à un contexte. Le nom du label flottant n'a en général aucune information temporelle et son contenu évolue en quasi permanence. Exemples de noms de labels flottants (Production, DAL Oracle, Mobile Web Design, Recette...)

Un allié pour les VPC's - Enfin

2007-08-15T20:30:24Z

voilà, je me transforme en VRP le temps d'un post pour vous présenter mon nouveau petit copain (pas de commentaires à ce sujet, je vous prie;) ).

En déplacement assez souvent et ayant besoin d'un stockage important et rapide pour présenter Team Foudation Server dans un environnement virtuel, je luttais depuis quelque temps à transporter mon disque dur externe de 500Go, certes rapide et volumineux mais tellement lourd et pas très joli.

Décidé, je me retrouve en magasin à la recherche d'une solution, caractéristiques demandées : disque dur externe, petit, rapide (7200 tours), stockage d'au moins 100Go, autoalimenté et si possible pas trop moche. Les vendeurs me rient au nez, je repars, et cela dans plusieurs enseignes informatiques. Par dépit, je tente la fnac, et je trouve çà :

Toutes les caractéristiques sont réunies et il intrigue beaucoup (la partie orange sur le côté est lumineuse et clignote pendant l'activité), voire trop, j'ai un collègue qui en a acheté deux en une semaine après avoir vu le mien.

Bref, mon dos se porte bien et mes VPC's respirent, peut être pour mieux vous servir...

TechEd - Keynote

2007-06-04T15:22:01Z

Arrivé à Orlando samedi dernier avec Daniel pour assister au TechEd US, je vous fais part de mes premières impressions après le KeyNote qui s'est déroulé ce matin (8h30 heure locale).

Back to the future

Première et peut être seul nouveauté annoncée lors de cette session, Microsoft comprend la frustration que peuvent éprouver certains de ces utilisateurs et prend un virage en terme de communication en reconnaissant ne pas avoir été aussi pragmatique que certains l'auraient souhaité.

La vidéo d'introduction, parodie de la série des "Retour vers le futur", préfigure la nouvelle stratégie général de Microsoft, on ne parle plus de "Vision" mais de "Plan". Des plans à long termes afin de fidéliser les utilisateurs existants et potentiels.

Agilité au cœur des systèmes

Faire face au changement et montrer davantage de réactivité dans tous les domaines, voilà l'objectif que certains d'entre nous ont d’ores et déjà pris en compte. C'est Tom Bittman de Gartner qui nous a démontré que s'il s'agit d'une recommandation aujourd'***, cet effort deviendra impératif très rapidement afin de répondre aux attentes de nos futurs utilisateurs.

En idée forte de son discours, je retiens particulièrement l'idée que les enfants ont "toujours voulu tout maintenant". Aujourd'***, les enfants peuvent voir ce qu'ils veulent maintenant "VOD", écouter ce qu'ils veulent maintenant et peuvent trouver l'information sur Internet. Cette génération, qui deviendra nos managers et utilisateurs finaux de demain, ne pourront souffrir de délais interminables et souhaiteront voir exhausser leurs besoins sous forme de fonctionnalité très rapidement.

Mise en place

Une demi-douzaine de démonstrations ont tenté de mettre en évidence comment les produits de Microsoft permettront de mettre en place des processus agiles et d'accroitre la réactivité des IT's, des DBA's et des développeurs.

De la virtualisation et des problèmes de migration ou de changement de topologie (Jeff Woodser) à la mise en place d'applications orientées services ( Mike Woods) en passant par l'amélioration des communications entre nos applications et l'infrastructure (Barry Shilmover), le contrôle et l'amélioration des outils et des processus face au changement étaient donc au coeur de ce Keynote.

Un Keynote en demi-teinte tout de même car aucune grande annonce n'est venu édulcorer une présentation et un discours certes important et stratégique mais pas en soit super sexy.