1. Vue d’ensemble
Dans cet article, nous allons examiner l’analyse statique du code source avec SonarQube , une plate-forme open source permettant d’assurer la qualité du code.
Commençons par une question fondamentale: pourquoi analyser le code source en premier lieu? En termes simples, pour assurer la qualité, la fiabilité et la facilité de maintenance tout au long du projet; une base de code mal écrite coûte toujours plus cher à maintenir.
Très bien, commençons maintenant par télécharger la dernière version LTS de SonarQube à partir de la page download et configurer notre serveur local comme indiqué dans la section https://docs.sonarqube . org/display/SONAR/Démarrer en deux minutes[guide de démarrage rapide].
2. Analyse du code source
.
Nous utiliserons le jeton plus tard au moment de l’analyse de nos projets. Nous devons également sélectionner le langage principal (Java) et la technologie de construction du projet (Maven).
Définissons le plugin dans le pom.xml :
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.sonarsource.scanner.maven</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>3.4.0.905</version>
</plugin>
</plugins>
</pluginManagement>
</build>La dernière version du plug-in est disponible à l’adresse https://search.maven.org/classic/#search%7Cgav%7C1%7Cg%3A%22org.sonarsource.scanner.maven%22%20AND%20a%3A%22sonar-maven . -plugin% 22[ici].
Maintenant, nous devons exécuter cette commande à la racine du répertoire de notre projet pour l’analyser:
mvn sonar:sonar -Dsonar.host.url=http://localhost:9000
-Dsonar.login=the-generated-tokenNous devons remplacer le jeton généré par le jeton d’en haut.
-
Le projet que nous avons utilisé dans cet article est disponible à l’adresse here .** .
Nous avons spécifié l’URL de l’hôte du serveur SonarQube et la connexion (jeton généré) en tant que paramètres du plug-in Maven.
Une fois la commande exécutée, les résultats seront disponibles dans le tableau de bord Projets - à l’adresse http://localhost : 9000 .
Il y a d’autres paramètres que nous pouvons transmettre au plugin Maven ou même définir à partir de l’interface Web; _sonar.host . url, sonar.projectKey et sonar.sources_ sont obligatoires, tandis que d’autres sont facultatifs.
D’autres paramètres d’analyse et leurs valeurs par défaut sont https://docs.sonarqube.org/display/SONAR/Analysis Parameters[ici].
Notez également que chaque plug-in de langue a des règles pour analyser le code source compatible.
3. Résultats d’analyse
Maintenant que nous avons analysé notre premier projet, nous pouvons accéder à l’interface Web à l’adresse http://localhost : 9000 et actualiser la page.
Nous y verrons le résumé du rapport:
Les problèmes découverts peuvent être un bogue, une vulnérabilité, une odeur de code, une couverture ou une duplication. Chaque catégorie a un nombre correspondant de numéros ou une valeur en pourcentage.
De plus, les problèmes peuvent avoir l’un des cinq niveaux de gravité suivants:
blocker, critical, major, minor et info. Juste devant le nom du projet, une icône indique l’état de Quality Gate: passé (vert) ou échoué (rouge).
En cliquant sur le nom du projet, vous accédez à un tableau de bord dédié dans lequel vous pouvez explorer plus en détail les problèmes propres au projet.
Vous pouvez voir le code du projet, l’activité et effectuer des tâches d’administration à partir du tableau de bord du projet - chacun disponible dans un onglet séparé.
Bien qu’il existe un onglet global Issues , l’onglet Issues du tableau de bord du projet présente les problèmes spécifiques au projet concerné:
lien:/uploads/383732889__issues-1024x479.jpg%201024w[]
L’onglet Problèmes affiche toujours la catégorie, le niveau de gravité, la ou les balises et l’effort calculé (en temps) qu’il faudra pour résoudre un problème.
Dans l’onglet Problèmes, il est possible d’attribuer un problème à un autre utilisateur, de le commenter et de modifier son niveau de gravité. En cliquant sur le problème lui-même, vous obtiendrez plus de détails sur le problème.
L’onglet Issue contient des filtres sophistiqués à gauche. Celles-ci sont bonnes pour cerner les problèmes. Alors, comment savoir si la base de code est suffisamment saine pour être déployée en production? C’est à cela que sert Quality Gate.
4. Portail Qualité SonarQube
Dans cette section, nous allons examiner une fonctionnalité clé de SonarQube - Quality Gate. Nous verrons ensuite un exemple de configuration d’un modèle personnalisé.
4.1. Qu’est-ce qu’une porte de qualité?
Un Quality Gate est un ensemble de conditions que le projet doit respecter avant de pouvoir prétendre à une version de production. Il répond à une question: puis-je pousser mon code à la production dans son état actuel ou non?
Garantir la qualité du code du «nouveau» code tout en corrigeant les codes existants est un bon moyen de conserver une bonne base de code au fil du temps. .
Les conditions définies dans Quality Gate affectent toujours les segments de code non modifiés. Si nous pouvons éviter que de nouveaux problèmes se posent, nous allons tous régler tous les problèmes.
Cette approche est comparable à https://docs.sonarqube.org/display/SONAR/Fixer la fuite d’eau[en corrigeant les fuites d’eau]depuis la source. Cela nous amène à un terme particulier - Période de fuite. C’est la période entre deux analyses/versions du projet .
Si nous réexécutons l’analyse sur le même projet, l’onglet de vue d’ensemble du tableau de bord du projet affiche les résultats pour la période de fuite:
lien:/uploads/36326789289 leak period-1024x470.jpg%201024w[]
Depuis l’interface Web, l’onglet Portes de qualité permet d’accéder à toutes les portes de qualité définies. Par défaut, SonarQube way est préinstallé avec le serveur.
La configuration par défaut de SonarQube way marque le code comme ayant échoué si:
-
la couverture sur le nouveau code est inférieure à 80%
-
le pourcentage de lignes dupliquées sur le nouveau code est supérieur à 3
-
la maintenabilité, la fiabilité ou la cote de sécurité est pire que A
Avec cette compréhension, nous pouvons créer une porte de qualité personnalisée.
4.2. Ajout de la porte de qualité personnalisée
Tout d’abord, nous devons cliquer sur l’onglet Quality Gates puis sur le bouton Create situé à gauche de la page. Nous devrons lui donner un nom: baeldung .
Maintenant, nous pouvons définir les conditions que nous voulons:
-
Dans le menu déroulant Ajouter une condition, choisissez Problèmes de blocage ** ; il apparaîtra immédiatement dans la liste des conditions.
Nous spécifierons is supérieur à than en tant que Operator, définissez zéro (0) pour la colonne Error et vérifiez la colonne Over Leak Period :
-
Ensuite, nous cliquerons sur le bouton Add pour effectuer les modifications ** . Ajoutons une autre condition en suivant la même procédure que ci-dessus.
Nous sélectionnerons issues dans la liste déroulante Ajouter une condition _ et nous vérifierons la colonne Sur période de fuite_ .
La valeur de la colonne O _perator sera définie sur « is inferieur à» et nous ajouterons un (1) comme valeur pour la colonne Error . Cela signifie que si le nombre de problèmes dans le nouveau code ajouté est inférieur à 1, marquez Quality Gate comme en échec_ .
Je sais que cela n’a pas de sens technique, mais utilisons-le pour apprendre. N’oubliez pas de cliquer sur le bouton Ajouter pour enregistrer la règle.
-
Une dernière étape consiste à associer un projet à notre Quality Gate personnalisé.
Nous pouvons le faire en faisant défiler la page jusqu’à la section Projets. **
Là, nous devons cliquer sur Tous, puis marquer notre projet de choix. Nous pouvons également le définir comme porte de qualité par défaut dans le coin supérieur droit de la page.
Nous allons scanner le code source du projet, encore une fois, comme nous l’avions déjà fait avec la commande Maven. Lorsque cela sera terminé, nous irons dans l’onglet Projets et nous actualiserons.
Cette fois, le projet ne répondra pas aux critères de Quality Gate et échouera. Pourquoi? Parce que l’une de nos règles a spécifié cela, cela devrait échouer s’il n’y a pas de nouveaux problèmes.
Revenons à l’onglet Quality Gates et modifions la condition pour issues en is supérieure à . Nous devons cliquer sur le bouton de mise à jour pour effectuer ce changement.
Une nouvelle analyse du code source passera cette fois-ci.
5. Intégration de SonarQube dans un CI
Intégrer SonarQube dans un processus d’intégration continue est possible.
La construction échouera automatiquement si l’analyse du code n’a pas satisfait à la condition Quality Gate.
Pour ce faire, nous allons utiliser SonarCloud , version du serveur SonaQube hébergée dans le cloud. Nous pouvons créer un compte here .
Dans Mon compte> Organisations, nous pouvons voir la clé d’organisation, généralement sous la forme xxxx-github ou xxxx-bitbucket .
Également à partir de Mon Account> Security , nous pouvons générer un jeton comme nous l’avons fait dans l’instance locale du serveur. Prenez note du jeton et de la clé d’organisation pour une utilisation ultérieure.
Dans cet article, nous utiliserons Travis CI et créerons un compte here avec un profil Github existant. Cela chargera tous nos projets et nous pourrons activer le commutateur pour activer Travis CI.
Nous devons ajouter le jeton que nous avons généré sur les variables d’environnement SonarCloud to Travis. Nous pouvons le faire en cliquant sur le projet que nous avons activé pour CI.
Ensuite, nous cliquerons sur «Plus d’options»> «Paramètres», puis sur «Variables d’environnement»:
Nous allons ajouter une nouvelle entrée avec le nom SONAR TOKEN__ et utiliser le jeton généré, sur SonarCloud, comme valeur. Travis CI va le chiffrer et le cacher de la vue publique:
Enfin, nous devons ajouter un fichier .travis.yml à la racine de notre projet avec le contenu suivant:
language: java
sudo: false
install: true
addons:
sonarcloud:
organization: "your__organization__key"
token:
secure: "$SONAR__TOKEN"
jdk:
- oraclejdk8
script:
- mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent package sonar:sonar
cache:
directories:
- '$HOME/.m2/repository'
- '$HOME/.sonar/cache'N’oubliez pas de remplacer votre clé d’organisation par la clé d’organisation décrite ci-dessus. La validation du nouveau code et l’appui sur le dépôt Github déclenchent la construction de Travis CI et activent à leur tour l’analyse du sonar.
6. Conclusion
Dans ce didacticiel, nous avons expliqué comment configurer un serveur SonarQube localement et comment utiliser Quality Gate pour définir les critères de conformité d’un projet à la version de production.
SonarQube documentation contient plus d’informations sur les autres aspects de la plate-forme.