Sonar est un outil qui centralise toute une gamme de mesures de qualité de code en un seul site web (voir Figure 9.18, “Rapport de qualité de code par Sonar.”). Il utilise un certain nombre de plugins Maven (Checkstyle, PMD, FindBugs, Cobertura ou Clover, et d’autres) pour analyser des projets Maven et générer un ensemble complet de rapports sur la qualité du code. Les rapports Sonar sur la couverture du code, le respect des règles, et la documentation, mais aussi sur des mesures de plus haut niveau comme la complexité, la maintenabilité et même la dette technique. Vous pouvez utiliser des plugins pour étendre ses fonctionnalités et ajouter le support pour d’autres langages (comme le support de CodeNarc pour du code source Groovy). Les règles utilisées par divers outils sont gérées et configurées de manière centralisée sur le site web de Sonar, et les projets Maven en cours d’analyse ne nécessitent aucune configuration particulière. Cela fait de Sonar l'outil parfait pour travailler sur des projets Maven où vous avez un contrôle limité sur les fichiers POM.
Dans l’une des utilisations les plus courantes de Sonar, Sonar exécute automatiquement un ensemble de plugins Maven liés à la qualité de code sur votre projet Maven, et stocke les résultats dans une base de données relationnelle. Le serveur Sonar, que vous exécutez séparément, analyse alors les résultats et les affiche comme indiqué dans Figure 9.18, “Rapport de qualité de code par Sonar.”.
Jenkins s’intègre bien avec Sonar. Le plugin Sonar de Jenkins vous laisse définir les instances Sonar pour tous vos projets, et active ensuite Sonar pour des builds particuliers. Vous pouvez exécuter votre serveur Sonar sur une machine différente de votre instance Jenkins, ou sur la même. La seule contrainte est que l’instance Jenkins doit avoir un accès JDBC à la base de données de Sonar, puisqu’il injecte des mesures de qualité de code directement dans la base de données, sans passer par le site web de Sonar (voir Figure 9.19, “Jenkins et Sonar”).
Sonar a aussi une amorce Ant (avec une amorce Gradle en cours de développement au moment de la rédaction de ce livre) pour les utilisateurs non-Maven.
Vous installez le plugin comme d’habitude, via le gestionnaire de plugin. Une fois installé, vous configurez le plugin Sonar de Jenkins dans l’écran Configurer le système, dans la section Sonar. Il s’agit de définir vos instances Sonar – vous pouvez configurer autant d’instances que vous avez besoin. La configuration par défaut suppose que vous exécutez une instance locale de Sonar avec la base de données embarquée par défaut. Ceci est utile à des fins de test, mais n’est pas très évolutif. Pour un environnement de production, vous exécuterez alors Sonar sur une vraie base de données comme MySQL ou Postgres, et vous aurez besoin de configurer la connexion JDBC sur la base de données de production de Sonar dans Jenkins. Vous pouvez faire ceci en cliquant le bouton Avancé et en remplissant les champs appropriés (voir Figure 9.20, “Configurer Sonar dans Jenkins”).
L’autre chose que vous devez configurer est le moment où le build de Sonar débutera dans une tâche de build où Sonar est activé. Vous configurez généralement Sonar pour qu'il s'exécute avec l’une des longues tâches de build Jenkins, comme le build de mesure de qualité de code. Ce n’est pas très utile d'exécuter le build Sonar plus d’une fois par jour, puisque Sonar stocke les mesures sur des tranches de 24 heures. La configuration par défaut exécutera le build de Sonar, dans une tâche de build où Sonar est activé, chaque fois qu’une tâche est déclenchée par un build périodiquement planifié ou par un build manuel.
Pour activer Sonar dans votre tâche de build, avec des options de configuration à l’échelle du système, il suffit de cocher l’option Sonar dans Actions à la suite du build (voir Figure 9.21, “Configurer Sonar dans une tâche de build”). Sonar s'exécutera à chaque fois que votre build est lancé par l’un des mécanismes de déclenchements définis ci-dessus.
Vous configurez généralement Sonar pour qu'il s'exécute sur une base régulière, par exemple tous les soirs ou une fois par semaine. Vous pouvez donc activer Sonar sur votre tâche de build de test unitaire/d’intégration normal, simplement en ajoutant un ordonnanceur (voir Figure 9.22, “Planifier les builds Sonar”). Cela évite les détails de configuration en double entre les tâches. Ou, si vous avez déjà une tâche de build ordonnancée qui démarre avec une fréquence appropriée (comme un build dédié aux mesures de qualité de code), vous pouvez activer Sonar sur cette tâche de build.
Si vous cliquez sur le bouton Avancé, vous pouvez spécifier d’autres options plus sophistiquées, comme lancer votre build Sonar sur une branche séparée, passer des options de ligne de commande Maven supplémentaires (comme de la mémoire supplémentaire), ou redéfinir la configuration par défaut des déclencheurs.
Par défaut, Sonar s'exécutera même si le build normal échoue. C’est généralement ce que l’on souhaite, puisque Sonar devrait enregistrer les builds et les tests défaillants aussi bien que les résultats réussis. Cependant, si c’est nécessaire, vous pouvez aussi désactiver cette option dans les options avancées.