Batswirl

Rhino Mock / MSTest : Isolation

2010-02-07T21:23:00Z

Dans ce post, j’aimerais vous présenter diverses méthodes permettant d’effectuer des tests de comportements sur vos composants. On ne teste pas le contexte, les données retournées mais bien le comportement de la routine avec l’appelant et les dépendances.

Contexte

On souhaite tester une méthode d’un dépôt(notion de repository en DDD). La routine en question est un service permettant d’envoyer des entités (Demande) à un service Web pour centraliser ces demandes. Les différentes actions effectuées sont les suivantes :

L’appelant appelle la méthode EnvoyerTout prenant en paramètre une liste de Demande.

Le dépôt reçoit la liste et vérifie les informations de synchronisation dans une base de données locale.

Le dépôt envoie la liste des demandes et les informations de synchronisation au service.

Le service répond et fournit des informations permettant d’enregistrer en local que les demandes ont déjà été envoyé au serveur.

Afin de limiter le trafic réseau, on souhaite vérifier que les demandes réellement envoyées au serveur n’avait jamais été envoyées. Cette information est disponible dans la base de données de locale.

On souhaite isoler le comportement de cette routine car nous détectons rapidement les différentes dépendances :

Un service Web qui doit répondre aux différentes requêtes du proxy.

Une base de données contenant des informations de synchronisation.

Une utilisation d’une dépôt permettant de récupérer les informations de l’utilisateur.

Explication du test

Voici donc le test en question :

   1:          [TestMethod]

   2:          public void EnvoyerToutNAjouteQueLesDemandesJamaisSynchronisees()

   3:          {

   4:              utilisateurDepot = mockRepository.Stub<IUtilisateurDepot>();

   5:              demandeDeControleService = mockRepository.StrictMock<DemandeDeControleService>();

   6:              demandeDeControleServeurDepot = mockRepository.Stub<DemandeDeControleServeurDepot>(demandeDeControleService, utilisateurDepot);

   7:              Expect.Call(demandeDeControleServeurDepot.GetReplicaId()).Return(Guid.NewGuid());

   8:              demandeDeControleServeurDepot.MettreAJourTousLesWatermark(null, 0);

   9:              LastCall.IgnoreArguments();

10:

  11:              Expect.Call(demandeDeControleService.EnvoyerTout(null)).IgnoreArguments().Return(0).Repeat.Once();

  12:              mockRepository.ReplayAll();

13:

  14:              demandeDeControleServeurDepot.EnvoyerTout(CreerUneListeDeDemandes(5, 2));

15:

  16:              ServiceDomain.DemandeDeControle[] demandeDeControleEnvoyees =

  17:                  (ServiceDomain.DemandeDeControle[])demandeDeControleService.GetArgumentsForCallsMadeOn(x => x.EnvoyerTout(null)).First().First();

  18:              Assert.AreEqual(2, demandeDeControleEnvoyees.Length);

  19:          }

Pour décrire ce test commençons par le commencement d’un test à savoir son assertion :

Ligne 18 : Assert.AreEqual(2, demandeDeControleEnvoyees.Length); On vérifie ici que le nombre de demandes envoyés au serveur est bien égale à 2.

On pourrait donc traduire cette assertion de la sorte : Si l'application fournit une liste de 5 demandes au dépôt mais que seuls 2 demandes de cette liste doivent être envoyées au serveur, vérifie que le dépôt n'a envoyé que ces 2 éléments au service.

Pourquoi?

Ligne 14 : demandeDeControleServeurDepot.EnvoyerTout(CreerUneListeDeDemandes(5, 2)); C’est la routine que nous souhaitons tester. Dans le test, le paramètre (la liste de demandes suceptibles d’être envoyées) est fourni par une méthode du test CreerUneListeDeDemandes(5, 2) prenant en paramètre le nombre total de demande à créer et le nombre de demandes à synchroniser (et qui doivent donc réellement être envoyées au serveur).

Et la rapport avec l’assertion?

Ligne 16 et 17 : On récupère le premier paramètre du premier appel (il n’y en a qu’un) de l’exécution de la méthode EnvoyerTout d’un mock (demandeDeControleService) .C’est le cœur même du test et l’objet de l’assertion. Ces paramètres proviennet directement du mock, le service n’est jamais instancié.

Et comment c’est possible?

De la ligne 4 à la ligne 9 : on prépare l’exécution du test en isolant, à l’aide de diverses techniques et fonctionnalités de RhinoMock, les dépendances détectées.

Ligne 4 : on crée un stub du dépot utilisateur, aucun comportement ou données ne nous sont nécessaires. Nous avons juste besoin d’une instance de ce dépot pour l’instanciation ligne 6. Le fait de le “stuber” permet de ne pas exécuter le code de ce dépôt.

Ligne 5 : On crée un mock strict. Toutes les fonctionnalités du service seront recrées et tous les appels vers le service seront redirigés vers ce mock.

Ligne 6 à 12 : Création du mock partiel du composant testé. Toutes les routines réclamant un contexte (ligne 7 et 8, la récupération des informations de synchronisation nécessite une base de données locale) sont redirigés vers le mock. On peut configurer le résultat de l’exécution de la méthode du mock (ligne6 : demandeDeControleServeurDepot.GetReplicaId()).Return(Guid.NewGuid()) ) ou l’on peut déclarer d’ignorer l’appel et les paramètres (ligne 7).

Sur ce mock partiel, on appelle la méthode testée (ligne 11).

Tous les comportement d’isolation ne seront disponibles qu’après la ligne 12. Celle-ci permet d’informer RhinoMock des différentes instructions d’isolation.

Conclusion

Pas de base de données à construire et de données à générer. Pas de service sur un serveur de test. Mais le comportement attendu est vérifié et le sera même en cas de changement de source de données, de modification du contrat de service…

Cool non?

Mise sur étagère : ou comment revoir un flux de développement TDD avec TFS

2010-02-04T10:38:00Z

La mise sur étagère dans Team Foundation Version Control est l’une des fonctionnalités qui m’a le plus rapidement séduit.

Classiquement, on s’en sert pour enregistrer une modification du source non achevée ( not done) mais que l’on souhaite conserver sur un serveur sauvegardé pour le récupérer en cas d’incident sur notre propre poste. Martin avait écrit un excellent billet à ce sujet.

On peut également l’utiliser pour communiquer nos modifications sur notre espace de travail avec d’autres développeurs, pour fusionner le travail, lors d’un binômage etc…

Récemment, j’ai surtout pris l’habitude de mettre sur étagère dans mon flux de développement en TDD (ou plutôt en Test First Programming, certains connaissent mon attachement à cette différenciation).

Voici donc ce nouveau flux :

Définir le test

Définir le test, en particulier son nom
Ecrire les assertions (ce que je vérifie)
Définir mes besoins (contexte, instanciation des composants testés)
Appel de la routine à tester

Obtenir le résultat du test (Red bar)

A ce stade, le projet ne compile pas en général, puisque rien n’est implémenté. L’objectif suivant est de faire compiler ce projet.

Je déclare les différentes variables
j’implémente au minimum l’objet du test (création du type, de la routine)

Ici, j’en arrive au point ou je compile et il ne me reste qu’à implémenter la fonctionnalité avec l’assurance de tester automatiquement celle-ci. C’est pour moi le moment idéal d’effectuer une mise sur étagère des modifications de mon espace de travail. Celui-ci me permet d’être plus à l’aise dans l’implémentation, en cas de problème, je peux revenir en arrière par l’ensemble d’actions :

Undo : annulation des modifications en attentes
Get : Récupération de la dernière version (facultatif)
Unshelve : Récupération du cadre de développement de la fonctionnalité à savoir mon test

Essayez ce flux, c’est l’adopter.

La fonctionnalité : Lier à un élément de travail

2009-07-20T03:25:21Z

Etant actuellement impliqué dans un projet agile autour de Team Foundation Server (un peu plus à ce sujet très prochainement), j’ai décidé de faire partager mon expérience du produit lors de chacune des Daily Meetings. C’est donc l’occasion pour moi de revenir sur mes basiques et surtout de faire un point sur ce qu’on attend des fonctionnalités de Team Foundation Server et ce qu’elles apportent réellement à l’équipe.

Lier à un élément de travail

Description : Lors de l’archivage d’une modification du projet, le développeur a l’opportunité de lier cette modification à un ou plusieurs éléments de travail. Un lien est alors créé entre son jeu de modifications (changeset) et l’élément de travail.

1 : Lors de l’archivage, le 2° bouton dans le menu de gauche permet de lier la modification à un élément de travail

2 : une requête permet de sélectionner l’élément de travail (par défaut les éléments de travail qui me sont assignés : “My Work Items”)

3 : Le développeur peut agir directement sur l’élément de travail en sélectionnant l’action (associer l’élément de travail ou le résoudre)

Une fois l’archivage effectué, le lien est présent dans l’historique du contrôleur de code source à l’aide dans le détail de l’archivage et depuis la base de l’élément de travail à l’aide d’un lien vers le contrôleur de code souce.

Les apports

En deux clics de la part du développeur on obtient une traçabilité “technico fonctionnelle”. J’entends par là que chacune des actions des développeurs, des testeurs et des architectes sont réliées à la demande ou au besoin initial. N’oublions pas que l’ensemble des ses informations vont persistées dans la base (SQL Server) pour des années et permettront de naviguer dans l’historique du projet et ainsi de :

Définir quelle était la cause d’une modification du contrôleur de code source
Déterminer l’impact de l’implémentation d’une fonctionnalité ou d’un correctif

Mise en place et Risques

Pas de mise en place particulière, il suffit d’avoir des éléments de travail à lier à vos modifications. Il s’agit donc de préparer les développements et les différentes tâches de l’équipe. Au niveau des risques, il est important de lier chaque modification du code source à un et un seul élément de travail. Rappelons que lors d’un archivage, tous les fichiers modifiés dans l’espace de travail sont sélectionnées mais qu’il est possible de construire son jeu de modifications en sélectionnant les seuls fichiers qui ont permis d’implémenter la fonctionnalité ou de résoudre un bug.

Contourner l’intégration continue

2009-05-16T08:49:34Z

De plus en d’équipes pratiquent l’intégration continue. Team Build et Team Foundation Server sont particulièrement bien dotés pour cela :

Démarrage des builds basé sur les évènements du contrôleur de source
la configuration est facile et permet d’empiler des compilations et de définir le nombre de builds à conserver afin de limiter l’espace disque utilisé par exemple
…

Cependant, il peut être utile de contourner le lancement de la compilation lors d’un archivage ( édtion d’un script de build, création d’une branche…).

Lors de l’archivage de votre changeset, placez en tête de votre commentaire le texte suivant :

***NO_CI***

Cette commande indiquera au moteur de build que vous ne souhaitez pas déclencher l’intégration continue.

Mon équipe ne me quitte plus!!!

2009-04-22T08:42:45Z

Les résultats des Builds de vos projets sur votre iPhone, c'est possible avec TFSToGo.

La partie configuration :

La liste des builds et le résultat :

Vais peut être changer de mobile moi...

Surveiller un serveur TFS

2008-10-09T05:39:14Z

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

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

Configuration matérielle

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

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

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

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

IIS

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

Default Web Site

Sharepoint Central Administration v3

Team Foundation Server

Team System Web Access

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

Microsoft Team Foundation Server Application Pool

ReportServer

TFS WSS

DefaultAppPool

Sharepoint Central Administation V3

TswaPool

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

Services Windows

Les services suivants sont ils démarrés?

TFSServerScheduler

SharePoint Timer Service

Journaux d' événements

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

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

SQL Server

Les services suivants sont ils démarrés?

Database Services

Analysis Services

Reporting Services

SQL Server Browser

SQL Server Agent

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

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

KB947455 - Actions "Delete" répétées durant les fusions

2008-07-21T12:00:25Z

Petit rappel : Une fusion dans Team Foundation Version Control est constituée d'une liste de "jeux de modifications" (ChangeSets en anglais) que l'on souhaite reporter d'une branche à l'autre. Les jeux de modifications comporte des actions (ajout, renommage, édition...) appliquées à des Items(les fichiers et les dossiers). La fusion consiste donc à répéter les différentes actions sur les items d'un jeu de modifications sur les items communs entre les branches.

Problème : Les actions de suppression des fichiers ne sont pas répétés durant les fusions dans TFVC 2005 et TFVC 2008. Les fichiers qui ont été supprimés dans la branche de destination seront donc toujours présents malgré le report de l'ensemble des modifications dans la branche Cible. Le problème est connu et une KB est disponible ici : http://support.microsoft.com/default.aspx/kb/947455/en-us

Résolution : Microsoft vient de publier un correctif visant à permettre de reporter les opérations de suppression à l'aide d'une opération de fusion. Ce correctif est disponible ici : http://code.msdn.microsoft.com/KB947455/Release/ProjectReleases.aspx?ReleaseId=1127 .

Il permet donc de voir apparaître des actions de suppression lors de la fusion entre deux branches.

Dans l'exemple ci-dessous, il s'agit du fichier web.config qui devra être supprimé après la fusion.

Nous avons bien l'effet attendu en vérifiant après la fusion les modifications en attentes sur l'espace de travail :

A noter toutefois que ce correctif ne permet pas de reporter des suppressions entre deux dossiers à l'aide de l'option /Baseless disponible à l'aide de l'outil en ligne de commande tf.exe, comme en témoigne le résultat des modifications en attentes ci-dessous.

Après exécution de la commande :

On constate donc que le fichier qui a été supprimé dans la branche source a donc été ignoré lors de la fusion.

Get Lastest on Check-out

2008-04-29T19:41:00Z

Ou pourquoi je ne recommande pas une nouvelle fonctionnalité de Microsoft Visual Studio Team Foundation Server 2008.

Rappel : la fonctionnalité permet d'extraire la dernière version du fichier lorsque vous demandez son extraction pour modificaiton. Il s'agit du comportement par défaut de Visual Source Safe et a été largement demandé par un certain nombre d' utilisateurs de TFVC 2005 qui n'en disposait pas

Il est désormais connu de tous qu'au cours de la planification d'un projet il est indispensable de fixer des jalons, des points de repère qui nous permettront de vérifier que nous ne nous sommes pas écartés du droit chemin, de notre objectif initial. Si tel est le cas, nous corrigerons notre route, nos tâches à faire afin de reprendre la bonne direction.

Cette technique, bien connue des adeptes de la navigation aérienne, nous l'utilisons tous les jours, à tout moment, dans chacune de nos actions. Nous établissons un plan de route que nous nous efforçons de tenir. Les imprévus font que nous devons nous positionner puis nous réorienter avant de pouvoir reprendre notre route.

Et en quoi cela concerne-t-il un contrôleur de code source ou un développeur me direz-vous?

Les développeurs n'échappent pas à la règle.

Je me place rarement derrière une machine, dans un environnement de travail sans savoir ce que je vais réaliser. A partir d'un objectif, je vais placer mes jalons, les sous-modules, les types, les routines qui me permettront de mener à bien ma tâche et faire progresser mon produit.

Je commence donc mon travail, je crée des classes, des interfaces,bref... Je crée des fichiers. Tout irait pour le mieux jusqu'à ce que j'aie à travailler en équipe et que j'utilise un contrôleur de code source et/ou que je doive prendre en compte l'existant.

Je m'apprête à modiifer cette classe abstraite dont je dérive afin que cette dernière me fournisse un service bien sympathique et là... c'est le drame.

Un développeur a mis à jour cette classe depuis ma dernière extraction du fichier et j'ai activé l'option Get lastest on Check-out. Je dois désormais prendre en compte dans mon plan, cette nouvelle méthode à implémenter, les modifications du contexte etc...

Qu'à cela ne tienne, les obstacles ne m'effraient guère et je consens à implémenter cette méthode et à modifier les paramètres d'appel des différentes méthodes.

Pourtant, au cours de la journée, l'incident se répète sans cesse et je commence à ne plus trop cerner mon plan d'action initial. J'en arrive même à faire des concessions dans ma conception initiale afin de me plier aux apports des autres développeurs. Soit.

Le constat

Le constat que nous pouvons tirer de cette journée de travail type est que le report des modifications d'un référentiel commun dans notre espace de travail et sans intervention de notre part nous force à intégrer ces modifications dans notre travail en cours.

Pourtant, je l'avoue, je ne suis pas thread safe et l'accumulation de paramètres à prendre en compte réduit ma capacité à prendre les bonnes décisions sur le sous système que je suis en train de concevoir.

Les différentes déviations que me font prendre ces modifications, m'eloignent petit à petit de ma route que je distingue de moins en moins. Imaginez qu'au cours de ces déviations, un golf s'offre à moi et vous comprendrez le retard que je pourrais prendre (les personnes me connaissant feront le rapprochement).

En bref, si les méthodes agiles préconisent une réactivité face au changement, elles permettent également d'organiser ce changement. Après tout, durant mon développement si je pressens devoir prendre en compte des modifications présentes sur le serveur, rien ne m'empêche de les récupérer. Cependant, je ne vois aucun intérêt à subir les affres d'un quelconque automatisme dans cette opération.

Une des valeurs agiles : Le courage

N'ayez crainte, il ne s'agit pas d'un article uniquement réservé aux adeptes des méthodes agiles, certains frileux des termes itérations et incrémentales ont déjà approuvé mes propos concernant mon point de vue sur cette option de TFS.

Le courage, c'est aussi être honnête et reconnaître ses fautes. Ainsi, il m'arrive, parfois, durant mon développement, d'être lassé de cette "intégration" continue (notez bien les guillemets et ne me faites pas dire ce que je n'ai pas dit).

Lassé, au point de tout faire pour en arriver à ce que je veux : Compiler, tester.

Alors que fait le développeur dans ce cas?

Il intègre me direz vous. Non monsieur, il corrige, atténue, prend en compte pour palier son besoin primaire : Compiler et voir si ce qu'il a écrit marche.

Certains appellent cela une intégration, pour ma part, j'appellerais ça une rustine.

Ne nous y trompons pas, le changement et l'intégration non organisés sont des virus qui peuvent mettre à mal votre volonté de bien faire.

Et l'intégration alors?

J'entends alors au loin les discours moqueurs me signalant que je n'ai toujours pas intégré mon code avec le référentiel et que je vais en mettre du temps. Ma réponse est Oui, je vais mettre du temps pour intégrer, mais aussi prendre le temps d'intégrer.

L'intégration consiste à confronter vos réalisations face aux modifications apportées par vos coéquipiers. Une partie de mon planning quotidien ou hebdomadaire devra être réservée à cela. Si, en plus, ces créneaux horaires sont communs à l'ensemble de l'équipe, je disposerais de collègue entièrement disponibles pour parler de telle abstraction à revoir ou de telle librairie que j'ai utilisée et qui leur permettrait d'archiver et donc d'intégrer plus rapidement. Encore une fois, déranger un développeur par vos propres soucis durant son développement ne provoquera que deux choses :

Vous parlerez dans le vide ou presque
Il ne vous invitera pas à son mariage se rappellant de ce petit bug que vous l'avez aidé à glisser dans sa fonctionnalité et qui a coûté si cher en production

Voilà pourquoi je ne recommande pas et je n'active pas l'option Get lastest on Check Out dans Team Foundation Version Control 2008.

Dans une prochaine publication, je confronterai mes résultats de test de QI à ceux de Visual Studio afin d'expliquer pourquoi je ne laisse jamais l'IDE s'occuper de mon espace de travail.

Erreur 32000 lors de la migration de TFS 2008

2008-04-28T20:25:04Z

Voici une entrée dans laquelle je vais présenter un problème que vous pourriez rencontrer lors d'une migration de votre serveur Team Foundation.

Bien que dans la majorité des migrations que nous effectuons, la procédure se résume à la simple exécution du programme d'installation, certaines petites manipulations ou configurations peuvent vous posait problèmes durant cette opération. Il semblerait que ce soit le cas pour la migration que j'ai opéré aujourd'***. Il s'agit d'une instance installée il y a de cela deux ans, qui n'a jamais posé de problème particulier hormis peut être avec Analysis Services. La remise en état du Warehouse se résumait à une reconstruction de l'entrepôt de données.

Voici donc l'erreur rencontrée durant la phase d'installation / migration:

Erreur 32000 : The Commandline '"C:\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Tools\TfsDb.exe" upgrade /server:"SERVER" /property:"TFS_SERVICE_ACCOUNT=SERVER\TFSSERVICE;TFS_REPORTING_ACCOUNT=SERVER\TFSREPORTS;LCID=1033;VSTF_AS_INSTANCE=SERVER;VSTF_AS_DATABASE=TFSWarehouse" /showui:196682' returned non-zero value: 100.

Cette erreur apparaît lors de la mise à jour de l'entrepôt de données, tiens, tiens...

La consultation des logs de l'installation présents dans les fichiers temporaires de l'utilisateur procédant à la migration nous révèle un premier indice :

Erreurs dans le gestionnaire de métadonnées. Une erreur s'est produite lors de l'instanciation d'un objet de métadonnées du fichier, « \\?\E:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Data\TFSWarehouse.0.db\Today.1452.dim.xml ».

En allant consulter le fichier indiqué dans le journal d'installation, j'ai pu constater qu'il s'agissait des informations de construction de la dimension Today du cube de Team Foundation Server. Dans ce fichier, qui semble être le fruit d'une sérialisation XML, l'erreur se comprend enfin : le fichier n'est pas valide, plus encore, il ne possède pas de balise de fin et n'est donc pas bien formé.

Après avoir pris conseil auprès de certains collègues plus au fait que moi dans les affaires de cubes et d'entrepôts, je prends mon courage à deux mains et renomme la dizaine de fichiers *.dim.xml qui semblent poser problèmes pour constater :

Que l'installation s'achève sans autre avertissemnet
Que les fichiers *.dim.xml ont été regénérés

L'architecture de Team Foundation est venue à notre rescousse car l'entrepôt de données et le cube peuvent être regénérés uniquement à l'aide des données présentes dans les différentes bases relationnelles (les données opérationnelles de TFS). Le fichier WareHouseSchema.xml, présent dans le répertoire d'installation de TFS, contient l'intégralité des définitions nécessaires à sa reconstruction et bien entendu , nous n'aurions pas pu supprimer la définition des dimensions dans une définition standard d'un entrepôt.

En espérant que vous n'ayez pas à vous servir de ce post...

Étendre les attributs des méthode de tests dans MsTest

2008-04-27T22:30:23Z

Un article très sympa de Justin Burtch est disponible ici.

Ce dernier a en effet développé quelques bouts de code permettant d'étendre les fonctionnalités de MsTest et permettre certaines configurations possibles avec mbUnit par exemple. Le code source est disponible en version Visual Studio 2005 mais la conversion ne m'a posé aucun problème.

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

2008-04-27T19:46:50Z

Complètement passée inaperçue lors de mon analyse des nouvelles fonctionalités de Visual Studio 2008, une limitation de la version 2005 du produit a disparu.

Rappel des faits

Les espaces de travail permettent de définir la liaison entre votre système de fichiers et votre contrôleur de source. Les liaisons multiples permettent de construire une vue de votre contrôleur, éventuellement composée d' éléments de différents projets d' équipe.

Revenons sur un cas d' utilisation, le Shared Source.

Imaginons un plateau de développement composé de deux équipes distinctes, une équipe "Framework" et une équipe "Applicatif". L'équipe "Framework" met à disposition des développeurs de l'équipe "Applicatif" un certain nombre de composants, facitlitant l'implémentation des applications et favorisant un développement homogène pour l'ensemble du plateau de développement.

Chaque équipe travaille dans son propre projet d'équipe.

Afin de faire partager leurs expériences de l'utilisation des composants, il a été décidé de mettre à disposition de l'équipe "Applicatif" les différents sources des composants qu'ils utilisent. Ils peuvent ainsi à tout moment effectuer des corrections qui seront potentiellement intégrées au code du framework après acceptation de l'équipe "Framework".

Une solution est de créer une branche du code source disponible du "Framework" dans le projet d'équipe "Applicatif". Cependant, cela impose aux développeurs de l'équipe "Applicatif" de mettre à jour le source à partir de la branche mère à chaque modification du framework et la gestion devient difficile si les équipes consommant le framework viennent à se multiplier.

Une autre solution consiste à créer une branche du code principal (branche Main) du framework directement dans le projet d'équipe "Framework" et à utiliser cette branche afin de permettre la diffusion et l'édition du source dans un référentiel partagé par toutes les équipes de développement. On utilise alors les liaisons multiples pour que les développeurs possèdent dans leur espace de travail :

le code de l'application en cours de réalisation

le code du framework utilisé

Problème avec TFS 2005

Le problème survient lorsque le code du framework doit faire partie de la solution de l' application afin de pouvoir travailler en mode projet sur les références du framework. En effet, il n'est pas possible de définir qu'une entrée du contrôleur de code source soit liée à votre système dans un sous dossier d' un dossier déjà utilisé dans un espace de travail.

Et pourtant, les développeurs ont l'habitude de retrouver dans une solution : 1 ou plusiers fichiers Sln à la racine et les dossiers contenant les projets.

Résolution TFS 2008

Cette limitation n'existe donc plus et nous pouvons donc allègrement définir ce genre de choses :

Soit le projet applicatif SmallBusiness dont voici la structure :

et un projet Framework dont la structure vous est ici présentée :

Nous pouvons maintenant définir un espace de travail permettant à l'équipe SmallBusiness de travailler avec le dossier LogTool directement dans le dossier Main :

Le résultat sur le système de fichier parle de lui même, le développeur pourra attacher très facilement le projet LogTool dans la solution SmallBusiness.sln.

Et la concurrence dans tout çà

Cette nouvelle fonctionnalité fait voler en éclats l'un des arguments de la concurrence. Certes il ne s'agissait pas d'une grosse limitation mais comme elle était âprement critiquée par certaines comparaisons entre TFS et plus particulièrement TFVC avec d'autres contrôleurs de source, certains clients me posaient la question.

Pour preuve, voilà un extrait d'un comparatif disponible ici : http://www.perforce.com/perforce/comparisons/perforce_mstfs.pdf http://www.perforce.com/perforce/comparisons/perforce_mstfs.pdf

TFS does not support sparse branching.
A user can individually “cloak” or “uncloak”
project folders. However, the same set of
files from two different repository folders
(for example, main and branch_x) cannot
be mapped to the same local folder in a
workspace.

Je connais quelques personnes ayant un document à mettre à jour...

Images VPC de test de Visual Studio Team System

2008-04-24T13:34:00Z

Ces images fournies par Microsoft permettent de tester l'intégralité des fonctionnalités de la plate-forme (clients et serveurs). Elles disposent également d'un ensemble d'ateliers permettant de prendre en main le produit.

L'image est disponible ici : http://www.microsoft.com/downloads/details.aspx?FamilyID=c7a809d8-8c9f-439f-8147-948bc6957812&displaylang=en et la dernière version expirera en décembre 2008.

Techdays 2008 - C'est fini pour moi

2008-02-13T09:15:11Z

L'édition 2008 s'achève dès ce matin pour moi. Après avoir donner deux sessions concernant Team System, je suis dès à présent de retour chez nos clients.

J'aimerais remercier tout le monde de l'accueil, l'engouement et la bonne humeur qui marqua cette édition et plus particulièrement les personnes qui m'ont accompagné durant les sessions, Vianney Lemaire d'Artegos et Florent Santin de Winwise.

Les sessions seront probablement disponibles d'ici un à deux mois sur le site média Microsoft.

Bien entendu, l'aventure ne s'arrête pas là et l'on pourra très prochainement se rencontrer, très prochainement...

Mais on y reviendra :D

Gauntlet passera sur TFS

2007-12-13T11:33:06Z

Si cela vous interesse bien entendu...

Construire ses versions à la hache?

Brian Harry vient d'annoncer la bonne nouvelle sur son blog. Le projet Gauntlet trouvera son implémentation dans Rosario, la future version de TFS.

Gauntlet

L'idée de Gauntlet vient modifier le processus de validation des builds dans le cadre de l'intégration (en particulier dans les grosses équipes).

En effet, comme on peut le constater dans TFS 2008 (avec la règle d'archivage "Builds") lorqu'une build qui n'a pas passé les critéres du processus automatisé (échec de compilation, de l'analyse statique, de l'exécution des tests unitaires ou le nom respect des QoS... ) on peut décider de bloquer la chaîne de production en interdisant tous les archivages sur le contrôleur de code source (sauf les tentatives de réparation de la build).

Cette technique trouve son origine dans les processus de Toyota qui stoppe la chaîne de production dès qu'une alerte est émise. Cependant et plus particulièrement dans les grosses équipes de développement ou dans les équipes réparties géographiquement, cette option perd de son sens et est très risquée.

Exemple : Pourquoi retarder la mise à disposition d'une fonctionnalité de l'équipe de Paris parce qu'un archivage de l'équipe de New York a provoqué l'échec de l'intégration continue? D'autant que les développeurs de Paris n'auront pas forcement les moyens d'y remedier pour pousser leurs modifications sur le référentiel.

Un projet communautaire permet dores et déjà tester cette politique : Open Gauntlet

les avantages

La démarche de Gauntlet est tout autre, quasiment l'inverse puisqu'elle revient à dire que si les modifications apportées n'ont pas respecté les critères de sortie d'une version, ces modifications doivent tout simplement être supprimées de la liste des modifications à constuire. On exclut donc le code défectueux pour donner la possibilité aux autres équipes ou autres développeurs de voir leur code être intégré.

Deuxième effet pertinent, l'intégration en tant que telle. Si l'équipe A a fournit un code défectueux et que l'équipe B doit attendre la résolution de ce code pour archiver, l'effort d'intégration reviendra à l'équipe B (qui n'a pour l'instant pas commi d'erreur). En revanche, dans la démarche de Gauntlet et de Gated Checkin de Rosario, l'effort d'intégration sera réalisé par l'équipe A, fautive dans le scénario présent, et avouons que cela semble plus juste.

Entre les lignes

Ce que l'on peut deviner également à la lecture de ce post de Mr Hary, c'est qu'une telle fonctionnalité réclame l'implémentation d'un mécanisme de comparaison des versions de notre projet afin d'exclure l'archive fautive. Cela nous laisse présager de grands changements dans l'avenir de TFVC (Team Foundaiton Version Control) et de Team Build et pourquoi pas les prémisses d'une approche de construction par composant de notre projet. Alléchant...

Fin de semaine de formation

2007-12-07T18:29:48Z

Cette semaine avait lieu, à l'initiative de Microsoft et plus particulièrement d'Eric Le Loc'h, 2 ateliers à destination des consultants des centres de compétences Team System.

Le premier avait pour objectif d'ouvrir de nouvelles possibilités de personnalisation et d'extension des projets d'équipes TFS en introduisant les concepts BI d'Analysis Services et de Reporting Services et leur fonctionnement autour des produits Team System.

Le second avait pour but de préparer au passage de la certification 70-510, concernant l'administration d'un serveur TFS.

Ayant co-animé la première et animé la seconde, j'aimerais remercier les participants pour le partage et l'ouverture d'esprit dont ils ont su faire preuve durant ce stage. Les questions posées étaient toutes pertinentes, la passion et le sérieux au rendez vous, et je dois avouer que donner des formations dans ce contexte fût un réel plaisir.