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…

Billet précédent

Un nouveau compagnon Outlook pour Team Foundation Server

Billet suivant

Images VPC de test de Visual Studio Team System

gabriel bélanger

Détenteur d’un baccalauréat en anthropologie et d’un certificat en journalisme, Gabriel s'intéresse au phénomène humain en général et en particulier aux communications. Sa rigueur et ses grandes aptitudes rédactionnelles contribuent au quotidien à faire de lui un collaborateur de choix en matière de création de contenu. Ayant œuvré dans divers contextes, tant au sein d’une grande agence que du côté client, il a eu la chance de se familiariser avec les nombreuses facettes de l’élaboration et de la diffusion de campagnes de communication. Il s’est joint récemment à l’équipe de Pyxis.