Category : Urban Turtle

Urban Turtle 3.0 Release Candidate

The Urban Turtle team is proud to finally present the release candidate of our Agile Project Management extension to Team Web Access 2010: Urban Turtle 3.0. This new version sports a brand new look, a streamlined user interface and full support for Team Foundation Server 2010. Make sure to download it and request a free 30-day trial, you’ll find that you can’t do Agile in TFS 2010 without Urban Turtle.

In the last few months, we’ve spent quite some time working on our template support. Out of the box, Urban Turtle supports the MSF Agile 5.0 process template. We’re actually quite proud to introduce what we think is the first and only 3-column task board to work with MSF Agile 5.0 without any modifications.

Urban Turtle 3.0 Task Board

But what’s even better is that we support virtually any process template through an xml mapping file. We already provide one such file to support MSF Agile 5.0, but new ones can be added to support your own template.

We’re aiming to sim-ship alongside Team Foundation Server 2010 which has just been made available, meaning the RTM version should be ready before the end of the month. Right now, the release candidate has only been tested with TFS 2010 RC. We recommend using Microsoft’s virtual machine to try Urban Turtle 3.0 RC.

We hope you enjoy this latest release, and please do provide some feedback so that we make the turtle even better!

Surveiller un serveur TFS

images

 

Basées sur mon expérience et les différentes installations que j’ai pu rencontré, voici mes recommandations concernant la supervision d’un serveur TFS.  Celles ci ne sont pas exhaustives et doivent être majorées suivant votre topologie et les ressources matérielles de votre serveur. J’attends vos éventuels retours afin de préciser ce billet.

 

Quelque soit l’outil de supervision ou les procédures que vous voici une liste non-exhaustive des points que vous devez surveiller sur votre serveur TFS.

 

Configuration matérielle

 

Consommation CPU : dépend du nombre d’utilisateurs actuellement connectés. Une forte consommation CPU peut survenir lors de la génération du Warehouse et/ou de la consultation des rapports et de Sharepoint. Sur une heure, une consommation inférieure à 30% du CPU devrait représenter un comportement normal.

Consommation mémoire : Une forte consommation mémoire peut être observé sur une instance unique (AT + DT), cela est causé par SQL Server 2005 qui prend ses aises.

Espace disque : Dépend fortement de la volumétrie (nombres de projets d’équipe). Une partition système doit disposer d’au moins 4Go de libre afin d’accueillir les MSI de mise à jour, la partition de données ne devrait pas excéder 50% d’espace occupé.

Connectivité : les adresses IP de la machine sont elles celles attribuées lors de l’installation. Le nom de la machine est il celui d’origine.

 

 

IIS

 

Les sites Web suivants sont ils démarrés?

 

Default Web Site

Sharepoint Central Administration v3

Team Foundation Server

Team System Web Access

 

Les pools d’applications suivants sont ils démarrés?

 

Microsoft Team Foundation Server Application Pool

ReportServer

TFS WSS

DefaultAppPool

Sharepoint Central Administation V3

TswaPool

 

Vérifier les en-têtes d’hôte et les éventuels certificats .

 

Services Windows

 

Les services suivants sont ils démarrés?

TFSServerScheduler

SharePoint Timer Service

 

Journaux d’ événements

 

Surveiller toutes les entrées concernant Team Foundation Server bien sûr (Erreur TFXXXXXX) mais également celles liés à SQL Server et surtout à son agent (Sauvegardes), à Sharepoint et à Reporting Services. Vous pouvez également considérer tous les erreurs provoqués lors de l’exécution d’une application par les différentes comptes de services de TFS.

 

Les alertes concernant Team Foundation Version Control et Team Foundation WorkItem Tracking sont considérées comme critiques. Les alertes concernant  TfsWarehouse et Reporting Services sont sérieuses.

 

SQL Server

 

Les services suivants sont ils démarrés?

 

Database Services

Analysis Services

Reporting Services

SQL Server Browser

SQL Server Agent

 

Les dernières exécutions des sauvegardes se sont elles bien déroulés?

Vérifiez la présence des fichiers et l’historique des jobs SQL Server.

Erreur 32000 lors de la migration de TFS 2008

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…

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

 

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.

 

FileSystem

 

 

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…

Images VPC de test de Visual Studio Team System

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.

Gauntlet passera sur TFS

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…