Aucun employé de Microsoft ne le dira jamais de manière officielle, mais quand vous discutez avec eux, certains l’avouent : Team Server avant la version 2008 était un accident industriel… Une erreur logicielle sortie uniquement pour que les concurrents et les solutions Open Source ne prennent pas trop d’avance.
Avec Rosario (la version 2008), Microsoft s’était enfin décidé à sortir quelque chose qui, fonctionnellement, tenait bien d’une ALM (Application Lifecycle Management), mais qui était redoutable à installer et à configurer. J’en ai personnellement fait l’expérience, échouant à recréer en trois jours de boulot avec Rosario ce que j’ai mis en place avec facilité, bien qu’en y passant du temps, avec CVS + NAnt et des appels directs à csc.exe et NUnit-console.exe.
Côté fonctionnalité, il y avait à peu près tout ce qu’il fallait pour une équipe de développement, mais rien de plus que ce qu’on pouvait se mettre en place en assemblant des produits OpenSource.
Attention les yeux !
La version 2010 n’a absolument rien à voir avec les précédentes. Microsoft a du menacer de virer sa division complète de développeurs sur TFS, car la version 2010 est impressionnante. Et sur les deux points : fonctionnalités (j’y reviendrai dans de prochains billets) et facilité d’installation et de configuration (le sujet du présent billet).
L’installation de TFS en version Basic (c’est à dire sans le reporting et le collaboratif, dont on peut très bien se passer pour des projets petits et même moyens) se fait en 17 clics de souris. En plus, vous n’êtes même pas obligés d’avoir un OS serveur ! Windows 7, même en 32 bits, fait très bien l’affaire, et vous pouvez donc pour vos tests avoir un TFS Basic 2010 RC sur votre bécane de développement, au même endroit que votre Visual Studio 2010 RC tout frais lui aussi. Autant vous dire que pour des beta-testeurs avec une machine limitée, c’est parfait… Plus besoin d’une VM limitée en RAM pour voir comment ça marche.
Pour vous dire à quel point c’est simple, je ne vais même pas vous faire de captures d’écran. Il n’y en a pas besoin : vous double-cliquez sur Setup.exe pour lancer l’installation, et ensuite vous ne faites que cliquer sur Next à chaque fois qu’on vous le demande. Même le choix du mode configuration est sur Basic par défaut, donc vous n’aurez même pas à changer ce mode. Vraiment, vous ne faites qu’avancer en gardant la configuration par défaut, et à la fin, vous vous retrouvez avec un serveur TFS accessible depuis http://localhost:8080/tfs.
Juste un petit truc : une erreur sur le WMI quand vous utilisez Windows 7 :
Rien de grave. Si vous cherchez le code TF255437 sur Google n’importe quel moteur de recherche, vous trouverez aisément la solution, comme par exemple sur http://social.msdn.microsoft.com/Forums/en-CA/tfsprerelease/thread/e6a24673-8606-4e79-87b5-5deae28234f6
Il suffit de cocher la fonctionnalité suivante dans les programmes Windows, et de relancer l’analyse de votre configuration. Bon, ça fait un clic de plus, mais le problème ne se produit pas en Windows Server.
L’installation complète a pris 17 clics de souris, plus le double-clic initial sur le programme setup.exe et les clics pour parcourir l’ISO d’installation, si on pinaille. Plus sérieusement, et plus important, à aucun moment le système d’installation ne demande de rentrer du texte pour configurer le logiciel ou le faire pointer sur une instance de SQLExpress ou autre. Si vous avez une installation de SQL, il la choisit pour vous, si vous n’en avez pas, il installe une instance de SQLExpress de manière silencieuse. Et surtout, à aucun moment, vous ne vous retrouvez en face d’une zone de saisie obligatoire en vous demandant “mais qu’est-ce qu’ils veulent que je mette là-dedans ?”.
Bref, génial pour tester. De manière générale, c’est le problème de beaucoup de serveurs : ils vous demandent plein de paramètres de configuration à l’installation. Quand vous connaissez bien le logiciel, pas de souci. Mais il y a obligatoirement une première fois… Microsoft a résolu brillamment ce problème sur TFS 2010 : installation complète par défaut, et si vous voulez paramétrer plus finement après, pas de souci, vous pouvez le faire. Mais si vous n’y connaissez rien, vous cliquez sur Next sans rien comprendre, et à la fin, tout est sur le répertoire virtuel tfs, sous port 8080.
Et ensuite ?
Bon, une fois arrivé là, vous vous dites que ça vaudrait le coup d’aller faire un tour sur cette fameuse url http://localhost:8080/tfs/. Allons-y, mais je vous préviens, il n’y a pas grand chose pour le moment. On vous demande votre login (authentification intégrée Windows), et voilà :
Eh ben, oui ! Il n’y a rien 🙂 Pas de projet à afficher, vu qu’on n’en a pas créé. Et il n’y a pas de lien pour en créer sur la page web.
Du coup, on jette un petit oeil à la console de configuration de TFS, qui s’est affichée à la fin de l’installation :
Si on va dans la premier node de l’arborescence, on n’en apprend pas beaucoup plus :
Mais, dans le deuxième, il semble y avoir un onglet intéressant dans la partie du bas :
Là encore, non seulement il n’y a pas de projet, mais il n’y a pas de lien de type Add ou autre chose.
Par contre, le lien How to add a Team Project paraît contenir ce qu’il nous faut. Le lien nous redirige sur http://msdn.microsoft.com/en-us/library/ms181477%28VS.100%29.aspx qui nous explique en gros que c’est depuis Visual Studio que ça se passe.
Configuration de Visual Studio
Du coup, c’est l’occasion d’installer la RC de Visual Studio 2010 aussi. Tout d’abord, quelques remarques :
- Ce n’est pas la peine d’avoir TFS 2010 pour utiliser VS 2010 : un Rosario suffit.
- Là où c’est encore plus fort, c’est que dans l’autre sens, c’est également vrai : vous pouvez très bien vous connecter avec une ancienne version de VS sur une nouvelle de TFS. Bref, il y a compatibilité dans les deux sens.
- Vous pouvez tout à fait installer VS 2010 RC sur la même machine qu’un VS 2008. Les deux ne se marchent pas sur les pieds. En tout cas, personnellement, je n’ai pas eu de problèmes…
Une fois arrivé dans Visual Studio, c’est extrêmement simple à nouveau : il suffit d’aller dans le menu Team, de sélectionner la seule entrée pour l’instant, à savoir “Connect to a Team Foundation Server”, et de se connecter au serveur, en l’occurrence la machine locale dans notre exemple.
Ce que TFS appelle des collections sont des ensembles de projets. Ca peut être pratique si vous avez deux logiciels qui ne partagent rien de les gérer dans deux collections. Mais la séparation est assez forte. Notez que l’installation par défaut a créé une collection par défaut, donc pas besoin de se poser de question.
Une fois que vous vous êtes connectés, vous avez accès au panel Team Explorer (CTRL+W, M, ou dans le menu View), qui va enfin nous permettre de créer un projet au sens TFS. Un clic droit sur localhost\DefaultCollection, et on choisit New Team Project… C’est parti pour un assistant, où on remplit d’abord le nom du projet et une petite description. Je ne suis pas fan des projets de type toto ou HelloWorld, alors on va plutôt en profiter pour tester les tests unitaires à la mode Microsoft. Je ne connais que la syntaxe NUnit, mais d’après ce que j’ai vu, c’est très proche.
L’étape suivante vous propose de choisir un modèle de processus :
La première fois, ça fait bizarre. Pourquoi est-ce que TFS me demande si je travaille en mode Agile ou CMMI (et il y a plein d’autres modèles à télécharger, de type RUP, etc.) ? En fait, c’est parce que TFS ne se limite pas, loin de là, à un contrôle de code source et une compilation automatique. C’est vraiment un ALM complet. Ce qui veut dire qu’il va gérer les tâches que vous entreprenez, les suivre, les relier à vos modifications de code, à votre gestion de branches, à vos livraisons, etc. Ce qui représente une énorme valeur ajoutée. On verra au fur et à mesure des prochains articles pourquoi.
La prochaine étape consiste à créer le répertoire dans le code source :
Une fois arrivé là, on peut avoir un petit résumé et lancer la création du projet. Ca prend quelques dizaines de secondes (mise en place du projet dans le serveur, dans la base de données, etc.). On peut ensuite commencer à bosser.
Création du premier projet sous contrôle de TFS
Supposons qu’on crée un projet avec nos opérations arithmétiques à tester, et qu’on coche Add to source control comme suit :
On aura ensuite l’affichage de la fenêtre suivante qui nous demande où dans la collection courante le projet doit être ajouté :
On peut bien sûr créer un nouveau répertoire et mettre en place une arborescence pour organiser notre travail, mais dans un premier temps et vu qu’il s’agit d’un test, je vais simplement placer ce projet sous un seul niveau de répertoire, à savoir TestsTFS. Le bouton Advanced… permet de contrôler de manière plus fine la correspondance entre le contenu et le contrôle de code source.
Quand on crée un projet, vous savez que Visual Studio crée pour vous un fichier de définition du projet, un pour la solution, et dans notre cas aussi un AssemblyInfo.cs, ainsi qu’un fichier de classe Class1.cs. Dans le cas d’un contrôle de code source, il y a aussi les fichiers .vspscc et .vssscc. Et du coup, la fenêtre Pending Changes vous indique que tous ces fichiers sont en attente d’ajout dans le contrôle de code source. En effet, nous avons créé le projet, mais pour l’instant, on n’a rien mis dedans.
Pour valider tout ceci dans le CCS (Contrôle de Code Source, l’acronyme n’est pas officiel, mais je n’ai pas envie de taper ça 36 fois…), il suffit de cliquer sur Check In. Il est de bonne pratique de rajouter un commentaire pour se rappeler du contenu global de cette livraison. La deuxième icone vous permet de relier la livraison de code à un Work Item. Je préfère garder cette notion, fondamentale, pour un prochain article plus complet sur la question, donc je ne vais pas créer un Work Item pour l’associer, mais sachez d’ores et déjà que ceci est extrêmement important. Un Work Item, pour vous expliquer quand même en deux mots, vous permet d’identifier, sur tout le cycle de vie, une opération de modification de votre logiciel. Typiquement, si vous mettez en place une fonctionnalité, ça doit être réalisé sous un Work Item. Ainsi, vous pourrez facilement consulter tout ce qui a été fait sur cette fonctionnalité, lancer des tests dessus, la passer sur une autre branche de développement, etc. J’arrête pour l’instant, mais on y reviendra car c’est absolument essentiel. Dans toutes les solutions ALM, la grosse difficulté d’intégration aux processus de la société qui les utilisent gravite autour de cette notion.
Espaces de travail
Pour l’instant, les fichiers sont rajoutés dans le CCS, mais ils sont aussi présents dans le répertoire dans lequel j’ai initialement créé le projet. Ceci était fait exprès pour vous faire voir que, dorénavant, on peut supprimer ces fichiers et les récupérer à un endroit un peu plus approprié pour travailler.
Supprimons donc tout le contenu de C:\Temp\OperationsArithmetiques après avoir clos la solution, et nous allons réaliser l’opération de Check Out, c’est-à-dire la récupération d’une copie de travail de ce qui se trouve désormais sur le serveur.
Pour cela, un double clic sur “Source Control” dans le panel “Team Explorer” nous amène en vue principale un autre onglet, à savoir “Source Control Explorer”, dans lequel on retrouve le projet et la solution que nous avons précédemment créés :
Par contre, on voit que pour l’instant, le projet n’est pas “mappé”. Il faut mettre en place une correspondance pour que le gestionnaire de code source sache où les fichiers doivent être placés en local pour travailler dessus. L’endroit du disque dur local où on stocke les fichiers pour modification, avant retour dans le serveur TFS, est appelé un workspace, ou espace de travail.
En cliquant sur le lien “Not Mapped”, VS vous propose de mettre en place cette correspondance. C’est le bon moment pour créer un répertoire de base dans lequel vous mettrez tous vos projets. Pour moi, c’est dans D:\WIP\Workspace (WIP comme Work In Progress pour les curieux), et VS rajoute automatiquement le nom du projet, de façon à ce qu’un répertoire soit créé pour ce projet TFS en particulier. On veut récupérer le contenu en récursif, donc la case en bas à gauche reste à son état coché par défaut.
Quand on clique sur Map, VS nous demande si on veut supprimer notre ancien mapping sur C:\Temp, et c’est bien ce qu’on veut faire, donc on confirme. Juste après, une autre boîte apparaît, où VS nous propose de lancer aussitôt l’opération de Get, qui consiste à alimenter le répertoire de correspondance avec les fichiers en provenance de TFS. En effet, dans un premier temps, on avait juste créé le répertoire et on l’avait mis en correspondance avec le projet sur le gestionnaire de code source, mais maintenant, il faut lui dire de rapatrier les fichiers. Un peu comme une synchronisation descendante.
Le rapatriement des fichiers se fait :
Et on a bien tout ce qu’il faut pour compiler, modifier et tester en local :
Si on avait répondu non à la commande de Get proposée, on pouvait réaliser l’équivalent en cliquant sur l’icone Get Latest Version (recursive) dans l’onglet “Source Control Explorer”.
Une fois arrivé à ce point, on peut ouvrir la solution D:\WIP\Workspace\TestsUnitairesMicrosoft\TestsTFS\OperationsArithmetiques\OperationsArithmetiques.sln et travailler dessus comme on le ferait pour n’importe quelle solution en local, à la seule différence que le panel Pending Changes s’enrichit au fur et à mesure des modifications, en attendant la prochaine étape de validation des modifications.
Notons juste que le seul fait de modifier un fichier génère un CheckOut, c’est-à-dire une opération signifiant qu’on prend la main sur le fichier. Il y a des options pour contrôler ceci, comme dans la plupart des IDE ou des plugins de contrôle de code source. Mais on peut bien sûr aussi faire un CheckOut sur tous les fichiers qu’on a l’intention de modifier, de façon à signaler qu’un travail est en cours sur ces fichiers. Je crois qu’il est même possible de demander un CheckOut exclusif, mais je n’ai pas encore cherché comment faire (et honnêtement, c’est une pratique assez moyenne quand on bosse en équipe).
Conclusion
Vous voulez une ALM super fonctionnelle et facile à utiliser ? 30 minutes de boulot et vous êtes dedans, avec une seule machine avec un OS client. On n’a pas encore parler de la compilation automatique, des WorkItems, mais ça sera pour une prochaine fois. Pareil pour les tests unitaires. J’ai dit que je faisais ce projet test pour les manipuler, mais il y a assez je pense dans cet article pour vous occuper un bout de temps si vous débutez, et vous faire à quel point c’est simple à mettre en place. Dans les prochains articles, on passera à la deuxième qualité de TFS, à savoir la richesse des fonctionnalités. Si elles sont aussi simples à mettre en place que le serveur lui-même, ça promet !
Pour faire un lien avec le monde professionnel (et vous savez maintenant que c’est ce qui me motive dans ce blog), la richesse de TSF 2010 est telle que la société pour laquelle je travaille est en train de se poser la question de la migration vers cette solution. Nous avons pourtant une ALM “cousue main” sur laquelle nous avons passé des mois de développement sur les sept dernières années, mais suite à ce que j’ai vu aux TechDays et à ce que je suis en train de trouver en testant TFS, nous envisageons sérieusement de mettre une partie de ce travail à la poubelle, et d’intégrer dans TFS ce qui est spécifique à notre organisation (heureusement, il en reste beaucoup, sinon je serais vraiment dégoûté !). Apparemment, l’accès aux API, aux services et à de nombreux points d’entrées dans TFS devraient nous permettre de mettre ceci en place assez facilement. De prochains articles détailleront les étapes envisagées (puis effectuées ?) pour cette migration.
Comme ça, on sera vraiment dans ce que je souhaite réaliser sur ce blog : vous faire voir des vraies solutions, applicables à l’industrie, et même réellement appliquées dans ce cas, en tout cas je l’espère…
