CI et CD : Jenkins, comment fonctionnent ses pipelines ? [FRENCH]

Jenkins est l’outil de Continuous Integration (CI) et Continuous Delivery (CD) le plus populaire, certainement pas pour son interface utilisateur plutôt vieillotte, mais pour la très grande richesse de ses plugins. Vous pouvez retrouver la liste à cette adresse : https://plugins.jenkins.io/. Jenkins est un Open Source développé en Java. Anciennement. Hudson, il a changé de nom en Jenkins lors de son rachat par Oracle.

Comme nous allons le voir, Jenkins est parfaitement adapté à l’utilisation de Docker et offre une bonne souplesse dans sa mise en oeuvre.

Dans Jenkins, un Pipeline est une séquence d’opérations automatisées permettant de livrer un produit ayant suivi un process d’assurance qualité.

Au centre de Jenkins se trouvent les Pipelines

Les Pipelines peuvent être créés de deux manières :

  • dans l’interface utilisateur de Jenkins,
  • dans un fichier (Jenkinsfile) intégré dans le repository.

Les Pipelines peuvent être créés via l’interface utilisateur de Jenkins

Il existe deux types de pipelines :

  • Step : c’est une opération simple (exemple : exécuter un script),
  • Stage : c’est un regroupement de Steps (exemple : Test).

Le Pipeline est structuré en sections. Chaque section contient un ou plusieurs Directives ou Steps :

  • Les directives permettent de configurer les opérations, en spécifiant par exemple l’agent, en mettant en place des triggers ou en spécifiant les conditions de déclenchement du Stage.
  • Les Steps, comme indiqué précédemment, décrivent les opérations à exécuter.

Le Commit Pipeline démarre après chaque changement dans le code, c’est-à-dire lorsqu’un commit est fait vers le repository principal. Il ne devrait pas durer plus de 5 minutes. Il peut être exécuté sur n’importe quel agent Jenkins.

Ce Pipeline comprend trois Stages :

  • Checkout : Jenkins télécharge le code source depuis le repository.
  • Compile : Celui est déclenché en cliquant sur le bouton de build dans Jenkins.
  • Unit Test : Les tests unitaires sont exécutés et un rapport HTML est produit.

Les Pipelines peuvent aussi être créés via un fichier Jenkinsfile

Les fichiers Jenkinsfile contiennent la même chose que le Pipeline Commit sauf le téléchargement (checkout) du code source puisque ce fichier se trouve déjà dans le code source.

Pour exécuter le Pipeline d’un fichier Jenkinsfile, il suffit de sélectionner le Pipeline dédié au Git et d’entrer l’URL du repository dans lequel se trouve le fichier Jenkinsfile.

Jenkins permet de contrôler la qualité du code

Jenkins prend en charge la couverture de test

Le premier volet de l’analyse de la qualité du code est l’outils de calcul de la couverture de test. Il vérifie quelles parties du code ont été exécutées et présente le résultat dans un rapport HTML. Les outils les plus populaires sont JaCoCo, Clover et Cobertura.

Pour générer un rapport HTML, il est nécessaire d’utiliser un plugin supplémentaire (HTML Publisher).

Jenkins prend aussi en charge l’analyse de code statique

Le second volet est l’analyse de code statique. Elle permet de mesurer la maintenabilité du code source et de s’assurer que le code est bien écrit. Pourquoi ce non ? Tout simplement parce que l’analyse est faire sans exécuter le code.

Concrètement, un certain nombre de règles sont vérifiées sur le code source (commentaire présent pour les classes publiques, définition de méthode equals(), longueur maximale des lignes, …).

Il y a deux solutions pour faire cette opération. La première est d’utiliser le Pipeline de qualité de code. Cette analyse est alors faite dans le cas d’Android par Checkstyle, pour lequel vous devez définir un jeu de règles qui vont être vérifiées.

Mais il existe une seconde solution : utiliser un outils de gestion de la qualité du code source dédié. Le plus connu est SonarQube. Il a plusieurs avantages. Le premier est qu’il supporte un grand nombre de languages. Un second est qu’il intègre de base plusieurs outils (pour Android : Checkstyle bien sûr, mais aussi FindBugs et JaCoCo). Le troisième est qu’il met à disposition un dashboard complet.

Et tout ça s’intègre très bien avec Jenkins. Avec cette solution, au lieu d’utiliser une Step de qualité de code, on utilise un Stage Sonar.

Les triggers permettent de déclencher les compilations

Afin que les Pipelines puissent démarrer automatiquement, on utilise la notion de trigger dans Jenkins. Il existe trois types de triggers :

Les triggers externes

La compilation est lancée sur appel du notifieur (exemple : GitHub, un autre Pipeline, …).

Les triggers de polling SCM

Jenkins appelle périodique le repository (GitHub par exemple) et vérifier s’il y a eu un nouveau push dans le repository; si c’est le cas, la compilation est lancée.

Cette solution est intéressante si les compilations sont longues.

Les triggers de compilation planifiés (Scheduled build)

Jenkins lance la compilation périodiquement, qu’il y ait eu ou non un commit sur le repository.

Les notifications permettent d’annoncer le statut des compilations

Pour annoncer le statut des compilations, Jenkins utilise les notifications. Il est possible d’envoyer des notifications uniquement en cas de changement de statut, en cas d’échec, de succès, d’instabilité ou à chaque lancement.

Il existe plusieurs types de notifications :

  • par email
  • par chat
  • par espace d’équipe

Nous voici à la fin de l’article. Maintenant, vous savez comment fonctionnent les pipelines et comment on les crée et vous connaissez les principes des triggers et des notifications. Dans un prochain article, je présenterai les différents scénarios d’architecture des serveurs Jenkins. A suivre donc …

Comments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×