Discussion :

[goldandlink]

Bonjour,


je suis utilisateur régulier des outils Checkstyle, PMD, FindBugs.

Le tout avec maven, dans Hudson.


Ma question est la suivante : est-ce qu'il existe un plugin (maven ou hudson) qui permette de déterminer les différences de qualimétrie entre deux commits liés à un même ID (à travers le commentaire du commit) ?


Je vais illustrer par un exemple, ce sera plus clair (même pour moi ).


J'ai deux développeurs dans mon équipe : D1 et D2.
J'affecte une tâche à chacun des développeurs : T1 pour D1 et T2 pour D2.

Chaque développeur, lorsqu'il fait un commit (dans svn ou autre), doit commenter son commit en renseignant l'ID de la tâche, par exemple D1 fait un commit :
[ID-T1] Correction bla-bla

Imaginons que j'ai une itération de développement de deux semaines.
Mon projet comporte 5 classes : C1, C2, C3, C4, et C5.


Si je regarde l'historique des commits durant ces deux semaines, j'ai ceci :

1°) D1 commit sur C1 et C3 (sur T1)
2°) D2 commit sur C2 et C4 (sur T2)
3°) D2 commit sur C5 (sur T2)
4°) D1 commit sur C1 et C4 (sur T1)
5°) D1 commit sur C1 (sur T1)

J'ai volontairement mis une difficulté (qui n'en est peut-être pas une, si ça se trouve) en mettant une classe (C4) modifiée à la fois par D1 et D2


Ce que j'aimerais, c'est être capable de déterminer très facilement les changements en termes de qualimétrie sur une tâche précise.

L'outil ou plugin que je cherche enchaînerait en quelque sorte les actions suivantes :
1°) Faire un rapport de qualimétrie avant la première modification (facile, ça existe déjà)
2°) Déterminer les impacts apportés par T1 et T2 (donc par ex être capable dire que sur T1, les classes C1, C2, C3 et C4 ont été modifiées de telle manière)
3°) Faire un nouveau rapport de qualimétrie après chaque commit pour déterminer le delta, et additionner tout ça sur l'ensemble des commits d'une tâche

A l'issue de cette analyse, j'aurais un résultat du type :
T1 : +8 Checkstyle, -7 PMD, +2 Findbugs
T2 : +41 Checkstyle, +17 PMD, +24 Findbugs

Idéalement il faudrait pour les +x être capable d'avoir la liste des règles violées concernées.

L'idée est de pouvoir quantifier facilement les impacts en termes de qualimétrie du développement d'une tâche sur une itération.

Je pourrais par exemple dire : Attention sur la tâche 2, c'est devenu très crade, source potentielle de bugs en prod, augmentation de la dette technique, etc...



Sur Hudson il existe un plugin sur le mode d'un jeu, qui permet d'attribuer des bons ou mauvais points aux développeurs, en s'appuyant sur des différentiels à chacun de leurs commit. L'outil est donc capable de faire ces analyses selon la personne qui commit. Il faudrait donc un outil qui soit capable de faire la même chose, mais en triant selon les [ID-Tx] des commentaires de commit.


Est-ce qu'il existe un outil ou un plugin qui fasse ça ?
Ou est-ce que je dois coder à la mimine un programme qui parse les rapports xml de Checkstyle, PMD, FindBugs pour calculer les différences, etc... ? A moins que quelqu'un ait déjà eu à développer ce type d'outil ?

J'espère que je n'ai pas été trop confus dans mon illustration

En tout cas merci d'avoir lu jusque là, et merci d'avance pour vos retours

[romaintaz]

Bonsoir,

C'est quand même super spécifique ce que tu cherches à faire là !

Le plugin "CI Game" dont tu parles gère ça de façon très basique :

Entre un Build N et un Build N+1, il va attribuer des points selon un barème spécifique : +1 pour un build OK, +1 pour tout test corrigé ou nouveau, -10 pour un build cassé et -1 pour tout nouvel échec de test (d'autres points sont attribués si l'on utilise des plugins d'analyse de qualité). Mais il va attribuer ces points à tous les commiteurs entre N et N+1. Ainsi, si dev1 et dev2 commitent tous les 2 entre les builds N et N+1, et que dev1 inclue un bug, dev2 sera aussi pénalisé. A moins que cela n'ait changé dans les versions plus récentes, ce déterminisme n'est pas tellement intelligent. Il n'est pas capable de dire qui de dev1 ou dev2 a cassé quelque chose.

En fait, Hudson (ou Jenkins) réagit pareil : dans mon exemple précédent, les deux développeurs vont recevoir le mail d'alerte, bien que seul dev1 soit en réalité concerné par l'erreur...

C'est aussi pour cela que l'intégration continue prône des commits les plus légers possibles, mais très fréquents. Cela permet surtout de savoir quelle modification ajoute un problème ou une régression.

Pour en revenir à ton sujet, je ne pense pas que tu trouveras complètement ton bonheur, à moins de développer ton propre plugin.

Toutefois, j'ai quelque chose à te proposer. Pourquoi n'utilisez vous pas Sonar dans votre environnement ? Ca pourrait vous être utile.
Là où ça peut être utile dans ton cas précis, c'est que depuis peu (v2.7 si je ne m'abuse), on peut voir l'évolution des métriques (dont les violations PMD/Checkstyle/Findbugs) dans un laps de temps donné (lors des 5 derniers jours, 30 derniers jours, ou en fonction de 2 dates paramétrables).
Tu pourrais ainsi par ex. savoir que tu as eu +/-X violations sur tes 15 derniers jours.
Certes cela ne te permet pas d'avoir le détail au niveau d'une évolution, mais seulement au niveau temporel, ce qui est à mon avis déjà pas mal !

Plus d'infos sur cette fonctionnalité ici : http://www.sonarsource.org/different...us-inspection/

J'espère avoir pu répondre à tes interrogations...