Pyxis

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

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.