avril 2008Monthly :

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 FilesMicrosoft Visual Studio 2008 Team Foundation ServerToolsTfsDb.exe” upgrade /server:”SERVER” /property:”TFS_SERVICE_ACCOUNT=SERVERTFSSERVICE;TFS_REPORTING_ACCOUNT=SERVERTFSREPORTS;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 FilesMicrosoft SQL ServerMSSQL.2OLAPDataTFSWarehouse.0.dbToday.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…

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.pdfhttp://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…

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.