Industrialisation d'un projet "legacy" (2/2)

Je travaille actuellement sur l'industrialisation d'un gros projet "legacy" : je mets en place le build par Maven, l'intégration continue avec Jenkins, et la qualimétrie avec notamment PMD et Checkstyle, configurés via Sonar.

Le précédent billet expliquait comment j'avais réussi à placer le projet sous intégration continue avec Maven et Jenkins ; dans celui-ci, je parlerai de qualimétrie avec Sonar, PMD et Checkstyle.

Sonar : bip, bip, bip, bug !

Sonar est déployé depuis peu sur le SI. Il est utilisé - sans grande conviction- sur quelques projets, pour fournir des métriques basiques comme la taille des méthodes et la complexité du code. Le fait que les projets ne sont actuellement pas compilés indépendamment de l'IDE limite son utilité...

Néanmoins, il fournit une interface très pratique pour configurer PMD et Checkstyle :

Ces réglages sont ensuite accessibles en ligne, via des "permaliens" :

Et justement, les plugins PMD et Checktyle pour Maven autorisent l'import de règles à partir d'URLs ! Quelle aubaine ! Sauf que... celles exposées par Sonar comportent des symboles que Maven n'accepte pas, notamment les "?" et "&". C'était trop simple...

UrlRewrite à la rescousse

Bon, à tout problème sa solution. Puisqu'il y a un problème d'URL, modifions l'URL.
Avec Apache et le mod_rewrite, ce serait facile ; mais je n'ai que Tomcat sous la main, qui héberge déjà Jenkins.

En cherchant sur Internet, j'ai découvert UrlRewriteFilter, un port de mod_rewrite sous la forme d'un filtre Java EE. Les règles de mapping sont définies dans le fichier urlrewrite.xml.
J'ai donc créé et déployé une mini application web contenant uniquement ce filtre, que j'ai configuré comme suit :

<urlrewrite>
    <rule>
        <from>/pmd/(.*)</from>
        <to type="redirect">http://<sonar>/profiles/export?language=java&amp;format=pmd&amp;name=$1</to>
    </rule>
    <rule>
        <from>/findbugs/(.*)</from>
        <to type="redirect">http://<sonar>/profiles/export?language=java&amp;format=findbugs&amp;name=$1</to>
    </rule>
    <rule>
        <from>/checkstyle/(.*)</from>
        <to type="redirect">http://<sonar>/profiles/export?language=java&amp;format=checkstyle&amp;name=$1</to>
    </rule>
</urlrewrite>

Grâce à ce mapping ô combien astucieux (n'est-ce pas), je peux désormais utiliser les plugins PMD et Checkstyle de Maven, et les faire pointer sur les règles exportées par Sonar :

<reporting>
    <plugins>
 
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-checkstyle-plugin</artifactId>
            <version>2.6</version>
            <configuration>
                <configLocation>http://localhost/urlrewriter/checkstyle/Sun%2520checks</configLocation>
            </configuration>
        </plugin>
 
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-pmd-plugin</artifactId>
            <version>2.5</version>
            <configuration>
                <rulesets>
                    <ruleset>http://localhost/urlrewriter/pmd/Sun%2520checks</ruleset>
                </rulesets>
            </configuration>
        </plugin>
 
    </plugins>
</reporting>

Un petit tour dans Jenkins ensuite pour activer les rapports PMD et Checkstyle, et le tour est joué !

Conclusion

Ainsi se termine la passionnante épopée de l'industrialisation d'un bon vieux projet "legacy".
Oh bien sûr, ce n'est sans doute pas parfait, et certains aspects relèvent un peu de la bidouille, mais au moins ça fonctionne.

Aujourd'hui le projet est construit toutes les heures, passe les tests unitaires (j'en reparlerai bientôt) ainsi que les analyses de PMD et Checkstyle. Les équipes ont enfin une vue synthétique de la qualité du code, et je suis content de les voir se piquer au jeu de la réduction de la dette technique. Quant aux builds en échec... ils ne le restent pas bien longtemps, le coupable (moi, quelquefois) étant bien souvent prévenu par ses collègues avant même d'avoir eu le temps de lire le mail d'alerte !

Je conclurai en encourageant tous les développeurs intervenant sur des projets "legacy" à mettre en place une usine logicielle, même si elle n'est pas tout à fait réalisée dans les règles de l'art. Une journée suffit, et le bénéfice est immédiat.

Commentaires

1. Le mercredi 3 août 2011, 12:12 par Jean

Hmm, pourquoi utiliser apache et mod_rewrite ? Si maven "n'accepte" pas les ? et les & dans les urls c'est qu'il ne gère pas correctment les URLs. Le problème est plus probablement dans un des plugins que dans maven même non ? il devrait suffire de corriger le plugin non ?

Corriger le plugin aurait eu l'avantage d'éviter a tout ceux qui ont le même problème et qui ne peuvent pas (ou disons difficilement, tout est toujours possible juste parfois extrêmement compliqué) utiliser un frontal apache avec mod_rewrite (parcequ'ils ne sont pas dans la cellule d'architecture du SI qui va bien dans la Grosse Boite (tm) dans laquelle ils bossent :) ) ...

2. Le mercredi 3 août 2011, 13:27 par Olivier Croisier

Idéalement oui, mais je n'ai ni le temps ni les compétences pour ouvrir les entrailles de Maven et tenter de corriger ce "bug" (entre guillemets, car je ne sais pas s'il s'agit vraiment d'un bug ou s'il existe un solution alternative).
Et puis, comme indiqué dans le billet, quand on n'a pas d'Apache sous la main, on peut toujours utiliser le filtre UrlRewriteFilter, déployé par exemple à côté de Jenkins. La solution de contournement est donc assez simple.

3. Le vendredi 5 août 2011, 01:36 par Grégory Boissinot

Le fait que les membres de l’équipe projet ne vont pas regarder les rapports Sonar ne m’étonne pas du tout. Contrairement à Jenkins qui est dédié aux développeurs, Sonar est avant tout dédié aux chefs de projet et aux managers. Son but premier est d’avoir une tendance de l’évolution des métriques dans le temps (par exemple par semaine, par mois, par date de livraison, …). Ce n’est donc pas un outil au quotidien des développeurs pour le suivi du commit d’intégration continue.
Des éléments dans Sonar comme la possibilité de configurer les règles ou leur systèmes d’alertes peuvent faire penser le contraire mais ce n’est que utopie car nous somme vite limités. La raison première est que Sonar n’a pas la main sur le checkout du code source et sur l’infrastructure cible. Ainsi il ne devrait pas avoir la main sur le run de la qualimétrie (souvent trop complexe et qui doit être réservé à des outils tiers).
C’est pourquoi, utiliser Sonar comme référentiel des règles est hautement discutable.
De mon point de vue, l’intérêt de Sonar est son collecteur et la fusion de résultats de métriques par typologie.

4. Le lundi 8 août 2011, 13:32 par kris78

C'est vrai que Sonar est pas mal pour avoir une vue synthétique des projets : nombre de lignes de codes (représentatif de la taille du projet), nom de classe, pourcentage de lignes de codes copiés ^_^.
J'utilise le plugin FindBugs. Il ajoute des règles "Findbugs" en plus de celle de Sonar. Il suffit juste les choisir en mode admin. Ce qui est pal mal aussi mais prend beaucoup plus de temps, c'est de paramétrer les règles dont certaines me paraissent peu utiles...
Par contre, tu ne parles pas de l'aspect configuration de la base de données utilisées par Sonar.
Par défaut, c'est un Apache Derby(enfin à l'époque). J'ai remarqué utilisant un MySQL, Sonar avait un peu moins de mal après un certain nombre d'analyses.
Son coté 'historisation' peut aussi intéressé les développeurs. On voit entre les différentes analyses si on a fait mieux ou moins bien ^_^.
Enfin, je ne sais pas si c'est valable pour toi, mais qu'en j'utilisais Hudson, je n'avais pas mes défauts d'affichage sous IE8 que j'ai maintenant avec Jenkins :-S
Dommage aussi qu'il n'ait toujours pas rajouter le lien qui permet de changer d'utilisateur SVN :-P
Pour info :http://ton_host:port/jenkins/scm/Su...
Encore un dernier détail, une journée suffit quand on a la bonne infrastructure ^_^.
Souvent j'ai du installé ce genre de plateforme sur une machine du réseau mais sans accès internet :'( . Après, il faut aussi un compte SVN dédié. Si ça utilise un compte avec un mot de passe qui change, bonjour le build failed quand le celui-ci change :-P
Enfin, sous Jenkins ou Hudson, il faut aussi configurer les comptes utilisateurs pour que tout le monde (qui accède à la console) ne puissent lancer des builds manuels ^_^
En tout cas ce sont de super outils ^_^ (Big Fan)

5. Le lundi 29 août 2011, 13:59 par Jean-Christophe Sirot

> Sauf que... celles exposées par Sonar comportent des symboles que Maven n'accepte pas,
> notamment les "?" et "&". C'était trop simple

Par curiosité j'ai fait le test sur mon infrastructure (maven 2.2.1 avec le plugin maven checkstyle 2.6) et en entourant l'URL dans la base <configLocation/> avec un bon vieux <!CDATA[ ...]> ça passe très bien.

6. Le mardi 30 août 2011, 14:30 par Olivier Croisier

@jcsirot Merci pour le tip, effectivement ça marche avec Checkstyle, mais pas avec PMD (et je n'ai pas testé avec Findbugs).