Mesurer la qualité et la couverture du code
Contents
Cet article a pour objectif d’expliciter les notions de qualité et couverture de code et de montrer comment tout un chacun peut mettre en œuvre des métriques inclues dans gitlab sur son projet à Systerel.
Qu’est-ce que c’est ?¶
Qualité de code¶
La définition d’un code de qualité est contextuelle. Cependant, en termes généraux, un code de bonne qualité est :
Adapté à l’objectif (il fait ce qu’il est censé faire du point de vue du propriétaire)
Cohérent en interne (le style ne change pas d’un bout à l’autre)
Facile à comprendre (toute personne connaissant le langage de programmation
utilisé doit être capable de lire le code et de comprendre rapidement son fonctionnement afin d’y apporter des améliorations). - Documenté de manière appropriée - Testable
Le code existe dans un but précis. Qu’il ait été écrit comme un exercice d’apprentissage ou qu’il soit un élément essentiel d’une application utilisée par des millions de personnes dans le monde, un code de bonne qualité aide les produits numériques et leurs fonctionnalités à faire leur travail de manière plus efficace et plus fiable.
En bref, une meilleure qualité de code signifie une meilleure qualité de logiciel.
Un code de bonne qualité peut également contribuer à protéger les utilisateurs, un logiciel bien écrit est plus sûr et plus sécurisé. C’est essentiel à une époque où les organismes de réglementation exigent de plus en plus des entreprises qu’elles prennent au sérieux la protection des données.
Couverture de code¶
En génie logiciel, la couverture de code est une mesure utilisée pour décrire le taux de code source exécuté d’un programme quand une suite de test est lancée. Ces informations permettent de vérifier quelle brique de code est parcouru, et donc testé.
Deux informations sont généralement retournés : - Le taux de couverture (en %) - Un rapport donnant la couverture effective par fichier
Comment ça marche ?¶
Le Gitlab Systerel intégère déjà ce genre de mesure. Pour les utiliser, il est nécessaire d’avoir des connaissances en intégration continue gitlab. Les informations adéquates peuvent se trouver sur le blog ici <https://kvm-2.aix.systerel.fr/blog/internal/posts/2022-01/integration-continue-a-systerel/>.
Les mesures qui nous intéressent correspondent à certains stage de de l’intégration continue.
Exemple¶
Projet interne — Composant SNMP Nomad Digital¶
Les mesures ont été mises en place sur le projet C943 à la demande du client Nomad Digital. La demande initiale était de donner à Nomad des KPIs de mesures de code utilisés par Systerel. A ce jour, il n’y a pas de KPI “générique” sur le sujet à Systerel. Une rapide étude a été faite pour utiliser ce qui était déjà inclus dans Gitlab et le mettre en exécution.
En version gratuite, les informations sont accessibles dans les merges request. Gitlab utilise : - CodeClimate <https://docs.codeclimate.com/docs> pour la mesure de qualité de code

Affichage du rapport de qualité dans une MR du projet C943, composant SNMP
Des rapports au format Corbertura <https://cobertura.github.io/cobertura/> pour la couverture de code

Affichage du taux de couverture dans une MR du projet C943, composant SNMP

Affichage de la couverture par ligne dans le diff d’une MR du projet C943, composant SNMP
Mise en place¶
Il existe différents systèmes pour définir les tâches et leur enchaînement, ainsi que l’environnement dans lesquelles elles seront exécutées. De manière générale, un fichier de configuration géré en configuration dans l’espace projet (sous git) est utilisé pour décrire tout cela de manière statique.
La documentation est en général disponible en ligne :
À Systerel, nous utilisons deux systèmes d’intégration continue. L’ancien Jenkins qui n’a plus vocation à être utilisé sur de nouveaux projets et l’instance locale de gitlab.
Dans la suite nous allons vous montrer comment mettre en place une intégration continue sur votre projet.
Création du projet gitlab¶
Si vous êtes chef de projet ou responsable de département, vous pouvez créer
un projet sous le groupe cNNN
correspondant au numéro de contrat en
vous rendant sur https://gitlab.aix.systerel.fr/cNNN et en cliquant sur
le bouton :
Si vous voulez juste essayer sans polluer un espace projet, vous pouvez
toujours créer un projet personnel en utilisant le même bouton sur la
page d’accueil. Sachez seulement
qu’à la différence des projets créés dans les groupes cNNN
, ceux-ci
ne sont pas sauvegardés par le SI.
Notez que pour pouvoir faire un push
vers gitlab, il vous faudra
ajouter votre clef publique ssh dans votre compte :
https://gitlab.aix.systerel.fr/profile/keys
Création du .gitlab-ci.yml
¶
Tout d’abord, clonez votre dépôt en local (en supposant que ce dernier
ait pour nom test_ci
et en remplaçant USERNAME
par votre login
gitlab) :
git clone "ssh://git@gitlab.aix.systerel.fr:2224/USERNAME/test_ci"
Et ajoutez en configuration le fichier .gitlab-ci.yml
ci-après qui décrit
un pipeline d’intégration continue (c’est-à-dire l’ensemble des actions qui
devront être lancées) permettant de simuler une compilation (stage: build
,
deux tâches de test (stage: test
) et une tâche de déploiement (stage:
deploy
).
Sans information de dépendances supplémentaires entre tâches, les phases (stage
) sont séquencées dans l’ordre et le pipeline s’arrête dès qu’une
des phases n’a pas toutes ses tâches (job) qui ont réussi.
build-job: stage: build script: - echo "Hello, $GITLAB_USER_LOGIN!" test-job1: stage: test script: - echo "This job tests something" test-job2: stage: test script: - echo "This job tests something, but takes more time than test-job1." - echo "After the echo commands complete, it runs the sleep command for 20 seconds" - echo "which simulates a test that runs 20 seconds longer than test-job1" - sleep 20 deploy-prod: stage: deploy script: - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
avec les commandes :
git add .gitlab-ci.yml git commit -m "Add initial CI configuration"
Enfin, poussez le tout vers le gitlab pour déclencher les travaux d’intégration continue.
git push -u origin master # pousse sur gitlab et associe la branche locale master à la branche distante de même nom
Vous pouvez alors constater sur https://gitlab.aix.systerel.fr/USERNAME/test_ci/-/pipelines que les différentes tâches d’intégration continue se sont bien exécutées :

Affichage du pipeline
Réutilisation des résultats¶
Il est souvent nécessaire de réutiliser les résultats d’une tâche précédente. Par exemple pour dérouler les tests, on utilise l’exécutable produit pendant la phase de compilation. Gitlab utilise pour cela la notion d’artefacts.
Modifiez votre fichier .gitlab-cy.yml
comme suit pour ajouter un
artefact en phase de build
et l’utiliser dans les tests :
@@ -1,12 +1,17 @@ build-job: stage: build script: - - echo "Hello, $GITLAB_USER_LOGIN!" + - echo "Hello, $GITLAB_USER_LOGIN!" | tee "result.txt" + artifacts: + paths: + - result.txt + expire_in: 1 day test-job1: stage: test script: - echo "This job tests something" + - grep "Hello" result.txt test-job2: stage: test @@ -15,6 +20,7 @@ test-job2: - echo "After the echo commands complete, it runs the sleep command for 20 seconds" - echo "which simulates a test that runs 20 seconds longer than test-job1" - sleep 20 + - grep "Jonathan Livingston" result.txt deploy-prod: stage: deploy
La CI s’exécute et donne le résultat attendu suivant :

Affichage du pipeline modifié
On peut voir que le grep
de test-job1
a réussi, mais que celui de
test-job2
a échoué comme attendu et que la dernière tâche n’a pas
été exécutée, car elle dépend de la bonne exécution de l’étape (stage
) précédente.
Le fichier result.txt
est consultable sur l’interface du gitlab dans
la liste des artefacts associés à la tâche build-job
.
Bonnes pratiques¶
Avoir une CI rapide¶
L’idée d’une intégration continue est de permettre au développeur d’avoir un retour rapide sur ses modifications. Il est donc important :
de commiter et pousser souvent sa branche de développement,
de minimiser le temps d’exécution de la CI.
Dans le cas contraire, cela oblige le développeur à changer de contexte pour prendre en compte le résultat de la CI, ce qui est parfois compliqué.
On peut être amené à découper les tâches de la CI en différents groupes. Un premier qui est exécuté à chaque push et un second (par exemple pour des tests de performance qui peuvent être long à exécuter) qui seront exécutés toutes les nuits.
Travailler sur des branches¶
L’idéal est d’avoir en permanence un master pour lequel l’intégration continue est au vert. Chaque développeur qui démarre une branche pour développer une fonctionnalité sait alors qu’il part sur des bonnes bases et qu’il a la responsabilité de livrer une branche qui garde la CI au vert (par défaut, la CI est lancée sur toutes les branches qui sont poussées sur le gitlab).
Utiliser une image docker¶
Il est courant d’avoir besoin d’un environnement spécifique pour
exécuter les tests (un compilateur spécifique, un environnement de
développement python avec des paquets préinstallés, …). Pour cela on
utilisera une image docker dont l’adresse est spécifiée par le champ
image:
(global ou spécifique à un job). Par exemple :
doc: image: "docker.aix.systerel.fr/c462/sysdoc:0.1" script: - make
Les images peuvent provenir :
de dépôts publics comme Docker Hub,
du dépôt interne de Systerel : https://docker.aix.systerel.fr/,
d’une image fabriquée sur votre machine, voire par l’intégration continue et mise à disposition dans le registre d’image docker de votre projet : https://gitlab.aix.systerel.fr/USERNAME/test_ci/container_registry (nous avons des exemples de fabrication dans un job de l’intégration continue. N’hésitez pas à demander à la DT si vous avez ce genre de besoin).
Utiliser des services¶
La CI permet de réaliser des tests unitaires, mais aussi des tests d’intégration ou des tests fonctionnels. Par exemple, pour tester un serveur web, nous avons peut-être besoin d’avoir une base de données opérationnelle (postgres, mongodb, redis ou autre). Il est possible dans ce cas de définir un service associé au job au moyen d’une image docker. Concrètement, l’image sera démarrée avant l’exécution du job et le service inclus dans l’image sera disponible via le réseau.
Le job suivant définit le service redis utilisant l’image de même nom du
Docker Hub qui sera accessible par
le programme en test sous le nom redis
(il est aussi possible de
définir des
alias) :
test: stage: test services: - redis:6.2.5-alpine script: - cd go/src - go test -race -p 1 ./...
Mise au point de la CI¶
Il peut être difficile et un peu laborieux de mettre au point un fichier
.gitlab-ci.yml
: on modifie, on commit, on pousse, on voit qu’il y a
des erreurs et on recommence. Trois outils nous permettent d’être plus
efficace :
l’outil CILint disponible sur la page Pipelines votre projet. Vous pouvez y coller votre configuration et les erreurs de syntaxe ou de configuration seront signalées.
-
le lancement en local d’un job d’intégration continue via l’outil
gitlab-runner
:Installer
gitlab-runner
sur votre poste (voir les instructions),-
Lancer le job
tests
par la commandegitlab-runner exec docker tests
. Le paramètredocker
signifie que le job sera lancé dans une image docker (ce qui nécessite d’avoir un démon ou service docker activé). On peut utiliser le paramètreshell
à la place dedocker
si le job n’a pas besoin d’environnement spécifique pour s’exécuter.Cette utilisation reste limitée à des jobs simples (par exemple, la directive extends ne semble pas prise en compte et il n’est pas possible de dérouler tout un pipeline).
Utiliser l’outil tiers gitlab-ci-local qui devrait permettre de dérouler tout un pipeline en local. Je l’ai utilisé avec plus ou moins de succès en fonction de la complexité des jobs.
Note
Si vous avez des remarques ou questions à propos de cet article, n’hésitez pas à me contacter ou à ouvrir un ticket ou une merge request sur le projet gitlab du blog.
- 1
-
si vous avez besoin de mettre en place un miroir de dépôt de PCB vers le gitlab, faites une demande au SI.
- 2
-
un runner est un service qui est lancé sur une machine et qui communique avec l’instance gitlab pour savoir quels sont les jobs qui lui sont affectés.
À l’heure de l’écriture de cet article, un runner partagé est configuré sur la machine marouette (6 cpus i5-8500@3Ghz et 32 Go de RAM) dont vous pouvez visualiser l’occupation sur ce tableau de bord grafana.
Commentaires