Utilisation de SonarQube par les développeurs

Prérequis

• Installer Docker Desktop :

Assurez-vous que Docker est installé sur votre système. Vous pouvez télécharger Docker à partir de leur site officiel et suivre les instructions d'installation appropriées pour votre système d'exploitation.

• Télécharger l'Image SonarQube :

- Ouvrez un terminal ou une invite de commande.
- Utilisez la commande suivante pour télécharger l'image SonarQube depuis Docker Hub :

- Dans Docker Desktop, dans la section ‘Containers’ (conteneurs), pour visualiser le conteneur.

- Accès à SonarQube :

• Ouvrez votre navigateur web et accédez à l'adresse suivante :http://localhost:8094/
• Vous devriez voir la page d'accueil de SonarQube où vous pouvez vous connecter ou créer un nouveau compte.

• Configuration Complémentaire (Optionnelle) :
  - Vous pouvez personnaliser davantage votre instance de SonarQube en ajoutant des plugins, en configurant des projets, etc.
• Utilisation de SonarQube :

Dans le tableau ci-dessous :

• Une installation de petite échelle est généralement une installation de l'édition Community / Developer qui prend en charge jusqu'à 1 million de lignes de code.
• Une installation de grande échelle est généralement une installation mononœud de l'édition Enterprise qui prend en charge jusqu'à 50 millions de lignes de code.

Produits SonarQube, Téléchargements

• Étape 1. Téléchargez la version SonarQube (édition Developer).
• Étape 2. Décompressez le fichier ZIP téléchargé.
• Étape 3. Accédez au dossier de configuration ‘conf’, puis éditez le fichier ‘sonar.properties’. Vous devrez changer l'utilisateur et le mot de passe de la base de données ainsi que le chemin vers la base de données. Dans notre cas, SQL Server.

• Étape 4. Après, exécutez le fichier batch (StartSonar.bat) pour démarrer l'application SonarQube.

• Étape 5. Ouvrez votre navigateur web et accédez à l'adresse suivante :http://localhost:9000/

Avant de passer aux étapes de création du projet, commençons par une brève présentation des différentes plateformes prises en charge par SonarQube :

• Azure DevOps :
  • Importez des projets depuis Azure DevOps, anciennement connu sous le nom de Visual Studio Team Services (VSTS).
  • Azure DevOps est une suite complète d'outils de développement collaboratif, comprenant la gestion de projet, le suivi des bogues, les tests et la livraison continue.
• Bitbucket Cloud :
  • Importez des projets depuis Bitbucket Cloud, une plateforme de gestion de code source basée sur le cloud.
  • Bitbucket Cloud offre un contrôle de version Git ou Mercurial pour vos projets.
• Bitbucket Server :
  • Importez des projets depuis Bitbucket Server, une solution de gestion de code source auto-hébergée.
  • Bitbucket Server offre un contrôle de version Git ou Mercurial pour vos projets, mais hébergé sur vos propres serveurs.
• GitHub :
  • Importez des projets depuis GitHub, l'une des plateformes d'hébergement de code les plus populaires.
  • GitHub utilise le contrôle de version Git pour héberger vos projets.
• Créer un projet local :
  • Créez un projet local directement sur SonarQube.
  • Cette option est utile si vous travaillez sur un projet qui n'est pas hébergé sur une plateforme externe de gestion de code source.

Dans notre cas, nous allons utiliser la dernière option : la création d'un nouveau projet qui n'est pas hébergé sur une plateforme externe de gestion de code source.

Après avoir cliqué sur ‘Créer un projet local’, une nouvelle fenêtre s'affiche. Saisissez le nom du projet, la clé du projet, et le nom de la branche à scanner. Dans notre cas, nous allons nous baser sur la branche master après avoir cliqué sur ‘Suivante’ (Next).

Donc, à cette étape, nous devons configurer le projet pour le scanner. Nous avons deux options : ‘Utiliser les paramètres globaux’ qui correspond à la configuration globale, et nous avons ‘Définir des paramètres spécifiques pour ce projet’ qui nous permet de spécifier les versions, le nombre de jours, ainsi que la branche de référence.

Cliquer sur ‘Create Project’.

Dans cette étape, choisissez ‘Localement’, c'est-à-dire que le code à scanner et à analyser doit être disponible en local.

Génération du projet token

Un ‘project token’ sur SonarQube est une clé d'authentification utilisée pour permettre à des outils externes ou à des services d'accéder au projet sur SonarQube pour effectuer des analyses ou des opérations spécifiques.

Lorsque vous créez un projet dans SonarQube, un ‘project token’ est généré. Ce token est ensuite utilisé pour permettre l'accès au projet à partir de l'extérieur, par exemple, pour des outils d'intégration continue, des scripts d'analyse, des services d'intégration, etc.

Le ‘project token’ est souvent utilisé dans les systèmes de build automatisés pour permettre à ces systèmes d'envoyer les résultats des analyses de code à SonarQube. Il est important de garder ce token sécurisé, car il donne accès au projet dans SonarQube.

Dans la deuxième partie, il faut suivre les étapes pour lancer l'analyse de code et lier le projet avec SonarQube. Il suffit de lancer les commandes sur le répertoire du projet pour démarrer l'analyse du code. Dans notre cas, nous allons choisir un projet utilisant .NET Core.

Veuillez noter qu'une fois l'analyse lancée, plusieurs fichiers sont ajoutés au niveau du projet contenant la configuration et les paramètres affectés au projet, comme indiqué dans l'image ci-dessous.

Une fois l'analyse du code terminée, les résultats sont envoyés vers SonarQube et le détail de l'analyse du code est affiché.

Tout d'abord, nous allons expliquer les résultats cités dans le tableau de bord du projet :

L’image affiche un tableau de bord avec diverses métriques liées à la qualité et à la maintenance du code informatique. Il y a des sections intitulées ‘Nouveau code’ et ‘Code global’, chacune avec des sous-catégories telles que ‘Fiabilité’, ‘Sécurité’ et ‘Maintenabilité’. Les métriques incluent le nombre de problèmes ouverts, le pourcentage de duplications, les points chauds de sécurité et un pourcentage de couverture qui est à 0,0 %. Cette image est intéressante car elle offre un aperçu de la santé et de la qualité d’une base de code, ce qui est essentiel pour que les développeurs comprennent les domaines nécessitant des améliorations.

La différence entre les sections ‘Nouveau code’ et ‘Code global’ est la suivante :

• Nouveau Code : Il s’agit du code ajouté ou mis à jour depuis le début de la période du ‘Nouveau Code’. Les métriques dans cette section reflètent uniquement les changements récents.
• Code Global : C’est l’ensemble du code, à la fois ancien et nouveau. Les métriques dans cette section incluent tout le code, qu’il soit nouveau ou non.

En résumé, la section ‘Nouveau code’ se concentre sur les modifications récentes, tandis que la section ‘Code global’ englobe l’ensemble du code.

Avant d'aborder la section expliquant les métriques mentionnées dans le tableau de bord du projet, nous allons parler un peu de la partie ‘projects’ qui existe dans le menu global :

La section ‘Projets’ dans SonarQube est l’endroit où vous pouvez gérer et suivre tous vos projets logiciels. Vous pouvez y ajouter des projets, afficher leurs analyses, vérifier les métriques de qualité du code et surveiller leur progression. C’est essentiellement le tableau de bord central pour la gestion de vos projets dans SonarQube.

Dans notre exemple, nous avons un seul projet nommé ‘demo’. L'analyse du code du projet ‘demo’ a réussi, comme mentionné. Cependant, il y a plusieurs parties du code qui doivent être prises en charge, mais globalement, le projet est accepté du point de vue de la qualité.

1. Fiabilité : Capacité d'un système ou d'un logiciel à fonctionner correctement dans diverses conditions. Problèmes potentiels : erreurs, plantages, comportements inattendus.
2. Sécurité : Protection des données, utilisateurs et systèmes contre les menaces et attaques. Problèmes possibles : vulnérabilités, failles de sécurité, risques pour l'intégrité des données.
3. Maintenabilité : Facilité avec laquelle le code peut être modifié, corrigé ou amélioré. Un code maintenable permet des modifications sans causer de nouveaux problèmes.
4. Couverture : Mesure la portion du code source testée par des tests automatisés. Avoir une couverture de 0,0 % signifie que le code n'est pas testé du tout.
5. Duplications : Parties de code similaires ou identiques répétées à différents endroits. Des duplications excessives peuvent rendre la maintenance du code plus difficile.
6. Points Chauds de Sécurité : Zones spécifiques du code à risque élevé en termes de sécurité, nécessitant une attention particulière pour éviter les vulnérabilités.

Voici une explication pour chaque section :

• 1. Fiabilité :
  • 12 problèmes (H) : Il y a 12 problèmes de fiabilité de niveau élevé.
  • 660 problèmes (M) : Il y a 660 problèmes de fiabilité de niveau moyen.
  • 79 problèmes (L) : Il y a 79 problèmes de fiabilité de faible niveau.
• 2. Sécurité :
  • 3 problèmes (H) : Il y a 3 problèmes de sécurité de niveau élevé.
  • 0 problèmes (M) : Il n’y a aucun problème de sécurité de niveau moyen.
  • 0 problèmes (L) : Il n’y a aucun problème de sécurité de faible niveau.
• 3. Maintenabilité :
  • 3300 problèmes (H) : Il y a 3300 problèmes de maintenabilité de niveau élevé.
  • 1300 problèmes (M) : Il y a 1300 problèmes de maintenabilité de niveau moyen.
  • 543 problèmes (L) : Il y a 543 problèmes de maintenabilité de faible niveau.
• 4. Couverture :
  • 0,0 % (sur 34 000 lignes à couvrir) : La couverture du code est actuellement de 0,0 %, ce qui signifie que les tests ne couvrent aucune des 34 000 lignes de code.
• 5. Duplications :
  • 30,7 % (sur 184 000 lignes) : Le pourcentage de duplications dans le code est de 30,7 %, ce qui indique que certaines parties du code sont similaires ou répétées.
• 6. Points Chauds de Sécurité :
  • 83 : Il y a 83 points chauds de sécurité identifiés dans le code. Les points chauds sont des zones potentiellement vulnérables qui nécessitent une attention particulière.

Premièrement, naviguez vers la section où vous souhaitez afficher les problématiques, comme indiqué dans l'image ci-dessous :

Dans notre exemple, nous avons 3 problématiques côté sécurité. Après l'affichage de la liste des problématiques, elles sont triées par fichier. Dans notre cas, le fichier ‘appsettings.Development.json’ (surligné en vert) contient 3 problématiques. Pour voir les détails de chaque problème, il suffit de cliquer sur le titre du problème, comme indiqué dans l'image.

Tout d'abord, examinons les détails du problème. Dans notre exemple avec SonarQube, il détecte qu'il y a un mot de passe de base de données affiché en clair dans ce fichier. SonarQube propose de supprimer le code, mais vous devez vous assurer que le mot de passe de la base de données a été modifié dans un autre endroit, par exemple dans le déploiement.

Finalement, après avoir corrigé le problème dans le code source du projet, vous devez informer SonarQube que le problème est résolu. Parfois, SonarQube peut signaler des résultats erronés, c'est pourquoi il propose un bouton ‘Ouvrir’. Vous pouvez confirmer que le problème est résolu. Si SonarQube donne un résultat erroné, vous pouvez sélectionner ‘False Positive’ et ajouter un commentaire pour expliquer que c'est un problème. Pour les prochaines analyses, SonarQube ne prendra pas en compte les ‘false positives’.