Votre pipeline contient désormais les étapes de build et de test.

Dans ce dernier chapitre de la partie CI, nous allons voir les deux dernières étapes du pipeline d'intégration continue : la qualité de code et la gestion des livrables.
Mesurez la qualité de votre code
Commençons par l'analyse de code statique, afin de contrôler la qualité du code.
Nous allons donc modifier le pipeline de code, afin d'ajouter cette analyse de code. Il faut alors modifier le fichier .gitlab-ci.yml
afin qu'il ressemble à ceci :
:
- build
- test
- quality
:
:
- .m2/repository
: "$CI_JOB_NAME"
:
: build
:
- ./mvnw compile
-Dhttps.protocols=TLSv1.2
-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository
-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN
-Dorg.slf4j.simpleLogger.showDateTime=true
-Djava.awt.headless=true
--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true
: openjdk:8-alpine
:
: test
:
- ./mvnw test
-Dhttps.protocols=TLSv1.2
-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository
-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN
-Dorg.slf4j.simpleLogger.showDateTime=true
-Djava.awt.headless=true
--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true
: openjdk:8-alpine
:
: quality
: docker:stable
: true
:
- docker:stable-dind
:
- mkdir codequality-results
- docker run
--env CODECLIMATE_CODE="$PWD"
--volume "$PWD":/code
--volume /var/run/docker.sock:/var/run/docker.sock
--volume /tmp/cc:/tmp/cc
codeclimate/codeclimate analyze -f html > ./codequality-results/index.html
:
:
- codequality-results/
Dans ce job, nous retrouvons les 3 lignes des étapes précédentes, plus d'autres lignes :
allow_failure
: cette ligne autorise l'échec de l'étape de qualité. Comme ce n'est pas une étape critique, nous nous permettons d'autoriser l'échec et de laisser le pipeline continuer ;services
: ce nouveau mot clé de GitLab permet de démarrer un démon Docker, pour que l’exécution de notre programme d’analyse de code puisse se faire. Cette ligne nous permet d'exécuter Docker au sein de l'image, afin d'exécuter l'analyse de code ;script
: cette ligne est un peu plus compliquée que les lignes de script précédentes. La première ligne va créer un dossiercodequality-results/
qui contiendra le résultat de l'analyse de code. La deuxième ligne monte le code à l'intérieur d'une image Docker via le dossier/code
, et lance l'analyse via le programmecodequality
. Le résultat sera exporté dans le dossiercodequality-results
;artifact
: cette ligne est un prérequis de GitLab si nous voulons voir notre évolution de qualité. Le dossiercodequality-results/
sera stocké au sein de GitLab afin de pouvoir voir le résultat de l'analyse du scan. Ce résultat sera disponible et visible au sein du jobcode_quality_job
.
Tout le script est exécuté au sein de l'image docker:stable
. Cette image permet de démarrer le programme d’analyse de code.
Une fois le fichier commité sous Git et envoyé sur GitLab via les commandes suivantes, le pipeline d'intégration continue va alors se mettre à jour et lancer une compilation, suivie d'une analyse statique du code.
Le code est alors analysé par GitLab, et le rapport généré stocké au niveau des artefacts. Pour voir le résultat de l'analyse de code, il suffit de naviguer dans le job code_quality_job
, puis de cliquer sur Browse. Vous aurez alors accès au dossier contenant le résultat de l'analyse de code, et pourrez naviguer au sein de ce fichier, afin de voir les améliorations à apporter au code.
Ça y est, l'étape de qualité est implémentée !

Packagez votre application pour la déployer
La prochaine étape après la qualité du code est le packaging de l'application, afin de pouvoir la déployer plus facilement. Pour ce projet, nous allons choisir Docker comme programme de packaging.
GitLab vient avec une registry Docker incluse, ce qui nous permet de stocker ces images au sein de GitLab. Pour pouvoir packager nos images Docker, il est nécessaire d'ajouter une nouvelle étape à notre pipeline d'intégration continue. Nous allons une nouvelle fois modifier le fichier.gitlab-ci.yml
pour ajouter cette nouvelle étape. Le fichier final ressemblera alors à ceci :
:
- build
- test
- quality
- package
:
:
- .m2/repository
: "$CI_JOB_NAME"
:
: build
:
- ./mvnw compile
-Dhttps.protocols=TLSv1.2
-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository
-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN
-Dorg.slf4j.simpleLogger.showDateTime=true
-Djava.awt.headless=true
--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true
: openjdk:8-alpine
:
: test
:
- ./mvnw test
-Dhttps.protocols=TLSv1.2
-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository
-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN
-Dorg.slf4j.simpleLogger.showDateTime=true
-Djava.awt.headless=true
--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true
: openjdk:8-alpine
:
: quality
: docker:stable
: true
:
- docker:stable-dind
:
- mkdir codequality-results
- docker run
--env CODECLIMATE_CODE="$PWD"
--volume "$PWD":/code
--volume /var/run/docker.sock:/var/run/docker.sock
--volume /tmp/cc:/tmp/cc
codeclimate/codeclimate analyze -f html > ./codequality-results/index.html
:
:
- codequality-results/
:
: package
:
- docker:stable-dind
:
: tcp://docker:2375
:
- apk add --no-cache docker
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
- ./mvnw install -PbuildDocker -DskipTests=true -DpushImage
-Dhttps.protocols=TLSv1.2
-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository
-Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN
-Dorg.slf4j.simpleLogger.showDateTime=true
-Djava.awt.headless=true
--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true
: openjdk:8-alpine
Ce job supplémentaire compile le projet et l'encapsule dans un conteneur. Il est ensuite poussé sur la registry de GitLab. Nous retrouvons toutes les lignes que nous avons vues précédemment. La partie script
lance cependant quelques commandes supplémentaires :
tout d'abord, nous installons le client Docker dans l'image
openjdk:8-alpine
afin de pouvoir lancer les commandes propres à Docker ;ensuite, nous nous connectons sur la registry interne de GitLab afin de pouvoir pousser les images Docker de façon sécurisée ;
enfin, nous lançons la commande Maven de création de l'image Docker.
Ce processus nous permettra, dans la livraison continue, de pouvoir déployer facilement le même code sur différents environnements. Il sert aussi à figer le code compilé dans un package immuable. De ce fait, nous pouvons facilement redéployer le même code compilé sur n'importe quel autre environnement. Cela assure que le code ne soit pas modifié entre deux environnements, et qu'un code testé soit déployé partout de la même façon. Les images Docker ainsi packagées se retrouvent sur la page de la registry :

Nous avons maintenant toutes les étapes nécessaires pour l'intégration continue. Comme prévu, notre code est compilé en continu, testé, analysé puis packagé, prêt à être déployé sur de nouveaux environnements.

Les autres outils de l'intégration continue
Vous avez donc vu tout au long de cette partie comment mettre en place l'intégration continue avec GitLab, mais sachez qu'il existe d'autres outils reprenant les mêmes concepts. Le plus connu et le plus utilisé d'entre eux est Jenkins. Avec cet outil, vous pouvez implémenter toutes les étapes précédemment vues. De plus, Jenkins utilise maintenant un fichier de description comme GitLab, qui s'appelle Jenkinsfile.
Le principe est strictement le même que GitLab : il s'agit d'un fichier de description du pipeline d'intégration continue qui va contenir toutes les étapes à lancer, afin de garantir que le code compile et soit de qualité à tout moment. Cependant, il est nécessaire d'installer Jenkins dans votre entreprise, de le configurer, de le maintenir et de le mettre à jour, ce qui peut s'avérer long et fastidieux.
Pour ceux qui ne voudraient pas passer leur temps à maintenir ce genre d'outils, il existe aussi d'autres outils en mode Software-as-a-Service (SaaS), où la maintenance et l'évolution sont garanties par le fournisseur. Ces outils peuvent être mieux adaptés pour mettre en place rapidement et sans effort un pipeline d'intégration continue. Les outils les plus connus dans cet écosystème sont Travis CI et CircleCI.
Le gros avantage de ces outils est que la maintenance n'est pas à la charge de l'équipe, mais du fournisseur. De plus, ces outils peuvent se connecter automatiquement sur Github.com pour la plupart, ce qui évite aussi les configurations longues et fastidieuses des différents outils.
Enfin, GitHub a sorti une beta de son nouveau service à destination des développeurs, afin de pouvoir implémenter rapidement des pipelines d'intégration continue : GitHub Actions. Le principe est toujours le même : un fichier .workflow
permet de créer un pipeline, afin de compiler et déployer du code sur n'importe quelle plateforme. L'avantage principal de GitHub Actions est que ce dernier est directement intégré dans GitHub.
En résumé
Dans ce chapitre, nous avons vu comment ajouter les étapes de mesure de la qualité de votre code ainsi que de packaging de votre application, pour sauvegarder les artefacts prêts à être déployés.
Et voilà ! Vous avez mis en place toutes les étapes de l'intégration continue ! 👏🎉
Dans la prochaine partie, nous mettrons en place la livraison continue, du déploiement à la supervision, en passant par les tests en production.