Les pipelines CI/CD dans GitLab

Introduction

À ce stade de votre lecture, vous avez suffisamment de connaissances sur Git et les fonctionnalités de gestion et de suivi de projets dans GitLab pour utiliser ces outils dans les phases initiales du cycle de vie du développement logiciel.

Dans ce chapitre, nous allons entrer dans le vif du sujet et voir comment fonctionnent les pipelines CI/CD. Nous commencerons par une partie théorique où nous verrons en quoi consistent les pipelines, quels sont leurs composants et comment elles mettent en œuvre l’intégration continue (CI) et la livraison ou le déploiement continus (CD).

Après avoir terminé ce volet théorique, nous apprendrons à écrire des fichiers de configuration de pipelines en utilisant des structures de données YAML et des mots-clés qui nous permettront de définir des étapes (stages) et des jobs.

Pour illustrer notre propos, nous commencerons par configurer un pipeline simple de type Hello World! et nous poursuivrons avec d’autres exemples plus complexes que nous construirons progressivement pour bien comprendre le rôle de chaque composant.

En plus de découvrir les différentes façons dont GitLab permet de déclencher des pipelines, nous verrons aussi en quoi il peut être pertinent de contrôler la fréquence de leur exécution.

À travers les exemples que nous...

Définition de la notion de pipeline

Un pipeline CI/CD dans GitLab est une série d’étapes définissant une ou plusieurs tâches (jobs) qui s’exécutent sur les fichiers du projet chaque fois qu’une modification est effectuée dans le dépôt Git d’un projet. Ces étapes peuvent inclure la compilation du code, l’exécution de tests, le déploiement de l’application, etc.

En d’autres termes, l’exécution d’un pipeline est déclenchée par un commit, mais il est également possible de configurer d’autres modes de déclenchement que nous verrons en détail plus bas.

Les actions effectuées par un pipeline sont spécifiées dans un fichier spécial nommé .gitlab-ci.yml qui doit être créé à la racine du dépôt du projet. Ce fichier utilise une syntaxe YAML pour définir les différentes étapes et jobs du pipeline ainsi que leur plateforme d’exécution ou leur environnement de déploiement. 

Une autre façon de voir un pipeline est de dire qu’il s’agit d’un plan ou d’une recette pour exécuter une série d’étapes qui seront appliquées aux fichiers d’un projet. Dans le contexte qui nous occupe, il s’agit des fichiers inclus dans un dépôt Git hébergés sur GitLab : code source, configuration, documentation, etc. Bien entendu, les fichiers de code source sont les plus couramment ciblés par les étapes d’un pipeline.

Les deux parties d’un pipeline

Bien que chaque projet GitLab ne définisse qu’un seul pipeline, la plupart du temps elles sont composées de deux parties, comme le souligne l’expression « pipeline CI/CD ».

La première partie relève de l’intégration continue (CI), tandis que la deuxième est liée à la livraison ou le déploiement continus (CD). Voyons ce qui distingue ces deux aspects d’un pipeline.

Comprendre le fichier .gitlab-ci.yml

Comme nous l’avons mentionné plus haut, la configuration d’un pipeline CI/CD se fait dans un fichier nommé .gitlab-ci.yml qui se trouve à la racine du dépôt d’un projet. Ce nom est spécifique à GitLab et son utilisation est requise pour que les pipelines soient reconnus et exécutés. Comme l’extension le suggère, il s’agit d’un fichier rédigé en YAML, un format de sérialisation de données simple et facile à lire.

Le .gitlab-ci.yml est un fichier de configuration qui détermine les tâches qui seront effectuées dans le pipeline de ce projet. Il contient les instructions nécessaires pour automatiser le processus de build, les tests et le déploiement d’une application. C’est dans ce fichier que sont déclarés les étapes, les jobs et les commandes dont nous avons déjà parlé.

Chaque fichier .gitlab-ci.yml utilise un langage spécifique qui se compose principalement de mots-clés avec des valeurs correspondantes. Certains d’entre eux définissent les étapes et les jobs, alors que d’autres sont utilisés pour configurer différentes tâches dans le pipeline. Il existe d’autres mots-clés qui permettent de définir des variables, de spécifier des images Docker pour exécuter les jobs ou d’autres actions comme l’ajout d’une condition de déclenchement ou la création d’artéfacts.

Le langage utilisé pour le fichier de configuration comprend environ 30 mots-clés qui sont largement suffisants pour faire presque toutes les tâches du SDLC. Il n’est pas nécessaire de mémoriser toutes les options disponibles, mais plutôt d’avoir une vue d’ensemble de ce que ces mots-clés permettent de faire dans les pipelines.

En général, vous utiliserez environ une dizaine de ces mots-clés. Au besoin, vous pouvez consulter la documentation...

Exemple de pipeline Hello world

Avant de mettre en pratique la syntaxe YAML en créant notre premier fichier .gitlab-ci.yml, commençons par exécuter le pipeline de test Hello world proposé par GitLab pour nous familiariser avec le processus. Vous pouvez réutiliser le projet avec lequel nous avons travaillé dans le chapitre Organiser et suivre son travail dans GitLab ou en créer un nouveau.

L’éditeur de pipeline va s’ouvrir sur un fichier .gitlab-ci.yml.

1. Présentation du fichier .gitlab-ci.yml

Avant de déclencher le pipeline en appuyant sur Valider les modifications, prenons un instant pour voir ce qui est défini dans ce fichier .gitlab-ci.yml en l’examinant plus attentivement.

D’abord, nous pouvons constater que la syntaxe de tout fichier .gitlab.yml est vérifiée automatiquement par GitLab pour s’assurer que votre YAML est correct et que les mots-clés sont bien utilisés.

Après les commentaires, nous voyons que les étapes sont déclarées avec le mot-clé stages (ligne 19) et chacune d’entre elle constitue une valeur de la séquence ou tableau qui suit (build, test, deploy). Le nom des étapes n’a pas d’importance, mais il est préférable de conserver une nomenclature universelle comme celle-ci.

Les étapes indiquent un ordre précis d’exécution à respecter que vous pouvez voir en mode graphique en appuyant sur l’onglet Visualiser.

Le bloc suivant définit le premier job (build-job) en précisant :

• l’étape à laquelle le job doit s’exécuter (valeur de la clé stage à la ligne 25) ;

• l’action que doit effectuer le GitLab Runner : exécuter un script (commandes). 

Comme c’était le cas pour les « stages », le nom des jobs n’a aucune importance. Il convient toutefois d’adopter une nomenclature simple qui exprime bien...

Créer un premier fichier de configuration de pipeline

Maintenant que nous connaissons les principales notions des pipelines dans GitLab et que nous avons en avons vu un en action avec l’exemple Hello world, nous sommes prêts à créer notre premier fichier de configuration.

Dans les sections qui suivent, nous allons construire un fichier .gitlab-ci.yml pas à pas en expliquant les mots-clés à mesure que nous les utiliserons.

1. Indications sur l’utilisation des composants

Avant de commencer, il est important de bien comprendre comment s’emboîtent les étapes, les jobs et les commandes. Voici quelques indications sur l’utilisation de ces composants dans GitLab :

• Chaque pipeline se compose d’au moins une étape (stage). Une étape représente une catégorie de tâches que le pipeline doit effectuer.

• Chaque étape contient au moins un job et ce dernier représente une tâche unique que le pipeline doit effectuer.

• Chaque job contient au moins une commande (ou script). Une commande est l’équivalent de ce qu’une personne taperait dans un shell pour effectuer une tâche de pipeline.

Comme nous l’avons déjà mentionné, la plupart des pipelines contiennent au moins trois étapes (Build, Test et Deploy) et le type de job au sein de chacune d’entre elles est souvent assez similaire d’un projet à l’autre.

Bien que ces étapes et jobs de base soient assez courants, la plupart des projets vont avoir recours à une nomenclature spécifique aux besoins du produit à développer. 

Créer un nouveau projet pour tester le pipeline

Pour pratiquer l’écriture d’un fichier .gitlab-ci.yml et tester les pipelines, nous vous invitons à créer un nouveau projet dans GitLab. Le nôtre se nomme « Exemples Bash », car nous allons nous exercer avec des commandes simples en Bash.

 Après avoir créé votre nouveau projet, ouvrez le menu Compilation dans le panneau latéral gauche et appuyez sur Éditeur de pipeline. Cliquez ensuite sur le bouton Configurer le pipeline dans la vue centrale.

 Supprimez le contenu du fichier qui donne un exemple de création du fichier de configuration.

Pour les exemples...

Contrôler l’exécution des pipelines

GitLab propose un certain nombre de mots-clés et d’instructions permettant de contrôler l’exécution des pipelines. Il s’agit généralement de conditions et leur utilisation peut optimiser les processus CI/CD selon les besoins spécifiques d’un projet. Les sections qui suivent présentent les mots-clés de contrôle d’exécution les plus utilisés.

Autres modes de déclenchement des pipelines

Comme nous le savons maintenant, la manière la plus courante d’exécuter un pipeline consiste à faire un commit à la suite d’une modification sur une branche. À chaque fois que vous le faites, GitLab exécute automatiquement un pipeline sur la version des fichiers de votre projet qui existe dans ce commit. 

Il existe d’autres modes de déclenchement des pipelines que nous allons présenter dans les sections suivantes.

1. L’exécution manuelle

GitLab vous permet d’exécuter manuellement un pipeline sur n’importe quelle branche Git, même si ce n’était pas la dernière branche sur laquelle vous avez validé des modifications.

 Pour déclencher un pipeline manuellement, rendez-vous sur la page d’accueil du projet et ouvrez le menu Compilation dans le panneau latéral. Dans la vue centrale, appuyez sur le bouton Nouveau pipeline en haut à droite (en anglais, ce bouton se nomme Run pipeline, ce qui est plus précis que « nouveau pipeline »).

 Sélectionnez la branche sur laquelle vous souhaitez exécuter le pipeline et appuyez sur Nouveau pipeline. L’utilisation de variables sera présentée dans le chapitre Aller plus loin avec les pipelines CI/CD.

Vous verrez ensuite votre pipeline en cours d’exécution :