Avant de voir comment rapporter les mesures de qualités dans Jenkins, cela peut être utile de revenir en arrière pour avoir une vue plus large. Les mesures de la qualité du code sont d’une valeur limitée si elles sont isolées, elles doivent faire partie d’une stratégie plus large d’amélioration des processus.
Le premier niveau d’intégration de la qualité du code devrait être l’EDI. Les EDI modernes ont un excellent support de beaucoup d’outils de qualité de code — Checkstyle, PMD et FindBugs ont tous des plugins pour Eclipse, NetBeans et IntelliJ, qui fournissent un retour d’information rapide aux développeurs sur les problèmes de qualité du code. C’est le moyen le plus rapide et le plus efficace pour fournir un retour d’information à des développeurs et pour leur apprendre les normes de codage de l’organisation ou du projet.
Le second niveau est votre serveur de build. En plus de vos tâches régulières de tests unitaires et d’intégration, mettez en place un build de qualité de code dédié, qui démarrera après le build régulier et les tests. Le but de ce processus est de fournir des mesures de qualité de code à l’échelle du projet, de garder un œil sur la façon dont le projet est fait dans son ensemble et de traiter n’importe quels problèmes d’un niveau élevé. L’efficacité des ces rapports peut être augmentée par une revue hebdomadaire de la qualité du code, dans laquelle les problèmes et les tendances sur la qualité du code sont discutés au sein de l’équipe.
Il est important d'exécuter cette tâche séparément parce que les outils d’analyse de couverture de code et d’analyse statique peuvent être très longs à exécuter. Il est également important de garder éloigné des builds n’importe quels tests de couverture du code, puisque le processus de couverture du code produit du code instrumenté qui ne devrait jamais être déployé vers un dépôt pour une utilisation en production.
L’établissement de rapports sur la de qualité de code est, par défaut, un processus relativement passif. Personne ne connaîtra l’état du projet s’il ne cherche pas l’information sur le serveur de build. Même si c’est mieux que rien, vous êtes peut-être exigeant sur la qualité du code, il y a alors un meilleur moyen. Au lieu de simplement établir des rapports sur la qualité du code, mettez en place un build dédié à la qualité du code, qui démarre après le build normal et les tests et configurez le build pour échouer si les mesures de la qualité du code ne sont pas à un niveau acceptable. Vous pouvez faire cela dans Jenkins ou dans votre script de build, bien qu’il soit avantageux de le configurer en dehors de votre script de build car vous pourrez changer les critères de défaillance du build de qualité du code sans changer le code source du projet.
Pour finir, souvenez-vous que les normes de codage sont des lignes directrices et des recommandations, pas des règles absolues. Utilisez la défaillance des builds et les rapports de qualité de code comme des indicateurs d’une zone possible d’amélioration, non pas comme des mesures de valeur absolue.