Batswirl's home

Urban Turtle : Des graphiques d’avancement dans vos projets

batswirl — Mon, 09 Aug 2010 14:29:00 GMT

Aujourd ***, l’équipe Urban Turtle est fière de proposer une nouvelle version de son outil de gestion agile avec Team Foundation Server.

Cette dernière version propose aux équipes travaillant avec le dernier modèle de processus Visual Studio Scrum 1.0 un graphique d’avancement temps réel (donc pas de warehouse, d’analysis services etc…).

La dernière version est téléchargeable à l’endroit habituel : Download URBAN TURTLE

Une tortue flashée a 240!!!

batswirl — Mon, 19 Jul 2010 18:11:05 GMT

Prise sur l’autoroute de la livraison, à la poursuite d’un modèle de processus qui venait de sortir. La tortue est désormais recherchée. Elle risque des années de travaux d’intérêts généraux, notamment dans le rôle d’accélératrice de solution pour les projets Scrum avec Team Foundation Server.

Source : Urban Turtle delivers a kick-ass experience for Scrum in Visual Studio Team Foundation Server

Pour télécharger la version compatible avec le tout chaud modèle de processus Microsoft Visual Studio Scrum : Urban Turtle

Scrum.org la révolution des développeurs

batswirl — Mon, 26 Apr 2010 14:44:00 GMT

Si vous ne connaissez pas encore Scrum.org et que vous travaillez actuellement dans un contexte agile, je vous conseille fortement de faire une petite visite sur le site.

Il s'agit d'une nouvelle initiative visant à promouvoir Scrum et l'agilité et à former les acteurs d'un projet à ces nouveaux contextes.

Ken Schwaber, le papa de Scrum, est à l'origine du projet et a établi un programme spécifique pour les développeurs. Le programme comble ainsi un manque terrible dans bon nombres de cursus agiles : la formation des développeurs.
L'objectif est ici de fournir la connaissance des outils et des pratiques qui permettront à un développeur de répondre aux différentes contraintes des projets agiles :

réactivité
Développement empirique
gestion du changement
collaboration
...

A l'heure actuelle, deux cursus sont disponibles pour les deux plate-formes majeures de l'industrie .Net et Java.
A Pyxis technologies, nous comptons parmi nous les 2 seuls formateurs francophones (Eric Mignot et Ernst Perpignand) et j'aurais l'occasion de binômer avec eux sur ces formations et ainsi apporter mes connaissances et mon expérience sur Team System et Team Foundation Server.

Les dates :

du 7 au 11 juin à Montréal

du 21 au 25 juin à Paris

En espérant vous rencontrer devant un VS10 pour parler architecture agile, TDD, scripts de build…

Le modèle de Kano, une force dans vos projets agiles

batswirl — Wed, 14 Apr 2010 14:38:00 GMT

Le modèle de Kano est un outil permettant la priorisation des éléments d’un projet en projetant la disponibilité d’une fonctionnalité sur la satisfaction que celle ci apporte. La grande force de ce modèle tient dans son postulat de base : La satisfaction ou l’insatisfaction d’un utilisateur pour un même point n’est pas une notion diamétralement opposée : «Ce n’est pas parce qu’une fonctionnalité livrée augmente la satisfaction de l’utilisateur que l’absence de cette même fonctionnalité aurait eu un impact négatif vis à vis de la satisfaction utilisateur».

De ce postulat, le modèle propose de sonder les utilisateurs en mesurant leur satisfaction du produit final dans le cas de la mise à disposition et dans le cas de l’absence de chacune des fonctionnalités.

Je vous laisse faire quelques recherches pour explorer plus en avant ce modèle car dans ce billet, j’aimerais m’attarder sur un point particulier, à savoir le recensement et la livraison des fonctionnalités de base.

Les fonctionnalités de base (basic needs) sont des points cruciaux pour la réussite de votre projet mais celles ci sont fourbes, elles ne sont pas clairement exprimées, on dit qu’elles sont implicites. Obligatoires et implicites, vous voyez ou je veux en venir...

Dans nos processus de développement agiles, la sollicitation des utilisateurs dans la définition des fonctionnalités est point essentiel. On tente ainsi de remédier à la dérive fonctionnelle des projets dont les spécifications ont été rédigés par des informaticiens.

Chaque fonctionnalité apportera un service, de la valeur ajoutée à l’utilisateur.

GOOD ENOUGH SOFTWARE

Dans un extrême caricatural, des équipes se laissent ainsi guider par des carnets de produits entièrement rédigé par un utilisateur. Ils vont forcement atteindre le GOOD ENOUGH SOFTWARE, pas de fioritures, pas de gadgets, jusque ce qu’il lui faut. Prétextant une volonté de ne pas vouloir influencer leur gestionnaire de produit, certaines équipes se refusent même à évoquer certaines fonctionnalités qu’elle trouve intéressantes.

Il faut pourtant se rendre à l’évidence, nos gestionnaires de produits ont rarement l’expérience ou les connaissances techniques qui leur permettent de déduire des fonctionnalités de base ou de mesurer l’impact de l’absence de certains points fonctionnels.

Comme toujours la solution réside dans la collaboration entre les membres de l’équipe et son gestionnaire de produit et le modèle de Kano offre ici un cadre de collaboration explicite :

L’équipe détecte une fonctionnalité basique, décrit la valeur ajoutée.

Le gestionnaire de produit mesure la satisfaction apportée par la livraison ou l’absence de cette fonctionnalité dans le produit final.

La fonctionnalité rentre dans le carnet de produit, ou pas!

C’est simple et ça devrait facilement pouvoir s’intégrer dans une maintenance de carnet (backlog maintenance).

Je mocke, tu mockes, il mocke... nous loupons un refactoring

batswirl — Fri, 19 Mar 2010 00:14:00 GMT

Avant de mocker un composant, assurez vous que les difficultés que vous rencontrez à le tester ne proviennent pas du composant lui même.

PS : Je sais c'est court mais je crois que c'est pertinent et que le message passera mieux. D'autant que je m'en fait un pense bête à lire 10x ou 15x par jour tellement c'est évident et qu'on arrive à passer à côté.

Test d'intégrataire ou test d'unigration

batswirl — Thu, 18 Mar 2010 23:49:00 GMT

Ces dernières semaines durant mon développement ou autour d'un autre binôme à Pyxis, j'ai été confronté à cette discussion qui trainait et qui au final ralentissait le développement :

Membre de l'équipe 1 : A ton avis, c'est un test d'intégration ou un test unitaire?

Membre de l'équipe 2 : ouf, y'a un fichier XML à utiliser, je vois pas comment s'en passer sans perdre le sens du test, çà doit forcement être un test d'intégration.

Membre de l'équipe 1 : Oui mais, il y a pleins de traitement différents que j'aimerais tester unitairement alors faire un test d'intégration avec le fichier...

Membre de l'équipe 2 : bon bah on va faire deux tests alors. Mais on fait quoi en premier?

Membre de l'équipe 1 : Bah c'est évident, on commence par l'unitaire.

Membre de l'équipe 2 : Et on fait comment pour le fichier?

Constat

A partir de ce point, on tourne en rond. On cherche à tester unitairement pour se rendre compte que l'on n'arrive pas à isoler ce maudit fichier.

Pattern

De ce que j'ai pu observé dans les différentes situations auxquelles j'ai été confrontées, le problème était le même. La question ne venait pas de la façon d'aborder les tests du composant mais bien le composant en lui même. Celui-ci dépendait d'une ressource (fichier XML, base de données, Service distant) lui fournissant des services de données. Ce même composant proposait un certain nombres de routines de traitement de ces mêmes données.

Logique + données, pourquoi ne pas séparer?

Au final, la résolution passait par une séparation de ces deux aspects du comportement. On extrait la partie accès aux données et la partie traitement. Rien de novateur, là dedans, ce qui l'est davantage pour moi (et je pense que vous en conviendrez), c'est que les tests ont facilité de détecter ce pattern et par expérience désormais si j'entend un développeur se posait la question : Test d'intégration ou test unitaire? je lui suggérerais en tout premier lieu de revoir le code ciblé par le test( ou l'idée qu'il s'en faisait en TDD).

Rhino Mock / MSTest : Isolation

batswirl — Sun, 07 Feb 2010 21:23:00 GMT

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

batswirl — Thu, 04 Feb 2010 10:38:00 GMT

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

batswirl — Mon, 20 Jul 2009 03:25:21 GMT

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

batswirl — Sat, 16 May 2009 08:49:34 GMT

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

batswirl — Wed, 22 Apr 2009 08:42:45 GMT

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

batswirl — Thu, 09 Oct 2008 05:39:14 GMT

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

batswirl — Mon, 21 Jul 2008 12:00:25 GMT

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

batswirl — Tue, 29 Apr 2008 19:41:00 GMT

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

batswirl — Mon, 28 Apr 2008 20:25:04 GMT

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

batswirl — Sun, 27 Apr 2008 22:30:23 GMT

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

batswirl — Sun, 27 Apr 2008 19:46:50 GMT

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

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

batswirl — Sun, 27 Apr 2008 19:46:50 GMT

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

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

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

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

le code du framework utilisé

Problème avec TFS 2005

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 çà

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

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

Images VPC de test de Visual Studio Team System

batswirl — Thu, 24 Apr 2008 13:34:00 GMT

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

batswirl — Wed, 13 Feb 2008 09:15:11 GMT

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

batswirl — Thu, 13 Dec 2007 11:33:06 GMT

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

batswirl — Fri, 07 Dec 2007 18:29:48 GMT

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.

Un nouveau compagnon Outlook pour Team Foundation Server

batswirl — Tue, 16 Oct 2007 10:18:26 GMT

Annonce officielle de la sortie de Team Companion par la société Ekobit, plugin Outlook permettant la connexion à votre base de données d'éléments de travail à partir de Microsoft Outlook.

Références Team System

batswirl — Thu, 04 Oct 2007 12:33:00 GMT

Afin de parfaire votre apprentissage de Team System, voici quelques liens et recommandations de lectures :

Sites

MSDN Team System : le site MSDN France des produits Team System

Team System Rocks : regroupe les posts de blogs les plus interessants concernat Team System

Brian Harry : Le blog du Program Manager le plus actif de Team System qui publie notamment les comptes rendus sur l'utilisation en interne (chez Microsoft) de Team System

Channel 9 - Visual Studio : Découvrez les nouveautés et le futur de la gamme à l'aide des reportages vidéos de Channel 9

Articles

Cyclomatic complexity : La définition du SEI de la complexité cyclomatique que nous retrouvons maintenant dans Visual Studio Team System For Software Developper avec les Code Metrics.

Index maintainability : La définition officielle d'une autre métrique interessante des Code Metrics.

Outils

Power tools : le site des extensions proposées par Microsoft pour Team Foundation Server

Attrice Corporation : auteur des outils Team Foundation SideKicks et Team Build SideKicks

TFS Admin : outil d'administration de TFS

TFS Event Subscription Tool : outil d'abonnement aux évènements TFS

Automaton : outil d'intégration continue

CI par Microsoft : le tutorial et le code associé à la mise en place d'une build continu

Team Build

Community Tasks : Librairie de tâches MSBuild

SDC Tasks : Librairie de tâches MSBuild

Livres

Gestion de configuration

Configuration Management Principles and Practice par Anne Mette Hass et Glenn Hass

The Build Master: Microsoft's Software Configuration Management Best Practices par Vincent Maraia

Software Configuration Management Patterns: Effective Teamwork, Practical Integration par Stephen P. Berczuk, Steve Berczuk, et Brad Appleton

Team System

Visual Studio Team System: Better Software Development for Agile Teams par Will Stott et James W. Newkirk

Software Engineering With Microsoft Visual Studio Team System par Sam Guckenheimer et Juan J. Perez

Professional Visual Studio 2005 Team System par Jean-Luc David, Tony Loton, et Erik Gunvaldson

Tests

Test-Driven Development: By Example par Kent Beck

Test-Driven Development in Microsoft .Net par James W. Newkirk et Alexei A. Vorontsov

Builder une solution à partir d'un Label

batswirl — Wed, 15 Aug 2007 20:47:00 GMT

Un petit truc dont de nombreux clients ayant fait appel à Team Build pour la construction de leur solution s'étonnent, à savoir la possibilité de modifier le comportement par défaut lors de la récupération des sources. En effet, par défaut, Team Build récupère la dernière version des fichiers composants la solution. Or vous voudriez peut être récupéèer la version correspondant à un label flottant (ex : Production).

Si tel est le cas, il vous faudra effectuer deux choses :

Surcharger la tâche Get de Team Build afin de lui préciser que vous allez vous occuper de la récupération des sources
Appeler la tâche Get en précisant la version souhaitée

Pour surcharger l'étape de récupération des sources, tout est prévu dans Team Build, il suffit d'ajouter un propriété SkipGet dans votre projet de Build :

...

<PropertyGroup>
<SkipGet>true</SkipGet>
...

Ensuite, il ne vous reste plus qu'à récupèrer le code correspondant à votre projet en spécifiant la verison spécifique, ici, je le fais avant la création du label fixe créé par Team Build :

<Target Name="BeforeLabel" >
<Get Condition="" Workspace="$(WorkspaceName)" Recursive="$(RecursiveGet)" Force="$(ForceGet)" Version="LClean@"/>
</Target>

Toutes les propriétés sont celles par défaut sauf pour l'attribut Version. Clean est le nom de mon label flottant permettant de définir les versions à compiler pour la clean build (build intégrale de la solution et exécution de l'ensembles des tests, configurations, automatisations etc...).

Cette propriété prend donc en paramètre : "L" + "<Nom du label>" + "@" + "<Scope>"

Le "L" définit que nous souhaitons récupérer les sources à partir d'un label dont le nom est indiqué. Vous pouvez également récupére le source à partir d'une date ("D"), d'un change set ("C") etc...

Le scope est optionnel et permet de restreindre la récupération des sources (on aurait pu fournir une url du contrôleur de code source, ex : $/mon projet/Main/DAL).

Label Flottant et Label Fixe :

De nombreux contrôleur de code source fournissent un mécanisme permettant de rassembler un ensemble de fichier d'une version particulière sous un nom commun. Les étiquettes de Visual Source Safe sont reprises dans Team Foundation Version Control. Un Label (étiquette) se construit en sélectionnant les fichiers qui le compose mais vous pourez par la suite modifier ces fichiers.

Ainsi, il apparaît que les équipes de développement ou les administrateurs du contrôleur définissent deux types de label :

Label fixe : Définit un fois pour toute, permet de gérer les différentes versions livrées. L'objectif étant de permettre une récupération rapide de la version d'un environnement, actuellement chez un client ou qui a vu une modificaiton notoire. Exemples de noms de labels fixes ( Livraison Mars 2007, Correctif Client Dupond, Publication Site Avril 2006, Main 2.1.0..., Modification provider). Les labels fixes étant par définition, non modifié, sont les seuls garants de récupérer une version stable après un régression.

Label flottant : Définit au fur et à mesure des itérations et de la progression du projet. Le label flottant est une référence pour l'équipe de développement qui lui permet de récupérer une version des sources en rapport à un contexte. Le nom du label flottant n'a en général aucune information temporelle et son contenu évolue en quasi permanence. Exemples de noms de labels flottants (Production, DAL Oracle, Mobile Web Design, Recette...)