Lors des techdays 2012 à Paris, j’ai eu le plaisir d’animer une session de présentation des nouveautés de Visual Studio 11 et Team Foundation Server 11 avec Florent Santin.

La vidéo est enfin en ligne !

Vous pouvez le retrouver ici : http://www.microsoft.com/france/mstechdays/programmes/parcours.aspx#SessionID=83357591-85b1-4b20-8a83-aa912f8dc108&fbid=XQNOAiwOs2V

Les slides sont disponibles ici : http://www.slideshare.net/Microsoft_France/les-nouveauts-de-visual-studio-11

Bientôt un billet plus consistant ! ;)

.Dispose();

J’ai récemment eu un problème pour obtenir l’intelliTrace sur un site web dans IIS. Il n’y avait pas de message d’erreur, rien dans le journal d’évènement Windows, et après 3 appels à une voyante, 2 visites chez un marabou, j’ai failli me résigner… jusqu’à ce que je tombe sur ce KB : http://support.microsoft.com/kb/2547655 qui indique que : “Le SP1 de Windows 7 peut causer un échec de la collection de l’intelliTrace.”

Soit.

La correction est assez simple à appliquer. Il suffit de :

• Modifier le fichier applicationHost.config
• Chercher dans <applicationPools> le pool d’application dans lequel tourne le site pour lequel on veut récupérer l’intelliTrace
• Modifier setProfileEnvironment="false" en setProfileEnvironment="true"

Et bim, ça marche :-)

En espérant que ça peut vous permettre d’éviter de perdre du temps!

.Dispose();

Le lab management permet de connecter TFS à un environnement de virtualisation Hyper-V. Avec TFS 2010, il est nécessaire de posséder un server Hyper-V et de passer par System Center Virtual Machine Manager.

Dans TFS 11, ceci ne sera plus une obligation pour activer les fonctionnalités associées au lab management de déploiement et d’exécution de test. On peut partir d’un serveur classique (virtualisé ou physique) possédant ce qu’il faut pour faire tourner notre application et simplement l’inclure dans un environnement de type Standard. C’est le Lab Center de Test Manager qui se charge de déployer les agents de tests et de build.

Tout devient plus simple et il est surtout plus facile d’intégrer le lab management dans un environnement existant !

Plus de détails sur le blog de Brian Harry : http://blogs.msdn.com/b/bharry/archive/2011/10/31/lab-management-improvements-in-tfs-11.aspx

.Dispose();

Note : Ce billet fait partie d’une série plus complète sur les nouveautés apportées par TFS 11.

Le projet de l’équipe les barbus démarre et les développeurs commencent à travailler. Dans Visual Studio, le nouveau Team Explorer, permet d’accéder à son travail via My Work :

Via cette interface, on accède au tableau de bord quotidien du développeur. Celui-ci est filtré pour chacun en n’affichant que ce qui le concerne directement.

Lorsque je désire commencer à travailler sur une tâche, je l’ajoute au travail en cours de réalisation. Ceci est à mon sens une différence majeure en terme de logique d’utilisation de TFS par rapport à la version précédente: j’indique ce que je veux faire au moment ou je commence, et non pas au moment ou je l’ai terminé (lors du checkin). Ceci est une approche beaucoup plus évidente.

Après avoir réalisé les modifications dans le code source que j’estime nécessaires à la réalisation de la tâche que j’ai choisie, je m’apprête à archiver mes modifications. La fenêtre My Work affiche un résumé des modifications réalisées :

En cliquant sur View changes je visualise le détail de mes modifications.

L’équipe des barbus à décidé de faire relire le code de chacun par un autre membre de l’équipe, pour éviter les fautes d’inattention. De ce fait, plutôt que de réaliser un checkin à l’instant, je décide de demander à Léonard d’effectuer une review :

Je peux alors lui préciser un commentaire et c’est parti !

A partir de ce moment, lorsque léonard visualise la page My Work il retrouve ma demande de review :

En double cliquant sur ma demande, Léonard obtient une page la détaillant. Il accepte alors ma demande :

Comment ça marche? Léonard va être capable de visualiser mes modifications sans pour autant que j’ai eu besoin de réaliser un archivage. En effet, il est important qu’il puisse valider mon code avant que je ne l’ai partagé avec le reste de l’équipe dans TFS. Lorsque j’ai cliqué sur la demande de review, le Team Explorer 11 à enregistré mes modifications dans un Shelve (mise sur étagère ou “réservation” en Français). L’avantage ici, est que ce type d’opération est transparente.

Au sein de la même fenêtre, léonard a accès à l’ensemble des fichiers que j’ai modifié / créé. Il peut visualiser les différences entre ceux-ci et me donner son avis via des commentaires fonctionnant sur le même concept que les commentaires de Word (ligne par ligne) :

Lorsqu’il a terminé la relecture, il indique que tout est ok (ou pas, suivant son analyse ! ;)) :

De mon côté, je peux visualiser en temps réel les commentaires que Léonard réalise sur mon code, lui répondre si besoin, et voir quand il a terminé de relire :

Je n’ai alors plus qu’a choisir si je veux abandonner ou réaliser la modification dans le contrôle de code source.

Une fois le checkin réalisé, la tâche est fermée, et elle n’apparait plus dans My Work :

Même si cela paraitra évident, il est important de comprendre que tout au long de mes modifications, l’état du work item sur lequel je travaille se met à jour, et que cela a un impact dans la visualisation des post-its au sein du site web. Maintenant que le travail est considéré comme terminé, le work item se retrouve dans la colonne de droite :

Remarquez d’ailleurs le rapport de burndown en haut à droite de la page. Lorsque l’on clique sur l’image, elle donne accès à un rapport plus détaillé :

Mon analyse de tout ça est que TFS 11 apporte une dimension très importante en terme d’ergonomie. La plupart des opérations que vous avez lues tout au long de cet article auraient pu être réalisées avec la version 2010. La différence réside dans la facilité avec laquelle ces opérations se font. Si je veux demander à quelqu’un de relire mon code dans la version 2010, je dois réserver mon code, prévenir la personne qui doit déreserver le code, etc. En TFS 11, je clique sur “Obtenir un relecteur” et tout se fait pour moi.

TFS 11 est la version de la simplicité, la version de l’abstraction. Un besoin simple est derrière tout ça : “Je ne veux pas que tu m’explique comment je dois faire pour réaliser quelque chose, je veux juste le faire”.

.Dispose();

En parallèle de ma série de billets sur la prochaine version de TFS, je vous invite à télécharger la machine virtuelle mise à disposition depuis quelques heures par Brian Keller ici : http://blogs.msdn.com/b/visualstudioalm/archive/2011/09/16/visual-studio-11-developer-preview-virtual-machine-with-hands-on-labs-demo-scripts-now-available.aspx

Au delà de vous faire gagner du temps par rapport à l’installation, la vraie raison est qu’elle contient des données de démos, des ateliers qui peuvent aussi vous êtes utiles pour réaliser des démos :)

Amusez-vous bien.

.Dispose();

Note : Ce billet fait partie d’une série plus complète sur les nouveautés apportées par TFS 11.

Rappel : l’équipe Les barbus démarre un projet de développement d’application Windows 8. L’administrateur a créé l’espace pour l’équipe dans TFS, elle veut maintenant planifier le premier sprint.

Dans l’interface d’administration du projet, le responsable de l’équipe ajoute un premier sprint à la première release :

Nouveauté de la version 11, il est maintenant possible de définir une date de début et de fin pour une itération ! Ceci permet d’afficher automatiquement des rapports corrects de Burndown notamment :)

Dans l’interface d’administration de l’équipe, le responsable choisit le sprint qu’il vient de créé et l’assigne comme itération courante.

Maintenant que le sprint est sélectionné pour l’équipe, il est nécessaire d’ajouter les premiers éléments du backlog global du projet. Pour cela le responsable (en général nommé product owner) utilise le site du projet.

Note : il est également possible de faire ces ajouts à partir de Visual Studio et Excel, comme dans les versions précédentes.

Il assigne le User Story (fonctionnalité) au Sprint 1 et enregistre :

Cette liste est en général globale au projet, et est alimentée en continu. A l’heure actuelle, le product owner n’a qu’une liste restreinte, mais peu importe, le projet peut démarrer !

A partir de là, tout se fait dans le portail dédié à l’équipe !

Dans la section backlog en sélectionnant Sprint 1, l’équipe visualise l’ensemble des User Stories présentes dans le sprint en question. On peut remarquer que le travail en heures (WORK (0 h)) est à 0 car aucune tâche n’a encore été assignée aux User Stories.

Après avoir ajouté les tâches à chacune des User Stories (en utilisant le bouton + bleu), l’équipe a une vision complète de ce qu’elle est nécessaire de faire.

Note : il est possible d’ordonner les éléments du backlog en effectuant un drag’n’drop vers le haut ou le bas.

Importante nouveauté également, la possibilité de définir combien de temps par jour sont disponibles chaque membre de l’équipe pour ce projet. On peut également préciser les dates pour lesquelles chaque personne n’est pas disponible (congés, autre projet, etc.):

Deux vues permettent alors dans la section board de visualiser l’état des tâches.

• Par User Story (notez la possibilité d’effectuer un drap’n’drop pour changer l’état dans TFS !) :

• Par membre de l’équipe (la sauvegarde suite à un drag’n’drop se fait en asynchrone, de manière transparente) :

L’équipe à bien démarré le projet, les tâches sont en cours !

Mon avis sur le sujet : La nouvelle ergonomie apporte une fluidité dans le travail au quotidien. On prend très rapidement les réflexes et on se retrouve très facilement dans l’interface quand on a compris les 2 ou 3 concepts de base. Je pense que c’est une avancée énorme en termes de productivité !

.Dispose();

Note : Ce billet fait partie d’une série plus complète sur les nouveautés apportées par TFS 11.

Depuis toujours, TFS fonctionne avec un principe de groupes de sécurité dans lesquels on ajoute des utilisateurs pour leur donner les droits associés au groupe. C’est plus ou moins grâce à cela que l’on peut représenter une équipe dans TFS jusqu’à la version 2010. Le problème de cela, c’est qu’il s’agit bien de groupe de sécurité et que la notion d’équipe s’arrête au titre que l’on donne au groupe.

TFS 11 apporte justement cette notion d’équipe. Pour la comprendre, il faut s’imaginer un groupe avec des propriétés supplémentaires. Une équipe est constituée d’un ou plusieurs membres et on peut lui associer des informations telles que l’itération sur laquelle elle travaille, les jours de disponibilités des membres (peut être qu’ils travaillent aussi sur d’autres choses, ou qu’ils prennent des congés), etc.

Avant de rentrer dans les détails du concept d’équipe, voici une présentation rapide du nouveau site (web access) de TFS 11. Il est constitué principalement de 3 vues :

• Le site classique, qui correspond fonctionnellement à ce que l’on avait précédemment:
• Voir / modifier les work items
• Consulter les sources
• Exécuter / Consulter les builds

• Le site d’administration, qui est bien distinct du site des utilisateurs et qui offre énormément plus de possibilités que ce que l’on pouvait faire à ce sujet dans les versions précédentes

• Le site d’équipe, qui n’existait pas auparavant. Son rôle est de présenter à chaque équipe l’ensemble des informations qui la concerne et uniquement celles-là. Chaque équipe a accès à son backlog (liste des fonctionnalités à développer), à une vue sous forme de post-it drag’n’droppable, et bien d’autres choses.

Pour bien comprendre le principe d’équipe dans TFS, je vais imaginer un “cas concret” avec une équipe que l’on va appeler Les barbus qui démarrent un projet d’une application pour Windows 8 avec un style metro et qui permettra de se connecter à TFS et d’afficher un tableau de bord interactif.

Via le lien Manage teams and project groups sur la page d’accueil du projet, l’administrateur créé une nouvelle équipe :

Il nomme l’équipe et l’ajoute au serveur TFS :

Il ajoute les différents membres :

Il défini de quelle(s) area(s) l’équipe est en charge (potentiellement tout le projet):

Et l’itération sur laquelle ils vont travailler sera définie plus tard, par l’équipe au fil de l’avancement des projets.

L’équipe est désormais créée et les membres peuvent commencer à travailler :

Attention : Il est important de comprendre que l’objet Team n’a pas pour vocation de remplacer les groupes de sécurités classiques. Des “teams” peuvent faire partie de groupes pour obtenir des droits associés.

Le billet suivant traitera de l’utilisation du site par l’équipe !

.Dispose();

Note : Ce billet fait partie d’une série plus complète sur les nouveautés apportées par TFS 11.

La première chose que l’on peut remarquer quand on lance pour la première fois Visual Studio 11 est que le team explorer (TE 11) à été complètement revu en termes d’interface. L’actuel (TE 10) présente les informations sous forme d’arborescence tandis la navigation au sein de TE 11 se fait via différentes pages accessibles par des liens:

Notez au passage l’apparition d’une zone de recherche pour trouver un work item. “Enfin” n’est-ce pas ?

• Work Items donne accès à l’arborescence classique des requêtes sur les work items. Vous pouvez remarquer le nouveau design pour les fiches de Work Item (ici la création d’une tâche) sur lequel je reviendrais plus tard:

• La fenêtre des pending changes a été également revue. Plus de dialogue modal comme dans TE 10, et une arborescence affichant les fichiers modifiés permet de beaucoup mieux se rendre compte de ce que l’on visualise :

• La fenêtre des builds permet désormais de filtrer sur les définitions pour rechercher facilement celle qu’on souhaite exécuter. Toujours pas de répertoires pour organiser les builds cependant il est possible d’en épingler certaines (comme permettait déjà de faire les power tools dans TE 10). Les builds en cours d’exécution que j’ai lancé s’affichent dans la section My Builds : assez pratique pour ne pas avoir à ouvrir la fenêtre de file d’attente générale. Une icône indique quel type de déclencheur est associé à la build (manuel dans l’exemple ci-dessous) :

• Les sections Documents et Reports n’offrent que peu de différences par rapport à leurs équivalents TE 10 si ce n’est qu’ils sont affichés dans des pages distinctes.
• La fenêtre de configuration Settings en revanche est complètement différente. On passe d’une boite de dialogue modale à une liste de liens amenant vers les différents éléments configurables. Une grande partie de ces liens amènent vers le site web. Je reviendrais sur le site en détails à travers mes différents billets, mais j’ai l’impression que l’équipe produit veux donner une place beaucoup plus centrale à celui-ci qu’il n’avait par le passé. Ceci est certainement lié à l’apparition de Team Foundation Service (TFS hébergé dans Azure par Microsoft) qui nécessite plus d’administration via un site web (certaines choses n’étant pas réalisables à distance).

• La section My Works est certainement la plus intéressante. Je ne vais pas m’attarder sur celle-là car elle fera l’objet d’un billet complet, mais il faut comprendre que c’est le point d’entrée du flux de travail du développeur. Contrairement à la version précédente dans laquelle je précise le work item sur lequel je travaille uniquement à la fin du développement (lors du checkin), la version 11 permet d’indiquer le démarrage d’une tâche, de mettre en pause le travail, de le reprendre facilement, etc.

Voilà pour un premier aperçu qui annonce de très bonnes choses pour cette version ! :)

.Dispose();

Maintenant que TFS 11 est disponible en preview, il est temps de voir ce qu’il y a sous le capot. :) Même si on avait déjà accès à un livre blanc et des captures d’écran ou encore de nombreuses communications de la part de Brian Harry, c’est toujours mieux de cliquer soi-même!

Je commence une série de billets qui vont vous permettre de découvrir les nouveautés notables sur les différentes fonctionnalités.

Voici une liste que je mettrais à jour au fil de l’écriture :

• TFS 11 – Découverte du nouveau Team Explorer
• TFS 11 – La nouvelle notion d’équipe
• TFS 11 – Démarrer le premier Sprint
• TFS 11 – Le nouveau flux de travail des développeurs
• TFS 11 – La nouvelle notion de feedback
• TFS 11 – Nouveautés pour Test Manager

“Et tu ne parles pas de Team Foundation Service ?” Me direz-vous? Les fonctionnalités sont exactement les mêmes à l’heure actuelle entre les deux versions, l’intérêt du service (qui est la version TFS hébergée dans Azure) est de simplifier les aspects d’administration et d’installation, au delà de ça, rien ne diffère si ce n’est que la version en ligne n’offre pas les services de Documents (sharepoint) ni de Reporting Service.

Stay tuned ! :)

.Dispose();

Ca y est ! On attendait ça depuis longtemps ! :)

Brian Harry annonce la disponibilité pour les abonnés MSDN de la preview de TFS et VS vNext. A ma grande surprise, il s’agit d’iso d’installation et non pas d’une machine virtuelle, alors que l’équipe produit nous avait toujours habitués à une preview sous ce format. On va pouvoir s’amuser un peu.

Mickey Gousset à blogué sur l’installation de TFS et sur celle de VS si cela vous intéresse.

J’installe ça dès que le download est fini et je vous fait un retour des mes impressions ! :)

.Dispose();

J’ai déjà twitté (@emargraff) à propos de ça, mais je pense qu’il s’agit d’un sujet tellement attendu et une modification tellement importante dans la manière d’appréhender la gestion du contrôle de code source avec TFS que je me suis dit qu’une explication plus longue valait le coup :)

Team Foundation Server existe depuis 2005 et 3 versions ont déjà vu le jour. L’objectif de TFS est bien plus large que la gestion des sources de l’application, tout son intérêt réside dans le fait que l’intégralité du processus de création de logiciels est prise en compte. La définition des spécifications, le découpage en tâches, le suivi d’anomalies, la création de campagnes de tests, l’automatisation des builds ou encore le reporting sont autant d’aspects gérés par la plateforme. L’intégration qui existe entre ces différentes fonctionnalités est certainement la raison principale du nombre important et toujours croissant d’équipes qui choisissent cette plateforme comme outil de collaboration.

Si je parle de tout cela, c’est qu’il est important de prendre ces aspects en considération lorsque l’on évalue TFS. Très souvent, les développeurs m’expliquant les raisons pour lesquels ils ne sont pas toujours complètement satisfaits par TFS ne connaissent et n’utilisent que la partie de gestion du code source. Aie ! ;) Ceci est une erreur à mon avis. TFS est bien plus que cela et si cela vous intéresse je pourrais vous expliquer en détails pourquoi je suis convaincu que c’est la solution la plus complète et le choix le plus judicieux en termes d’outils ALM à l’heure actuelle.

Les reproches faits au contrôle de code source actuel le sont généralement par d’anciens utilisateurs de Subversion. Pour comprendre ce qui les dérange, rappelons le fonctionnement de TFS sur cet aspect.

Les sources d’un projet sont stockées dans le serveur TFS. Pour pouvoir travailler sur les fichiers de ce projet, il est nécessaire de définir un workspace (espace de travail). Un workspace est un objet géré par le serveur, qui contient un certain nombre d’informations :

• L’ensemble des mappings (liaisons) entre un ou plusieurs répertoires sur le serveur, et le ou les répertoires sur mon poste, là ou je veux les stocker pour pouvoir les modifier
• La liste des modifications en cours dans l’espace de travail
• La version de chacun des fichiers que j’ai localement

C’est l’espace de travail qui contrôle ce qui se passe en local, sur mon poste. Quand je veux travailler sur un fichier, il faut que je notifie au préalable le serveur de mon intention. Cette opération peut être réalisée explicitement ou implicitement lorsque je modifie le fichier dans Visual Studio, mais elle est obligatoire dans tous les cas. Pour savoir si un fichier est en cours de modification et pour m’éviter d’effectuer des changements sans notification (appelée “Extraction” ou “Check Out” en anglais), TFS utilise l’attribut de lecture seule des fichiers. Cela ne concerne pas que la modification, mais également l’ajout d’un fichier. L’ajouter dans le répertoire local de mon workspace ne suffit pas, il est nécessaire de prévenir le serveur avec une opération d’ajout indiquant que je veux que celui-ci soit ajouté au contrôle de code source.

Ce comportement a également un impact sur la gestion du mode offline de TFS. Lorsque mon poste n’a pas accès au serveur pour une raison X ou Y, je dois passer en hors ligne (ce qui nécessite un redémarrage de Visual Studio, sauf si vous utilisez le plugin “Go Offline”, qui ajoute un bouton magique !). Du fait que toutes les informations sont stockées dans le workspace, sur le serveur TFS mes possibilités d’actions sont très limitées lorsque je travaille hors ligne. Je ne peux pas comparer mes modifications avec la version de laquelle je suis parti, je ne peux pas effectuer des opérations d’ajout de fichiers, supprimer un fichier, ou annuler mes modifications.

Tous ces comportements critiqués par les adeptes de Subversion (et par d’autres) peuvent effectivement avoir un impact sur le travail de certains profils de développeurs itinérants qui se retrouvent souvent face à ce type de situations. Les raisons énoncées par l’équipe de développement du produit sont principalement liées aux performances et à la scalabilité apporté par ce système.

C’est là qu’arrive TFS 11 (nb : il s’agit du numéro de version. “11” n’a pas de rapport avec l’année de sortie.). TFS 11 apportera un ensemble de nouveautés non négligeables dont vous pouvez déjà avoir un aperçu depuis quelques semaines, dans le livre blanc téléchargeable ici: http://www.microsoft.com/visualstudio/en-us/roadmap.

Brian Harry à récemment fait une annonce sur son blog concernant un nouveau type de workspace qui apparaitra dans la prochaine version : les “Local workspaces”. Grâce à cela, TFS n’est plus le maitre de toutes les décisions, et laisse la liberté à l’utilisateur d’effectuer des modifications localement, sans que celui-ci n’ai besoin de le prévenir. Autrement dit, je pourrais effectuer les modifications qui me plaisent et TFS réagira à ces opérations. Dans le cas où il ne saura pas quoi faire, il me posera la question.

Principalement, ce qu’il faut noter :

• Plus de readonly en local. Je fais mes modifications, TFS comprendra que je modifie le fichier sans que je le prévienne
• Si j’ajoute un fichier en local, TFS le détectera et me proposera de l’ajouter
• Indirectement : si j’utilise un autre outil que Visual Studio pour modifier un fichier, plus besoin de plugin pour interagir avec mon workspace!

Cela aura également un impact important (et positif) sur le mode hors ligne:

• Plus jamais ces popups insupportables me demandant si je veux enlever le readonly sur le fichier quand je commence à la modifier
• Je pourrais faire un diff avec la version à partir de laquelle je suis parti dans mon workspace
• Je pourrais annuler mes modifications sans être connecté au serveur (il reviendra alors dans la dernière version que j’avais récupéré du serveur)
• Je pourrais voir mes modifications en cours même en mode offline
• Les opérations de suppression, renommage et d’ajout seront également possibles

Je peux vous citer une liste interminable de personnes qui seront ravis d’apprendre ça ! :-) C’est à mon sens une liste de modifications qui amène la brique de gestion de code source de TFS à une maturité encore plus grande.

Derniers résistants, toujours utilisateurs de Subversion, plus aucune excuse pour passer à TFS! ;-)

Dans son billet, Brian fait une parenthèse sur le fait que non, ceci ne fait pas de TFS un DVCS. Les DVCS (Distributed Version Control System) sont une autre manière d’appréhender la problématique de contrôle de code source, en intégrant la notion d’historique local. Le plus connu est Git. Il précise par contre que cela n’est pas complètement écarté de la réflexion autour de TFS. Simplement, ça ne sera pas pour TFS 11!

Dernier point, important : les workspaces tels que nous les connaissons actuellement ne disparaitront pas. Les workspaces locaux seront le mode de fonctionnement par défaut, mais le mode actuel restera une solution possible pour les cas lors desquels ils seront utiles.

.Dispose();

Depuis la première version de TFS, il est possible de définir un serveur SMTP. Ceci permet aux utilisateurs de mettre en place des alertes pour être avertis de certaines opérations sur le serveur (en général en relation avec le contrôle de source, les éléments de travail et les builds).

Par défaut, l’interface de la console d’administration de TFS ne permet pas de définir un port différent de 25 pour le serveur. Dans le cas ou vous n’avez pas la main sur le port sur lequel le serveur SMTP écoute, il faut ruser… Pour cela, il faut modifier le fichier XML "%programfiles%\Microsoft Team Foundation Server 2010\Application Tier\TFSJobAgent\TfsJobAgent.exe.config".

Dans le fichier, on ajoute le nœud XML suivant en remplaçant le port par celui de notre serveur et le tour est joué !

<system.net>
  <mailSettings>
    <smtp >
      <network host="MySmtpServer" port="26" />
    </smtp>
  </mailSettings>
</system.net>

… du moins, le tour était joué. Est alors arrivé l’outil Team Foundation Server Backups permettant de simplifier notre vie pour les sauvegardes. Lorsqu’on le configure, il est possible de définir un serveur SMTP (c’est d’ailleurs par défaut celui configuré dans TFS). Grâce à cela, on peut recevoir un mail lorsque les backups échouent. Le problème, c’est que c’est l’outil de backup qui envoie le mail et non pas l’agent TFS comme c’est le cas pour tous les autres types d’alertes. Et l’outil utilise le port par défaut (25)… retour à la case départ :)

La solution qui fonctionnera dans tous les cas, c’est de faire une redirection de port en utilisant netsh, puis de faire pointer la configuration sur l’ip local sur le port 25. Les demandes seront alors redirigées vers le vrai serveur, sur le bon port.

La commande est la suivante :

> netsh interface portproxy v4tov4 add listenport=25 listenaddress={LocalIP} connectport={PortDestination} connectaddress={ServeurSmtp} protocol=tcp

NB : Pensez à retirer la modification dans le fichier XML si vous l’aviez fait (pour que ça fonctionne également sur TFS).

Et voilà !

.Dispose();

Un petit post pour vous parler d’un outil tout récent, créé par Arnaud Fontaine (Microsoft France).

Celui-ci permet d’effectuer facilement un ensemble d’opérations souvent complexes, telles que l’affichage de l’historique complet d’un ChangeSet à travers les branches. L’outil s’appuie sur le format DGML pour afficher les graphes nécessaires.

N’hésitez pas à tester et faire vos retours sur les améliorations possibles ! :)

http://tfhisto.codeplex.com/

.Dispose();

Vous le savez peut-être, actuellement se déroule la conférence des Teched aux USA. C’est l’occasion d’annoncer pas mal de nouveautés pour la prochaine version de la gamme de produit Visual Studio !

Les nouveautés les plus importantes se retrouve au niveau de :

• L’ajout de la notion de feedback, qui s’approche pas mal des tests fonctionnels déjà disponibles avec Test Manager, mais en version plus libre (et accessible à travers l’interface Web !!

• Une nouvelle interface web optimisée pour travailler de façon agile

• Un nouvel outil pour réaliser des maquettes intégré directement à PowerPoint ! Une bibliothèque d’éléments visuels est disponible pour imaginer les applications que l’on souhaite. L’avantage est qu’on obtient directement une présentation de l'application qu’on veut réaliser prête à l’emploi.

• Les tests unitaires complètement revus également, avec une nouvelle interface d’organisation

• On continue pour Visual Studio avec un outil de code review permettant de comparer et annoter le code BEAUCOUP plus facilement

• Une intégration avec les outils d’administration et de suivi des applications en production pour remonter les anomalies de production directement aux équipes de développement, avec les informations nécessaire à la résolution du problème.

• La mise en place avec TFS d’un flux de travail plus poussé pour le développeur qui permet de se mettre dans un contexte de travail, de l’arrêter et de redémarrer dans le même état par la suite

• Et tout un tas d’autres nouveautés, comme les images dans les champs des work items, etc.

Vous l’aurez compris, on parle ici d’une version aussi énorme que la 2010 !!

Vous pouvez obtenir plus d’informations ici : http://bit.ly/kml72s

Bonne lecture,

.Dispose();

L’équipe produit de Visual Studio, comme à son habitude, à mis à disposition de la communauté une machine virtuelle permettant de tester l’intégration entre Team Foundation Server 2010 et Project Server.

L’avantage est que vous avez une solution clé en main de validation et que vous pouvez vous concentrer sur le test des fonctionnalités sans perdre de temps sur l’installation.

Le lien vers le blog de Brian Keller pour la machine virtuelle : http://blogs.msdn.com/b/briankel/archive/2011/04/15/getting-started-with-the-team-foundation-server-2010-and-project-server-2010-integration-virtual-machine.aspx

Plus d’information sur l’intégration entre les deux outils : http://blogs.msdn.com/b/bharry/archive/2011/03/08/vs-tfs-2010-sp1-and-tfs-project-server-integration-feature-pack-have-released.aspx

Il n’y a plus qu’à essayer !

.Dispose();

Très souvent, je suis face à une incompréhension voire une mauvaise compréhension des possibilités de reporting offertes par la plateforme Team Foundation Server 2010. Souvent, elle est associée à tord à SharePoint. Bien qu’elle puisse y être liée, il est possible d’avoir du reporting sans SharePoint.

Reprenons les bases :

Team Foundation Server 2010 contient une base de données opérationnelle qui est utilisée en “live” pour toutes les opérations classiques (contrôle de source, éléments de travail, build, tests, etc.). Celle-ci est optimisée pour les actions de tous les jours, mais n’est pas adaptée à la création de rapports. C’est pour cette raison qu’elle alimente une base de données dé-normalisée. Cet entrepôt (warehouse) permet d’effectuer des premiers rapports et est utilisé dans certains de ceux que l’on retrouve par défaut. Pour plus de performance et pour pouvoir effectuer instantanément des croisements d’informations poussés, cette base de données alimente une base multidimensionnelle (un cube OLAP SQL Server Analysis Service).

Voici un schéma tiré du site msdn résumant ces échanges de données :

Vous pouvez remarquer deux choses sur cette représentation :

• Les données sont transformées et transmises vers le Warehouse à l’aide d’adaptateurs (pour information il est possible d’en développer de nouveaux pour ajouter des données provenant d’ailleurs)
• Les données préparées pour le reporting et contenues dans le cube peuvent être exploitées par
• SQL Server Reporting Services
• Microsoft Excel

Le deuxième point est très important : pas besoin de SharePoint pour générer des rapports !

Quel outil de reporting dois-je utiliser ? Cela dépend de vos besoins.

• Reporting Service est un site web contenant des rapports très faciles à transmettre à un utilisateur même s’il n’a pas d’outil installé localement. Cela permet également d’avoir un design plus poussé.
• Microsoft Excel offre plus de souplesse : un simple clic sur le bouton “Rapports” du menu “Equipe” ajouté dans Excel par l’Explorateur d’Equipe permet d’obtenir des graphiques intéressants et quelques minutes suffisent à générer un nouveau rapport.

Quelle interaction avec SharePoint ?

Même si j’ai expliqué que SharePoint n’était pas nécessaire il est très complémentaire et apporte des avantages important. Depuis TFS 2010, en plus de son rôle de gestion documentaire, SharePoint permet de créer des tableaux de bords synthétisant les informations principales du projet. Il est possible de compléter ces tableaux de bords :

• En y ajoutant les rapports provenant Reporting Services
• En y publiant des rapports provenant d’Excel avec les Excel Services (1)

(1) Concernant la publication de rapport Excel, il est important de comprendre que ceci n’est possible que lorsque vous disposez d’une version Sharepoint Server 2010 qui possède la fonctionnalité Excel Services. Sharepoint Foundation ne permettra que d’exploiter les rapport Reporting Services.

Bon reporting !

.Dispose();

Aujourd’hui, une annonce très importante a été faite par Microsoft. Très importante par le fait qu’elle agrandit de manière considérable le nombre de sociétés et d’équipes qui vont être capables de réaliser des tests de charge avec Visual Studio 2010 en conditions réelles, sans surcout de licence!

Avant d’entrer dans les détails, voici un petit historique du mode de prix des tests de charge dans l’univers Visual Studio.

Avec les versions 2005 et 2008, il fallait une version Visual Studio Team Test pour créer et réaliser des tests de charge. Le nombre d’utilisateurs pouvant être simulés était “illimité” (mais bien évidemment dépendant des performances de la machine). Pour pouvoir augmenter la capacité de charge et par là le nombre d’utilisateurs virtuels en parallèle, il fallait acquérir des agents de tests. Les agents étaient facturés par processeurs. L’inconvénient de ceci est qu’il fallait acquérir des machines puissantes pour rentabiliser les agents et leur prix.

Avec la version 2010 apparait un autre mode de fonctionnement : il faut une édition Visual Studio Ultimate pour créer et jouer des tests de charge et il n’est possible de simuler que 250 utilisateurs virtuels en parallèle. Pour augmenter le nombre d’utilisateurs, il faut encore passer par des agents, mais cette fois le prix est fixé par nombre d’utilisateurs simulés. Il faut acquérir un ou plusieurs pack d’utilisateurs virtuels (vendus “par 1000”). La solution est légèrement meilleure, car on peut installer autant d’agents de test que l’on souhaite, mais reste chère pour les petites équipes et toute la puissance des tests de charge n’est pas exploitée à sa juste valeur.

Désormais, il sera possible à n’importe quel détenteur d’une licence Visual Studio Ultimate avec une licence MSDN de réaliser un test de charge avec des agents et de simuler autant d’utilisateurs virtuels que nécessaires !!

Si vous voulez plus d’information sur les tests de charge, je vous conseille de lire

• http://msdn.microsoft.com/fr-fr/vstudio/ee676520 
• ou mon livre qui contient un chapitre sur le sujet !  http://livre.fnac.com/a3349671/Etienne-Margraff-Visual-Studio-2010-ALM

.Dispose();

Vous avez peut être vu passer l’annonce : une nouvelle version des power tools pour TFS 2010 est sortie la semaine dernière.

Pour ceux qui ne sauraient pas, les power tools sont un ensemble d’outils client et serveur qu’il est possible d’utiliser pour enrichir l’expérience utilisateur. On retrouve notamment l’outil Process template editor permettant de modifier très simplement un modèle de processus TFS.

Cette mise à jour corrige/ajoute énormément de choses pour la fonctionnalité de Backup dont je parlais dans un post précédent. Notamment: il n’est désormais plus nécessaire de bidouiller le fichier de configuration pour affecter une période de rétention des backups de moins de 30 jours ! :-)

Quelques ajouts sympas également au niveau de l’extension shell qui permet d’obtenir un mode à la “tortoise” dans le système de fichier Windows. On peut maintenant accéder à l’historique, comparer et surtout… réserver et dé réserver ! (shelve, unshelve).

Côté build, il est possible de cloner une définition de build directement à partir de l’outil en ligne de commande TFPT.exe. C’est tout simplement génial pour gérer des environnement de build où il faut en créer souvent : il suffit d’avoir un modèle et on le clone :)

Vous pouvez trouver une liste plus complète des modifications sur le blog de Brian Harry : http://blogs.msdn.com/b/bharry/archive/2011/03/03/mar-11-team-foundation-server-power-tools-are-available.aspx

Vous pouvez télécharger cette nouvelle version ici : http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f

Et l’extension pour les builds ici : http://visualstudiogallery.msdn.microsoft.com/2d7c8577-54b8-47ce-82a5-8649f579dcb6

.Dispose();

(Update !)

Au sein de TFS, la majorité des modèles de processus contiennent des informations temporelles sur les tâches. L’idée est de permettre au développeur de préciser combien de temps à été estimé à l’origine, combien à été réalisé et combien reste à faire. Ceci est extrêmement pratique pour pouvoir obtenir des rapports vitaux de l’avancement des travaux en cours :-)

Lors d’un archivage (check-in) au sein de TFS, il est déjà possible d’associer les modifications que l’on publie à un élément de travail (très souvent une tâche, ou un bug). La limitation ici est qu’il n’est pas possible facilement de saisir le temps réalisé / restant. On est obligé d’ouvrir la fiche de l’élément pour modifier ces informations… Du coup : on risque d’oublier, voire de refuser de le faire. “Ben ouais, c’est quand même pas pratique !”.

C’est de là qu’est venu l’idée de faire une politique d’archivage permettant de faire ceci ! Une fois installé, une popup s’affiche lors d’un archivage si on a sélectionné une (ou plusieurs) tâche(s) et nous rappelle / permet de saisir le temps !

Vous pouvez trouver cette extension sur le site Visual Studio Gallery : http://visualstudiogallery.msdn.microsoft.com/58ec8802-bd48-4673-a465-4ba099cfbce1

Sur le site des labs d’Infinite Square : http://labs.infinitesquare.com/fr-FR/Projects/TFS/TimeTracking

Le travail à été fait en grande majorité par Wilfried, un grand merci à lui ! ;-)

.Dispose();

Très souvent les personnes avec qui je discute de l’intégration entre TFS et MS Project (version “client”, pas “serveur”) m’indiquent qu’il ne l’utilisent pas car “la publication des dates ne marche que dans un sens” et donc que “c’est bugué !”.

Et bien en fait : non ! C’est un comportement tout à fait volontaire qui peut être aisément modifié.

La liaison entre les champs des éléments de travail et ceux de Project est définie dans un fichier de mapping stocké sur le serveur TFS pour chaque projet. Par défaut, dans ce fichier, certains champs comme la date de début et de fin d’une tâche ont l’attribut “PublishOnly” positionné à “true”. Ceci a pour effet de permettre de publier les dates à partir de Project vers TFS, mais pas l’inverse (i.e. : Un rafraichissement à partir de MS Project ne prendra pas en compte les modifications des dates de TFS effectuées dans Excel ou une autre application).

Pour modifier ce comportement, il suffit de mettre à jour le fichier en question:

- Lancez une Invite de commande Visual Studio 2010

- Téléchargez le fichier en local en utilisant la commande tfsfieldmapping download

- Modifiez le fichier XML et changez l’attribut Publish=”true” à Publish=”false”

- Uploadez le fichier sur le serveur

Tout est bon !

.Dispose();