Nous avons vu dans le post précédent comment installer le plugin Sonar pour Jenkins. Il est temps maintenant d’effectuer notre première analyse depuis Jenkins. Celle-ci portera sur le code source Cobol déjà utilisé lors de notre première analyse avec Sonar et le Java Runner.

Pour cela, nous allons créer un projet, depuis la page principale de Jenkins.

Dans la page de création, nous entrons un nom de projet et sélectionnons la première option:

Ceci nous ouvre la page de configuration de ce projet, dans laquelle il nous suffit d’indiquer que nous souhaitons effectuer une analyse Sonar:

Il nous reste simplement à indiquer notre fichier de configuration pour cette analyse, le même que déjà utilisé pour notre première analyse avec Sonar, c’est-à-dire : C:\Soft\Sonar\sonar-runner-1.1\Projects\sonar-project.properties :

Mais auparavant, nous allons spécifier dans ce fichier une nouvelle version pour notre analyse: sonar.projectVersion=1.1.

N’oubliez pas de sauvegarder les paramètres de votre projet.

Avant de lancer celui-ci.

Pendant que le projet s’exécute…

 

Nous pouvons regarder le log d’analyse:

Puis dans Sonar, le résultat de cette analyse, avec la version indiquée dans notre fichier de configuration:

Nous avons vu comment contourner deux inconvénients du Java Runner (que nous utilisons par manque de pratique de la syntaxe Maven) :

1. Un fichier unique de configuration d’analyse : Jenkins nous permet de spécifier un fichier distinct pour chaque analyse Sonar.
2. Un log beaucoup plus pratique et convivial chaque fois que nous lancerons une de nos analyses Sonar.

Ceci nous permet une grande souplesse d’utilisation, notamment dans l’organisation de notre environnement d’analyse. Nous allons voir deux exemples.

Je vais commencer par renommer le fichier sonar-project.properties en Myproject.properties, dans le répertoire ..\sonar-runner-1.1\Projects. Je modifie également la version d’analyse (sonar.projectVersion=1.2) dans ce fichier, simplement afin de vérifier que celui-ci est bien pris en compte.

Je vais ensuite indiquer ce nouveau fichier dans la configuration de mon projet Jenkins avant de lancer celui-ci à nouveau…Et de vérifier le résultat dans Sonar : une nouvelle version 1.2 apparaît effectivement. Ceci signifie que je peux utiliser un espace ‘Projet’ avec autant de fichiers de configurations que j’ai d’applications à analyser.

 

Un autre type d’organisation consiste à dédier un disque dur à mon environnement d’analyse, avec un dossier par application, au sein duquel je placerai à la fois le code source applicatif, mais également tout fichier de configuration d’analyse. Dans ce second exemple, je vais :

• Créer un répertoire G:\Mainframe\MyAppCobol pour mon application.
• Dans ce dossier, créer un sous-répertoire \Source dans lequel je vais copier les programmes Cobol à analyser.
• Dans ce dossier, créer un sous-répertoire \Implementation\Conf dans lequel je placerai mon fichier de configuration Sonar MyAppCobol.properties
• Dans ce fichier, modifier l’attribut sources=G:/Mainframe/MyAppCobol/Source afin d’indiquer le nouvel emplacement des fichiers Cobol.

Voici à quoi ressemble mon nouvel environnement.

Il ne nous reste plus qu’à modifier à nouveau la configuration de notre projet Jenkins afin de prendre en compte le nouvel emplacement du fichier de configuration Sonar, et d’exécuter une nouvelle analyse.

Je peux donc organiser mes analyses comme je le souhaite, soit en centralisant tous les fichiers de configuration au sein d’un même dossier \Projets (par exemple), soit en décentralisant chacun au niveau d’un dossier par application.

Je peux gérer autant d’analyses que je le souhaite, de quelque technologie que ce soit avec les plugins Sonar, et bénéficier de la console de Jenkins pour gérer les logs d’analyse.

Enfin, la solution mise en place repose sur le Java Runner de Sonar sans nécessiter de connaissances particulières d’autres outils tels que Maven ou Ant.