Ca y est … Les nouveaux Power Tools pour TFS 2010 Béta 2 sont disponibles.
Vous pourrez maintenant donner libre cour à vos personnalisation sans être obligé de tout réaliser directement dans les fichiers XML.
Vous pouvez les récupérer ici.
Bonne customisation …
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.
Afin de donner une petite prestation TFS chez un client, j’ai été amener à installer pour la Nième fois un serveur TFS 2008.
Tant qu’à faire, autant avoir un OS et un SQL 2008 à jour. Connaissant le côté pratique d’une installation sur un serveur SQL 2008, j’avais conservé les sources de TFS mergée avec son SP1 (on me la fait pas…). Tout contant d’avoir tout sous la main, j’ai juste installé le SP1 de SQL 2008 manière d’être à jour.
Et là, c’est le drame… Impossible d’installer TFS 2008 SP1 qui me soutient qu’il n’ai pas compatible avec cette version de SQL.
Un coup d’œil sur internet et je tombe sur le post qui tue qui me renvoi sur la KB de la mort:
http://support.microsoft.com/kb/969985
En résumé, il faut modifier un fichier .xml de l’installation afin de lui dire de ne plus se limiter à la version SQL 2008 mais d’accepter aussi les versions supérieures.
Vive l’installation de TFS 2010, ce genre de bidouilles ne me manqueront pas…
Alan, en mode résigné
Annonce lors de la "Microsoft Project Conference 2009" à Phoenix de la disponibilité, en fin d'année, de la première version publique de la nouvelle mouture du célèbre "MS Project" : Project 2010.
Au programme:
Plutôt qu'une longue liste de nouvelles fonctionnalités, je vous invite à visionner les vidéos de présentation ici.
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 :
Oui, c’est possible.
En effet, si vous avez effectué une migration de TFS 2005 vers TFS 2008 par exemple, vous vous retrouvez avec la configuration suivante:
Pas de problème particulier jusqu’à l’arrivé du SP1 de TFS 2008. Ce service Pack, en plus de mettre à jour TFS, installe le SP1 du .NET Framework 3.5, qui malheureusement, est incompatible avec WSS 2.0.
Vous risquez donc de vous retrouver avec un message d’erreur sur chaque Webpart affiché dans la page du type:
“Web Part Error: A Web Part or Web Form Control on this Web Part Page cannot be displayed or imported because it is not registered on this site as safe.”
Malheureusement, il n’y a pas de solution miracle.
Deux possibilités s’offrent à vous:
1 - Modification du Framework .NET installé (cf..)
2 - Migration de WSS 2.0 vers WSS 3.0
En conclusion, vous n’échapperez pas à la migration de WSS.
