Visual Studio 11 et TFS 11 preview sont là !

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();

TFS 11 (vNext) – Local Workspaces

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();

TFS 2010 – Utiliser un serveur SMTP avec un port différent de 25

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à ! Sourire

.Dispose();

TFS 2010 – TFHisto, un outil pour comprendre l’historique

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/

006_7

.Dispose();

Visual Studio ALM : NouveautéS pour la prochaine version

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 !!

image

image

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

image

image

  • 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.

image

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

image

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

image

  • 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.

image

image

  • 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

image

  • 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 !! Sourire

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

Bonne lecture,

.Dispose();

TFS 2010–Tester l’intégration avec Microsoft Project Server, c’est simple !

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();

TFS 2010 : Le reporting, ça marche comment ?

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();

Visual Studio 2010 : Changement de mode de licence pour les tests de charge !

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

.Dispose();

TFS 2010–Power tools Mars

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();

TFS 2010–Time tracking check-in policy !

(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 !

TimeTracking

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();

TFS 2010–Pourquoi les dates dans MS Project ne sont pas les mêmes que dans TFS ?

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();

TFS 2010–Simplifier vos sauvegardes

Team Foundation Server 2010 stocke toutes ses informations au sein d’une base de données SQL Server. Il parait bien évidemment vital qu’il faut mettre en place une politique de sauvegarde de cette base de données pour être certain qu’il sera possible de restaurer le tout si jamais le serveur brule / explose / fond / subit une inondation.

Comme toute base de données il est possible de mettre en place un plan de maintenance au sein de SQL Server effectuant une sauvegarde des bases et de le programmer au sein d’un job récurrent. Jusqu’a présent, tout le monde faisait comme ça et devait prendre garde de sauvegarder les bonnes bases.

Les power tools sont un produit gratuit de Microsoft permettant d’ajouter des fonctionnalités supplémentaires pour les utilisateurs de Team Foundation Server. Jusqu’à présent celui-ci ajoutait principalement des éléments côté client (au niveau de Visual Studio principalement). Depuis la version de Septembre 2010, il contient une extension à la Console d’administration de Team Foundation Server qui permet de nous simplifier la vie pour mettre en place la politique de sauvegarde de TFS ! :-)

Dès qu’il est installé sur le serveur, le plugin ajoute un menu dans l’outil d’administration :

image

Il est alors possible de définir en quelques étapes ce que l’on souhaite sauvegarder, à quelle fréquence et de quelle manière :

image

Tout se passe alors en arrière plan, tout seul. Il est également possible de déclencher la sauvegarde manuellement dès qu’on le souhaite.

Un avantage supplémentaire est qu’il est extrêmement simple de restaurer le système TFS. L’ensemble des sauvegardes disponibles est listée, il suffit de choisir et de cliquer sur “Restore” !

image

Attention cependant, il n’est pas possible de configurer la politique de rétention à moins de 30 jours via l’assistant. Il est cependant possible de le modifier après la création du plan de sauvegarde dans le fichier de configuration. Celui-ci se trouve dans le répertoire C:\ProgramData\Microsoft\Team Foundation\Server Configuration et se nomme ConfigPT.xml.

Il suffit de modifier le noeud XML suivant :

<RetentionDays>7</RetentionDays>

… et le tour est joué !

Information intéressante également, si la taille de vos sauvegardes est très importante, vous pouvez suivre la procédure suivante : http://mikefourie.wordpress.com/2010/09/21/minimize-your-tfs-backup-size/

Bonnes sauvegardes ! ;-)

.Dispose();

Industrialiser vos développements PHP avec TFS 2010 c’est possible !

Avant tout, voici un billet de blog après une longue période de rien du tout :-) J’étais plutôt occupé à finaliser l’écriture d’un livre sur les tests logiciels avec Visual Studio dont je parlerais quand il sera sur le point de sortir.

Très récemment, j’ai été sollicité pour démontrer qu’il est possible d’industrialiser les développements PHP. Quoi de mieux pour cela que la plateforme Team Foundation Server ? ;-)

Vous connaissez peut être l’existence du plugin pour Eclipse permettant d’effectuer des développements avec PHP. Il s’agit de PHP Development Tools (PDT). Grâce à celui-ci et certains autres, il est possible d’éditer, compiler, tester, débuguer et surtout organiser les scripts d’un site PHP. Notez qu’il est également possible d’effectuer du développement PHP sous Visual Studio mais ce qu’il y a de bien avec la plateforme TFS, c’est que vous avez le choix ! :-)

PDT est nécessaire pour organiser vos fichiers en local mais il manque beaucoup de choses pour déjà parler d’industrialisation. Comment faire pour gérer la liste des tâches ou des bugs (si, si, il y en a) ? Comment partager les sources à travers l’équipe de dev ? Comment gérer les tests fonctionnels et automatiser la validation de l’application ? Comment livrer dans un serveur de test automatiquement la nouvelle version toutes les nuits, ou à chaque modification de code ? Comment savoir où on en est dans l’avancement du dev ? Où stocker les documentations ? etc. ? :-)

Toutes ces questions on se les pose quand on démarre un projet, peu importe sa taille, peu importe la technologie ou l’équipe. Et si on se dit “Tant pis pour le suivi, c’est un petit projet de toute façon” ça n’est pas parce que c’est vrai mais parce que ça parait compliqué de le faire. Avec TFS, répondre à toutes ces problématiques est non seulement simple mais adapté à toutes tailles de projets. Quel est le lien entre PHP, Eclipse et TFS ? Team Explorer Everywhere ! C’est l’outil qui permet de se connecter à TFS 2010 comme le permet le Team Explorer classique dans Visual Studio. La seule différence est que l’on est au sein d’Eclipse et que ça fonctionne aussi bien sur Windows que sur Linux, Mac OS et bien d’autres. Quelle excuse reste-t-il ? Aucune ! :-)

Les sources sont centralisées dans le contrôle de source, les tâches / bug / cas de tests et autres user stories sont gérés par les work items, la livraison automatique par le système de build intégré (pouvant utiliser Ant ou Maven), les documents sont situés dans Sharepoint qui est accessible directement depuis Eclipse et le système de reporting donne automatiquement l’avancement du projet. Il est possible de mettre en place une méthode de développement de type Agile comme Scrum ou plus classique si besoin. Tout ce qu’il est nécessaire de faire : Installer PDT et le Team Explorer Everywhere !

Intégration du contrôle de sources :

EclipsePHP_thumb[9]

Intégration du Team Explorer Everywhere :

EclipsePHP2_thumb[2]

Plus aucune excuse pour industrialiser ! :-)

A noter qu’il est possible de tester tout ça avec une version d’évaluation de TFS 2010 et une version d’évaluation de Team Explorer Everywhere.

.Dispose();

Automatiser des tests d’interfaces graphiques sur Excel : Done !

Le principe des tests d’interfaces graphiques automatisés dans Visual Studio 2010 est simple : on utilise du code (la plupart du temps généré, mais pas forcément) pour pouvoir identifier des objets graphiques et y appliquer un comportement identique à celui qu’aurait un utilisateur de façon à simuler son utilisation.

Pour que l’enregistreur de tests (Coded UI Tests) ou l’exécuteur de ces mêmes tests puisse “trouver” et manipuler ces objets graphiques, il est nécessaire qu’il “connaisse” la technologie dans laquel il a été constuit. Par défaut, un nombre important de technologies sont connues de l’outil, tels que WPF, Winforms, HTML, etc. Lorsque le système se retrouve confronté à un contrôle très personnalisé, les possibilités d’interactions seront minimalistes : on pourra récupérer son nom et quelques autres propriétés, mais cela s’arrête plus ou moins ici.

C’est pour cette raison que si vous tentez d’enregistrer un test impliquant Excel, vous pourrez utiliser la plupart des contrôles (tels que le ruban, les boutons de mise en forme, etc.), qui sont réalisés dans des technologies connues de l’outil. Si par contre vous tentez comme moi d’utiliser le sélectionneur de contrôle de l’enregistreur de test pour identifier une cellule particulière, vous vous rendrez compte rapidement que le contrôle contenant les cellules n’est pas reconnu par le système de Coded Ui tests et qu’il ne peut pas descendre en dessous du niveau de la grille :

image

On se retrouve alors avec un seul contrôle, difficilement utilisable.

Si c’est votre cas, ne paniquez pas, il existe une solution ! (mais vous vous en doutez, vu le titre du billet…)

Vu que les choses sont bien faites, le modèle de technologies supportées par les Coded UI Tests est extensible. Il est possible d’ajouter un plugin qui permettra à l’outil de reconnaitre et d’interagir avec une nouvelle technologie. Le schéma d’extensibilité est le suivant :

UI Test Architecture

Grosso modo, un plugin consiste à enrichir la couche “Technology Managers” et plus particulièrement l’aspect “Property Provider” qui permet d’exposer au Coded UI Test les valeurs des propriétés des contrôles.

L’avantage qu’on a quand on veut faire un plugin pour Excel, c’est que l’exemple d’extensibilité fournit par les équipes de Microsoft concerne justement Excel :) Vous pouvez trouver toutes les informations ici : http://msdn.microsoft.com/en-us/library/ff398055.aspx

Il contient le code du plugin et les explications concernant les étapes nécessaires à son déploiement (quelques DLLs à copier par-ci, par-là).

Dans les grandes lignes, le concept est d’avoir un AddIn VSTO (Visual Studio Tools for Office) dans Excel qui communique avec le plugin des Coded UI Tests. Si on a besoin d’avoir les informations concernant une cellule par exemple, le plugin côté test “demande” (en Remoting) ces informations à l’addin dans Excel qui lui répond. De même pour les actions réalisées sur Excel (prendre le focus, modifier une cellule, etc.).

Donc in fine, lorsque le plugin est déployé, vous utilisez les outils des Coded Ui Test (recorder et runner) comme d’habitude mis à part le fait que vous aurez accès à plus d’informations !

Ce qui fait que quand on utilise le sélectionneur : TADA ! On arrive à identifier une cellule en particulier:

image

Toutes les informations nécessaires à l’utilisation du plugin sont dans le lien cité plus haut. Au dela de m’avoir sauvé la vie dans le cadre d’un projet de tests sur Excel, c’est également un très bon exemple d’extensibilité.

Bon tests :)

.Dispose();

[Team Build 2010] Tips sur la création d’une nouvelle activité de build

En attendant la sortie de la RTM de Visual Studio / Team Foundation Server 2010 je continue à jouer “occasionnellement” (à qui je vais faire croire que c’est occasionnel? :-)) avec la Release Candidate.

Vous le savez déjà (j’espère ;-)): la grande nouveauté au niveau des Builds dans TFS 2010 c’est le fait qu’elles sont maintenant réalisées à l’aide de la techno Workflow Foundation. Je ne vais pas revenir en détails sur le fonctionnement général, ni sur les avantages que cela apporte, vous pouvez lire des choses à ce sujet ici et ici.

Auparavant, l’ordonnancement des tâches qui permettait d’obtenir en un seul clic : compilation, packaging, labelisation, documentation, déploiement et j’en passe grâce à Team Build était réalisé avec MSBuild (le même langage qui est utilisé dans la plupart des fichiers projets de vos solutions Visual Studio comme par exemple les .csproj). Un fichier MSBuild est schématiquement un ensemble de tâches MSBuild appelées sequentiellement. Si les tâches standards ne suffisent pas, on peut créer les siennes les déployer sur le serveur, les référencer dans le fichier MSBuild et les utiliser.

Avec Team Build 2010, le pendant de ce méchanisme d’extensibilité est identique à la différence prêt qu’on ne créé plus des tâches MSBuild personnalisées, mais des activités de workflow de build. Il y a déjà des articles régidés sur le sujet pour comprendre comment créer ces activités et quoi écrire pour que ça marche (ici par exemple).

Par contre on peut rencontrer quelques soucis lorsqu’on l’on souhaite utiliser la nouvelle activité. Si on est téméraire, on ouvre le fichier DefaultTemplate.xaml à partir de notre workspace local et on tente un Drag&Drop. Normalement, ça ne marche pas :)

En cherchant un peu on se rend compte que pas mal de gens mettent le fichier Xaml dans le même projet que l’activité pour que l’ajout au workflow fonctionne. Une fois que l’on sait ça, ni une, ni deux, on ajoute le fichier xaml au projet qui contient l’activité et là : magie, le Drag&Drop marche, on voit notre activité dans le workflow et on est content.

C’est alors que l’on décide de tester notre workflow Team Build tout neuf dans le serveur de build. Cela est très simple à réaliser, il suffit de :

  • Créer un répertoire dans le contrôle de code source dans lequel on dépose l’assembly contenant l’activité (j’ai bien dit le contrôle de code source et pas un répertoire windows)
  • Préciser au contrôleur de build qu’il doit aller chercher les assemblies des activités personnalisées dans le répertoire en question
  • Ajouter le workflow dans le contrôle de code source ou mettre à jour le fichier DefaultTemplate.xaml
  • Lancer la build

Et là… Team Build nous indique gentillement qu’il ne trouve pas l’assembly contenant l’activité. Pourquoi ?

<Je ne suis pas un expert WF mais…>

En jettant un coup d’oeil au fichier .xaml après avoir ajouté mon activité, j’ai découvert qu’il ajoutait bien une référence dans le noeud racine de la définition XML du workflow. Le problème c’est qu’il référence l’activité en utilisant le Namespace uniquement, sans préciser l’assembly. Ce qui explique que cela fonctionne dans le projet, mais pas dans le serveur de build ! Alors évidemment, on peut modifier le fichier XAML à la main pour mettre à jour la référence mais on perd l’utilisation de l’éditeur graphique de Visual Studio…

La solution *la plus simple* que j’ai trouvée, c’est de créer un autre projet vierge dans lequel je référence le projet contenant l’activité et ajoute le fichier XAML à éditer. De ce fait, la référence qu’il créé est complète et cela fonctionne sur le serveur de build. VICTOIRE ! ;-)

</Je ne suis pas un expert WF mais…>

Pour synthétiser voici ce que j’ai mis en place. Une solution contenant :

  • Un projet qui contient mes activités de builds
  • Un projet qui référence le premier projet et qui contient mes fichiers XAML uniquement dans le but de les éditer

image

 

 

 

 

 

 

 

 

Et là, tout fonctionne correctement ! :)

.Dispose();

Microsoft Visual Studio Team Explorer 2010 – Nom de code “Eaglestone”

Ca ne vous dit rien ?

Si vous êtes dans le monde Java et que vous utilisez Team Foundation Server, vous devez certainement connaître voir utiliser le plugin Team Prise. Il permet depuis plusieurs années d’avoir l’équivalent du Team Explorer (client riche pour accéder à TFS) dans Eclipse. C’est à mon sens l’un des plus beaux exemples de l’extensibilité de Team Foundation Server puisque qu’on obtient exactement la même expérience utilisateur qu’a travers notre Visual Studio préféré mais depuis Linux, Solaris, AIX, HP-UX, Mac et Windows le tout sous Eclipse.

Microsoft à récemment fait l’acquisition de Team Prise et le projet en question est pour l’instant connu sous le nom de code “Eaglestone”.

L’avantage avec cette solution, c’est qu’on ne se cantonne pas qu’a la gestion des sources comme on peut l’avoir pour Delphi ou d’autres clients, mais à l’intégralité des fonctionnalités. On peut gérer ses Work Items, créer ses requêtes, gérer les branches … sans avoir à sortir de l’IDE (et un développeur, ça n’aime pas sortir de l’IDE ;-)).

Brian Harry à annoncé la sortie d’une première version qui prend en charge le support des builds avec Workflow Foundation, la nouvelle architecture de TFS (Collection de projets, etc.), la gestion des branches, etc.

Ce qu’il manque actuellement dans cette version ? La gestion du Gated Checkin et la visualisation graphique des branches. Pour rappel le gated checkin permet de contrôler la qualité du code à chaque checkin en effectuant une build d’intégration continue avant d’effectuer réellement l’archivage. Il est apparemment possible de le faire mais l’expérience utilisateur n’est pas identique à celle connue sous Visual Studio 2010 RC.

Je vous invite à lire le billet plus complet de Brian Harry sur le sujet pour avoir tous les détails croustillants :)

(Anglais) : http://blogs.msdn.com/bharry/archive/2010/03/04/microsoft-visual-studio-team-explorer-2010.aspx

La moralité de cette histoire, et on ne le repetera jamais assez : Team Foundation Server, ça n’est pas que pour le monde Microsoft ! Ne vous privez pas d’un bon outil à cause de préjugés ;-)

.Dispose();

[Visual Studio 2010] Tester le Lab Management, c’est simple !

Vous connaissez le Lab Management ? Il s’agit d’une fonctionnalité assez importante dans la gamme de produits Visual Studio 2010 qui permet de connecter un serveur de virtualisation à un serveur TFS 2010 dans le but de pouvoir provisionner automatiquement des environnements de validation / recette / tests d’intégration / cequevousvoulez :

qsd

Ca ne s’arrête évidemment pas là car l’intégration avec Microsoft Test Manager (l’outil pour les testeurs fonctionnels, “MTM” pour les intimes) est très poussée : au point de pouvoir facilement attacher un lien vers un snapshot d’un environnement virtualisé à une fiche de bug remontée aux développeurs !

Et ça va encore plus loin avec les activités disponibles dans le workflow de Build de Team Build 2010 qui permettent de déployer un environnement ou d’en recycler un existant à chaque compilation serveur pour s’assurer que votre solution de test est toujours saine.

Bref, je suis fan de ça (ça se voit non ?) :)

Le lab management : Vous en avez déjà peut être entendu parlé, vu en démonstration, en vidéos, sur des blogs, dans des magazines, etc. Mais vous vous êtes toujours dit : “Oula, ce truc là ça à l’air compliqué à installer, on va mettre de côté pour l’instant…”.

Vous aviez peut-être raison… mais plus maintenant ! L’équipe du lab management chez Microsoft à mit à disposition du grand public une machine virtuelle comprenant tout ce qui est nécessaire pour pouvoir tester cette fonctionnalité :)

Comment ça marche ? Il suffit d’avoir une machine (8Gb de ram recommandés, 4Gb peuvent suffir) avec Hyper-V, d’importer la machine et de suivre un petit guide et C’EST PARTI !

Merci à l’équipe Microsoft qui nous à préparé tout ça :)

 

.Dispose();

[Visual Studio 2010 – Team Foundation Server 2010] Quelques guides

Les outils de la gamme Visual Studio 2010 amènent pas mal (énormément?) de nouveautés. Pour pouvoir les exploiter au mieux, l’équipe de “Visual Studio ALM Rangers” publie de plus en plus de guides. Il peut s’agir de mises à jour (comme le guide de branching qui existait déjà), ou de nouveautés !

En voici une première liste qui s’agrandira certainement au fil du temps :

Et ceux qui existaient déjà principalement pour 2008 :

Des documents complets que je vous recommande fortement ! :-)

Bonne lecture.

.Dispose();

[Visual Studio 2010] Importer des cas de tests à partir d’Excel

Vous connaissez certainement la possibilité de créer, exécuter des tests fonctionnels, disponible avec la gamme de produits Visual Studio 2010 (dont je parle ici)

Ces tests fonctionnels sont définis dans des WorkItems de type “Test Case”, dans Team Foundation Server. Le principe de base est simple : on définit la liste des étapes à réaliser par le testeur, et le résultat auquel il doit s’attendre. Le fait qu’il s’agisse ici de WorkItems, offre toute la souplesse d’édition habituelle, telle que l’édition dans Excel. Du moins, on pourra éditer les champs “classiques”, comme le titre, la description, l’itération et la zone, etc. mais le souci (en tout cas à l’heure actuelle) est que l’on ne peut pas éditer les étapes d’un cas de test directement à partir d’Excel. De manière générale, cela ne pose pas de réel problème, mais lorsque l’on souhaite importer ses cas des tests (venant d’un export d’un autre outil, ou d’un ensemble de cas déjà définit par vos équipes dans Excel), on est “bloqué”.

Rassurez-vous, vous n’aurez pas à tout recopier manuellement :)

La première solution, dont je parle ici, est de créer les cas de tests à partir d'Excel et de copier/coller les étapes dans les cas de tests, directement sous Visual Studio ou Test and Lab Manager. L’inconvénient de cette solution est de devoir au préalable créer les cas dans TFS.

La seconde solution est d’utiliser le nouvel outil d’import disponible sur codeplex : TestCaseMigrator ! L’idée est simple, vous avez un fichier Excel contenant vos scénarios de test, suivant votre format de définition. Via l’outil TestCaseMigrator, vous pouvez définir quelles colonnes correspondent à quels champs d’un workitem de type Test Case. Une fois ceci défini, vous n’avez plus qu’à lancer l’import et tout est ajouté dans Team Foundation Server !

Petite démonstration :

J’ai un fichier Excel ressemblant à ceci :

image

On voit ici deux scénarios, le premier: “Créer un élément” contient 3 étapes, et le second en contient 4. Quelques étapes possèdent un résultat attendu (optionnel). Remarquez que j’ai également un paramètre, nommé id.

A partir de l’outil TestCaseMigrator, je définis le fichier Excel à utiliser :

image

A partir de cette étape, l’outil identifie les colonnes et leurs titres (par défaut, les titres sont considérés comme provenant de la première ligne, mais on peut bien entendu le modifier :)

Etape suivante : se connecter à un serveur TFS

image

Remarquez qu’on peut préciser le type de work item à utiliser (s’il ne s’agit pas de “Test case” dans votre cas).

On peut alors choisir un fichier de mapping existant. Ceci peut vous faire gagner du temps si vous comptez importer des cas de test à partir de plusieurs fichiers Excel. Vous pouvez enregistrer le mapping et le réutiliser pour tous les fichiers ayant le même format.

image

Dans cet exemple, je vais considérer que je n’ai pas de fichier de définition de  mapping existant. Je le défini comme dans la capture suivante, en indiquant à quel champs du work item “Test case” correspond chaque colonne du fichier Excel :

image 

Sur l’écran suivant, vous avez la possibilité de définir un mapping de données entre des valeurs du fichier Excel et celles qui doivent arriver dans le work item. Ceci peut être pratique, si par exemple vous avez un état définit dans votre fiche Excel qui n’est pas le même que celui du Work Item. Vous définissez alors une correspondance à ce niveau (par exemple, pour transformer automatiquement l’état “A exécuter” en “Ready”).

image

On définit ensuite si on a un seul ou plusieurs cas de test par feuille Excel, ce qui est mon cas. Optionnellement, si on a déjà des paramètres dans notre test, on peut indiquer le séparateur de début et de fin. Dans mon fichier Excel, j’ai un paramètre id contenu entre @{ et }. Vous pouvez également donner le chemin d’un fichier pour sauvegarder la configuration de mapping que je viens de définir, pour pouvoir la réutiliser plus tard.

image

Il ne reste plus qu’à cliquer sur next, relire toute la configuration et cliquer sur Save and Import !

image

Et voilà ! Nous avons importé nos scénarios :)

Le résultat en image, visualisé à partir de Visual Studio :

image

Les tests on été correctement créés, les étapes également, ainsi que le paramètre id !

Simple non ? Très facile maintenant d’importer vos scénarios à partir d’un export Excel d’un autre outil (comme par exemple HP Quality Center ? ;-)) et profiter pleinement des fonctionnalités qu’offre Microsoft Test and Lab Manager !

.Dispose();

[VS 2010] Team Test Controller et Team Test Agent, ça devient quoi ?

  Si vous avez déjà effectué un test de charge avec Visual Studio 2008 Team Test, vous connaissez certainement la possibilité de répartir la charge sur plusieurs machines pour simuler plus d’utilisateurs.

Pour cela, on utilise un contrôleur, et un ou plusieurs agents, comme sur le graphique suivant :

Picture2

Le contrôleur était “gratuit”, contrairement aux agents pour lesquels il fallait acheter une licence par processeur.

Avec Visual Studio 2010, ce modèle change : le coût n’est plus par processeur, mais par nombre d’utilisateurs que vous voulez simuler.

Le nom de ce nouveau mode de package est : Microsoft Visual Studio Load Test Visual User Pack 2010.

Le principe est simple : Vous pouvez installer autant d’agents (nommés désormais : Visual Studio 2010 Team Agents) que vous désirez, sur autant de machines que vous voulez, mais vous ne pouvez pas dépasser le nombre d’utilisateurs auquel vous avez droit. Si vous voulez plus d’utilisateurs, il suffit d’ajouter un pack :)

Beaucoup plus simple et plus adapté à la réalité, ce nouveau modèle offre la souplesse qu’on attendait depuis un moment !

Plus d’informations sur le blog d’Ed Glas http://blogs.msdn.com/edglas/archive/2009/10/20/introducing-the-microsoft-visual-studio-load-test-virtual-user-pack-2010.aspx et http://blogs.msdn.com/edglas/archive/2009/10/20/getting-started-with-visual-studio-2010-beta-2.aspx

.Dispose();


Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01