Archives par étiquette : TFS 2010

image

Forcer les developpeurs a mettre des commentaires de changesets pertinents

Ecrire des commentaires de checkins pertinents fait parti  des tâches simples que l’on a du mal à faire comprendre et accepter des équipes.

Les tâches non liées à l’écriture de code mais qui sont là pour faciliter la maintenance des applications (via dans le cas présent une meilleure traçabilité des modifications effectuées) sont il est vrai souvent considérées par les développeurs comme des tâches moins importantes, moins prioritaires, des tâches de seconde classe.

Par fainéantise, ou par désintérêt on se retrouve le plus souvent avec ce type de commentaire :

image

Des commentaires (lorsqu’ils sont présent ce qui n’est pas le cas pour le changeset 7817) qui n’ont aucune valeur.

Le problème est important puisque cela conduit à ce genre de choses :

image

Un historique de fichier inutilisable  où on ne sait pas ce qui s’est passé sauf à passer beaucoup de temps à faire des compare entre chaque changeset.

Lors d’une discussion avec un responsable ALM, celui-ci m’indiquait qu’il n’arrivait pas à arriver à ce type de résultat :

image Un résultat certes imparfait mais quand même de qualité, avec des information utiles qui pourront être consultées dans le futur.

Pour parvenir à cela, et bien évidemment après avoir expliqué à l’équipe en quoi il est important de placer des commentaires pertinents, j’ai été obligé de passer en mode “dictateur”, et TFS propose une solution simple pour y arriver : les alertes.

Afin “d’encourager” les membres d’une équipe il suffit de se créer une alerte sur tous les checkins lié à un Team Project :

image

Une fois le mail d’alerte reçu, sachez qu’il est possible de directement répondre à ce mail afin de communiquer avec le développeur. – Je vous invite à consulter cet ancien post qui décrit le process -.

Ainsi vous pouvez réagir très rapidement à ces mauvais commentaires en demandant au développeur fautif de modifier à posteriori son commentaire afin qu’il soit pertinent.

Après avoir reçu plusieurs mails de rappel à l’ordre demandant de corriger le problème, les plus récalcitrants rentrent ainsi dans le bon chemin sur une période de temps assez courte (environ 1 mois dans mon cas).

SNAGHTML62193f3

Faire du reporting simplement avec TFS OData et Tableau

Lors de la session sur la visibilité des applications Windows 8, j’ai présenté certaines fonctionnalités à partir de l’application exemple TFSDashboard.

Cette application utilise les services OData exposés via ce package additionnel : http://www.microsoft.com/en-us/download/details.aspx?id=36230

A noter que ces services OData sont installés par défaut et disponibles sur TFS Service : https://tfsodata.visualstudio.com/

Une fois ce package installé vous pouvez requêter directement les informations stockées par TFS (Team Projects, Work Items, Builds, Changesets, etc.) depuis des applications tiers (Windows 8, Windows Phone, Web, etc.) sans avoir à utiliser le SDK de TFS.

Autre possibilité, utiliser ces services afin de proposer à certains utilisateurs (ScrumMaster ou Product Owners) de créer leur propre reporting.

Afin d’illustrer cela, je vous propose d’utiliser Tableau Public, cette version de Tableau est gratuite et permet aux utilisateurs finaux de créer des rapports intéractifs depuis des fichiers Excel, des fichiers texte ou encore des services OData.

Pour cela créer une nouvelle connection en spécifiant la requête que vous souhaitez exécuter :

SNAGHTML62193f3

Indiquer les champs que vous souhaitez utiliser en lignes et colonnes mais également vos filtres :

SNAGHTML62397a3

Une publication plus tard et on dispose d’un rapport interactif permettant d’avoir une vision de l’activité des développeurs par rapport à leurs checkins :

En savoir plus :
Télécharger TFS OData
Télécharger Tableau Public

image

La revue de code “du pauvre” avec TFS 2010

imageQue cela soit pour les prestataires auxquels nous faisons appels ou pour le code produit en interne par notre service développement, lors de mon arrivée dans ma nouvelle société, j’ai souhaité mettre en place des revues de code afin :

 

 

  • d’avoir une vision précise de la qualité de code produite en interne et en externe
  • être capable d’évaluer les compétences des prestataires auxquels nous faisons appels
  • Déceler les non-conformités le plus rapidement possible afin de mener des actions correctives les moins couteuses possibles
  • faire monter en compétence l’équipe interne en faisant des revues de code en binôme, et en ciblant les formations internes en fonction des lacunes constatées.

Pour cela, j’ai donc cherché comment effectué des revues de code le plus simplement possible avec Visual Studio 2010 et TFS 2010. Visual Studio 2010 ne proposant pas encore de fonctionnalité intégrée comme cela sera pour la V.next, je vous proprose via ce post ma méthode pour parvenir à effectuer ces revues de code, de manière simple et rapide.

Et pour cela, j’utilise la fonctionnalité des alertes de TFS 2010. Il est en effet possible de s’abonner à tout checkin effectué sur un team project directement depuis Visual Studio :

image

Et avec TFS 2010, ces alertes ont gagné de l’intérêt puisqu’elles bénéficient de l’intégration native de Team Web Access :

image

Chaque item présent dans un changeset peut être pointé via un lien, lien renvoyant directement vers le compare avec la précédente version, ce qui permet de simplement voir l’évolution du code entre les deux versions (celle checkinée, et celle avant la modification) :

image

De plus,  les développeurs de TFS ont eu la bonne idée de définir un header reply-to dans les mails des alertes.

Ce qui fait que l’on peut directement répondre à un mail d’alerte, celui-ci arrivera directement dans la boite du développeur qui a effectué le checkin. Ainsi si l’on suit le screenshot du dessus, au lieu de répondre à tfsservice@loginspace.fr qui a envoyé le mail d’alerte, cela sera bien le développeur qui a effectué le checkin qui recevra le mail :

image

Cette technique permet donc d’effectuer des revues de code simplement, en analysant le code modifié grâce aux alertes, et en faisant les remontées aux développeurs directement par mail, ou via des sessions de revues de code en binôme lorsque cela le nécessite.

L’avantage de cette technique réside dans sa simplicité (pas de mise en place d’usine à gaz), et dans le fait que je peux être très réactif (je fais mes revues tous les jours en fin ou début de journée).

L’inconvénient majeur est que le code revu est déjà présent dans le repository. Ce qui nécessite un second checkin pour corriger le code après une revue.

Dans un prochain post, je détaillerais les configurations d’Outlook que j’ai effectué afin d’améliorer encore ce processus de code.