Attention, cet article est ancien ! Certaines parties sont peut-être inadaptées à votre stack actuelle. Pour découvrir nos nouveaux article sur le test et la qualité logicielle, nous vous conseillons de consulter la page d’accueil de notre blog. Amusez-vous bien !
La galaxie SonarQube
Dans de précédents articles, nous avons présenté SonarQube, son interface ainsi que son intégration avec Jenkins, et SonarLint, son acolyte qui permet aux développeurs de vérifier la qualité de leur code avant de le commiter. Aujourd’hui, nous voulons affiner encore les choses, et différencier l’analyse des branches features et master.
Cet article présente un applicatif open-source, disponible en l’état et sans garantie. Il est de la responsabilité du SI de vérifier qu’il est conforme à sa politique de sécurité d’une part, et de respecter sa licence d’autre part. Merci à Gabriel Allaigre, de Talanlabs, pour le plugin Sonar-Gitlab !
La procédure suivante met en oeuvre SonarQube, Gitlab et Jenkins en environnement Linux.
Problème initial : trop ou trop peu de données qualimétriques ?
Entre surcharge informationnelle…
Dans un projet donné, il arrive que chaque branche (de feature ou même de bug) fasse l’objet d’une analyse SonarQube à chaque fois que du nouveau code est poussé dessus. Les résultats de cette analyse sont alors stockés dans la base de données et affichés dans l’interface.
Le problème, c’est qu’il en résulte rapidement une liste interminable de « projets » SonarQube qui n’en sont pas ; ce ne sont que des branches ! Ces résultats sont conservés indéfiniment alors qu’ils perdent leur intérêt dès que les branches sont fusionnées.
Comment éviter ce bruit tout en conservant le feedback de SonarQube ?
… et isolement des informations
Par ailleurs, il est assez courant d’entendre des témoignages de ce type : « Nous avons installé SonarQube et des analyses sont régulièrement lancées sur nos projets, mais en pratique on ne les regarde pas souvent. » Effectivement : SonarQube est simple à installer, simple à configurer et simple à utiliser. Le plus difficile est de l’intégrer pleinement aux modes de travail des équipes.
Le plugin présenté ici vise à résoudre le premier problème, tout en apportant un élément de solution au second.
Comprendre les lancements d’analyse SonarQube
Il faut d’abord savoir que SonarQube dispose de 3 modes de lancement :
- Analysis : il s’agit du mode de lancement par défaut de SonarQube. Tous les fichiers sont analysés et SonarQube crée ou met à jour un projet dans sa base de données.
- Preview : tous les fichiers sont également analysés mais les résultats ne sont pas stockée dans la base de données.
- Incremental : seul le fichier courant ou les derniers fichiers modifiés sont analysés. Il s’agit du mode de lancement par défaut de SonarLint.
Source : https://blog.sonarsource.com/analysis-vs-preview-vs-incremental-preview-in-sonarqube/
Ce sont sur ces modes de lancement que nous allons nous appuyer pour différencier les analyses des branches features et master :
- Pour la branche master, nous allons continuer d’utiliser le mode analysis, et stocker les résultats dans la base de données.
- Pour les branches temporaires, nous allons basculer sur le mode preview, ce qui va nous permettre de générer le rapport et de le visionner… sur Gitlab !
L’idée est de permettre à un utilisateur Gitlab dédié (que l’on nommera tout simplement SonarQube) de commenter les commits en indiquant les mauvaises pratiques détectées dans les portions de nouveau code.
Mise en pratique
Récupération du plugin
La dernière version stable du plugin Sonar-Gitlab est disponible depuis le centre de mise à jour de SonarQube, vous pouvez l’y installer directement.
Si vous souhaitez utiliser la toute dernière version du plugin, vous devrez récupérer le projet Sonar Gitlab Plugin sur la page Github du projet, placer le jar dans le répertoire « plugins » de Sonarqube (SONARQUBE_HOME/extensions/plugins) puis redémarrer SonarQube.
Configuration de Gitlab
- Créer un compte Gitlab avec comme nom SonarQube
- Se connecter sur Gitlab en tant qu’administrateur et attribuer à l’utilisateur SonarQube le profil « Développeur » dans les groupes contenant les projets à analyser
- Se connecter sur Gitlab avec l’utilisateur SonarQube et générer un token sur la page http://urldegitlab/profile/personal_access_tokens
Configuration de SonarQube
- Se connecter sur SonarQube en tant qu’administrateur
- Dans « Configuration », se rendre dans le tout nouvel onglet « Gitlab »
- Dans le formulaire qui s’ouvre, renseigner le token
- Remplir les champs « Global template » et « Inline template » en adaptant les templates proposés ici : https://gitlab.talanlabs.com/gabriel-allaigre/sonar-gitlab-plugin#examples
Configuration du projet à analyser
- Sur Gitlab, récupérer l’id du projet souhaité, qui se trouve dans les Settings du projet.
- Sur SonarQube, revenir à l’écran des projets, cliquer sur le projet concerné, puis sur « Configuration » > « Paramètres projet » > « Gitlab »
- Dans le formulaire qui s’affiche, renseigner l’id du projet récupéré dans Gitlab et, éventuellement, adapter les barrières qualité du projet
- Pour être analysé par SonarQube, un projet doit contenir un fichier sonar-project.properties. Ajouter les deux lignes suivantes à ce fichier :
sonar.analysis.mode=${MODE_ANALYSE} ${GITLAB_CONFIG}A noter : les variables ${MODE_ANALYSE} et ${GITLAB_CONFIG} seront remplacées au moment du build Jenkins.
Configuration du job Jenkins
- Sur Jenkins, créer un build et ajuster les actions déclenchant le build ; ici, à chaque fois qu’un changement a lieu sur Gitlab
- Lors de l’étape de récupération des sources, prendre soin de ne cibler aucune branche en particulier.
- Ajouter une étape « Exécuter un script shell » avec le script suivant :
ID_PROJET="124" # id du projet, à récupérer dans Gitlab URL_SONARQUBE="http://urldesonarqube" SHA_DERNIER_COMMIT=$GIT_COMMIT if ["$GIT_BRANCH" = "origin/master" ]; then echo "Nous sommes sur la branche master. Les résultats de cette analyse seront enregistrés dans la base de données de SonarQube." sed -i "s/${MODE_ANALYSE}/publish/g" sonar-project.properties # on suppose que ce fichier est à la racine du projet. Adapter le chemin si besoin. sed -i "s/${GITLAB_CONFIG}//g" sonar-project.properties else echo "Nous sommes sur une autre branche que master. Les résultats de cette analyse seront enregistrés dans les commentaires de l'utilisateur SonarQube dans Gitlab." sed -i "s/${MODE_ANALYSE}/preview/g" sonar-project.properties # Configuration Gitlab sed -i "s/${GITLAB_CONFIG}/sonar.gitlab.commit_sha=${CI_BUILD_REF}nsonar.gitlab.ref_name=${CI_BUILD_REF_NAME}nsonar.gitlab.project_id=${ID_PROJET}nsonar.host.url=${URL_SONARQUBE}nsonar.issuesReport.console.enable=true/g" sonar-project.properties sed -i "s/${CI_BUILD_REF}/$SHA_DERNIER_COMMIT/g" sonar-project.properties sed -i "s/${CI_BUILD_REF_NAME}/$SHA_DERNIER_COMMIT/g" sonar-project.properties fi - Ajouter l’étape de lancement de l’analyse SonarQube.
Intégrer l’analyse de code à tous les niveaux
Récapitulons. Désormais, à chaque changement dans le dépôt Gitlab, un build Jenkins sera lancé. Si c’est la branche master qui est concernée, un rapport sera enregistré dans la base de données de SonarQube ; sinon, des commentaires seront postés sur le commit pour indiquer d’éventuelles mauvaises pratiques dans le nouveau code introduit.
Bonnes analyses !