Introduction

Dans ce chapitre, nous allons explorer des techniques avancées pour optimiser, structurer et rendre nos pipelines plus performants et plus modulaires. À mesure que les projets se complexifient, il devient essentiel de tirer parti des outils disponibles pour réduire la duplication, améliorer l’efficacité et organiser les workflows CI/CD de manière plus flexible.

Nous commencerons par les variables et les règles qui permettent d’ajuster dynamiquement l’exécution des jobs en fonction du contexte du pipeline. Ensuite, nous verrons comment les graphes acycliques dirigés (DAG) et le parallélisme permettent d’exécuter plusieurs jobs simultanément pour accélérer le pipeline tout en optimisant l’utilisation des ressources.

Nous poursuivrons avec les pipelines parent-enfant et multiprojets, des approches utiles pour organiser des tâches complexes en structurant l’exécution des jobs dans un même projet ou entre plusieurs dépôts GitLab. Nous verrons également comment l’héritage de configuration permet de mieux contrôler les paramètres transmis d’un pipeline à un autre.

Ensuite, nous nous pencherons sur l’optimisation des fichiers et des dépendances avec le cache, qui permet de réutiliser des fichiers entre différentes...

Optimiser l’exécution des pipelines avec les variables

Nous avons déjà utilisé des variables dans certains exemples, mais nous avions réservé leur présentation détaillée pour un chapitre ultérieur. Dans la section suivante, nous verrons en quoi consistent les variables GitLab et nous passerons en revue les différents types disponibles en donnant des exemples concrets pour mieux comprendre leur utilisation.

1. Le rôle des variables

Les variables GitLab permettent d’optimiser les pipelines et de les rendre plus dynamiques en adaptant leur exécution en fonction du contexte sans avoir à modifier directement le fichier .gitlab-ci.yml à chaque besoin spécifique. En d’autres termes, elles améliorent la portabilité du fichier de configuration du pipeline qui devient réutilisable, que ce soit pour différents environnements (dev, staging, prod), différentes configurations (versions de logiciels, options de build) ou même différents projets.

Les variables permettent de réduire la duplication du code, de modifier le comportement des jobs et d’améliorer la gestion des secrets et des configurations. Elles sont accessibles dans l’environnement d’exécution des jobs et elles peuvent être utilisées dans les scripts comme n’importe quelle variable d’environnement classique. GitLab les exporte automatiquement et elles sont disponibles dans le shell des runners.

Comme nous l’avons déjà vu précédemment, les variables sont déclarées avec le mot-clé variables dans le fichier de configuration et elles peuvent être définies à différents niveaux (projet, groupe, instance ou directement dans le pipeline). Elles ont également des portées (scopes) spécifiques qui déterminent leur champ d’action et leur visibilité dans un pipeline. Commençons par présenter la façon dont vous pouvez utiliser les variables.

2. Le mode d’utilisation des variables

Dans GitLab, les variables sont référencées en utilisant le symbole $, comme dans $VARIABLE_NAME, pour les appeler directement dans les scripts. Lorsque les variables sont intégrées dans une chaîne de caractères...

Contrôler l’exécution avec les règles

Dans GitLab, les règles permettent de contrôler finement l’exécution des jobs en définissant des conditions précises. Plutôt que d’exécuter un job systématiquement à chaque pipeline, les règles offrent la possibilité d’utiliser des filtres pour adapter le déroulement du pipeline en fonction du contexte.

1. Le rôle des règles dans les pipelines

Dans GitLab, les règles vous permettent notamment d’optimiser le pipeline en évitant les exécutions inutiles et en ciblant uniquement les situations où un job est réellement nécessaire. Les règles sont définies sous le mot-clé rules dans le fichier .gitlab-ci.yml. Elles fonctionnent comme des filtres conditionnels qui permettent de déterminer si un job doit ou non s’exécuter en fonction de critères spécifiques.

Par exemple, avec les règles, il est possible d’exécuter un job uniquement sur une branche spécifique, lorsqu’un fichier particulier est présent ou encore si certains fichiers ont été modifiés.

Vous pouvez aussi utiliser des expressions régulières (regex) pour cibler dynamiquement des branches ou des tags en suivant une convention de nommage. Les règles permettent d’optimiser le processus CI/CD et elles ont l’avantage de réduire la charge d’exécution sur les runners.

2. La structure conditionnelle des règles

La structure conditionnelle utilisée pour les règles est le mot-clé if placé après la section script d’un job, comme ceci :

test_job: 
  stage: test 
  script: 
    - echo "Test en cours..." 
  rules: 
    - if: '$CI_COMMIT_BRANCH == "main"'

Vous pouvez simuler un if-else de deux manières :

En définissant plusieurs règles et en utilisant when pour déterminer l’action à exécuter :

test_job: 
  stage: test 
  script: 
    - echo "Test en cours..." 
  rules: 
    - if: '$CI_COMMIT_BRANCH...

Optimiser la performance des pipelines

1. Les pipelines basés sur le modèle DAG

En 2020, GitLab a lancé un nouveau type de pipeline basé sur le modèle de graphe acyclique dirigé (Directed Acyclic Graph, DAG) qui permet d’optimiser l’exécution. Dans un pipeline traditionnel, les étapes se succèdent de manière séquentielle : chaque étape, composée de plusieurs jobs exécutés en parallèle, doit être terminée avant que la suivante ne commence.

Avec le modèle DAG, les tâches peuvent être organisées en fonction de leurs dépendances spécifiques plutôt que de l’ordre des étapes.

a. Fonctionnement des pipelines DAG

Le modèle DAG repose sur trois concepts clés (qui sont plus simples que ce que leur nom laisse penser) :

Directed (dirigé) : les jobs s’exécutent dans un ordre précis, défini par leurs dépendances.
Acyclic (acyclique) : il n’y a pas de boucle, un job ne peut pas dépendre de lui-même.
Graph (graphe) : ensemble de jobs reliés par des dépendances qui forme une structure optimisée.

Le modèle DAG améliore les pipelines en réduisant les temps d’exécution grâce à une gestion intelligente des dépendances avec le mot-clé needs. Il permet d’exécuter des jobs dès que ceux dont il dépend sont terminés, sans devoir attendre la fin complète de l’étape à laquelle ils appartiennent. Cette approche accélère les processus complexes et améliore l’utilisation des ressources, ce qui rend les pipelines plus rapides et efficaces.

b. Créer un pipeline DAG

Pour créer un DAG dans GitLab, vous devez utiliser le mot-clé needs pour chaque job. Cette directive indique les autres jobs dont le job actuel dépend.

Voici un exemple de fichier de configuration de pipeline basé sur le modèle DAG :

stages: 
  - setup 
  - create 
  - display 
 
create_directory: 
  stage: setup 
  script: 
    - echo "Création d'un répertoire" 
    -...

L’utilisation du cache dans un pipeline

Avant d’exploiter le cache dans un pipeline, il est important de comprendre ce qui le différencie des artéfacts. Bien qu’ils permettent tous deux de conserver des fichiers entre les jobs, leurs rôles sont distincts. Le cache est conçu pour accélérer les tâches répétitives, tandis que les artefacts transmettent des fichiers entre les étapes d’un pipeline. Choisir l’un ou l’autre dépend des besoins spécifiques de votre workflow CI/CD.

Dans cette section, nous verrons en quoi le cache et les artefacts sont différents et comment les utiliser efficacement. Nous montrerons aussi comment leur gestion peut être optimisée avec différents backends de stockage comme un bucket AWS S3, un Azure Blob Storage ou un Google Cloud Storage bucket.

1. La différence entre le cache et les artéfacts

Le cache

Le cache permet de stocker temporairement des fichiers fréquemment utilisés afin d’éviter de les télécharger ou de les générer à chaque exécution du pipeline. Contrairement aux artéfacts, il ne sert pas à établir une dépendance stricte entre les jobs.

Le cache est géré par le GitLab Runner qui stocke les fichiers localement ou sur un backend distant comme un service de stockage objet cloud. Il est défini avec le mot-clé cache et il peut être partagé entre plusieurs jobs si la clé (key) est identique. Voici deux autres caractéristiques du cache :

Il est spécifique à un projet individuel, il ne peut donc pas être partagé.
Par défaut, les branches protégées et non protégées ne partagent pas le même cache.

Comme nous l’avons mentionné plus haut, les artéfacts permettent de transmettre des fichiers d’un job à un autre dans un même pipeline. Contrairement au cache, ils créent une dépendance stricte entre les étapes.

Les artéfacts

Les artéfacts sont stockés sur l’instance...

Travailler avec les ancres YAML

Le YAML dispose d’une fonctionnalité nommée « ancres » (anchors) qui permet de dupliquer du contenu dans un document. Dans le contexte de GitLab, ces ancres donnent la possibilité de réutiliser des portions de configuration à plusieurs endroits dans le fichier .gitlab-ci.yml. Elles sont utiles lorsque plusieurs jobs partagent des paramètres communs, tels qu’une image Docker, des variables ou un script d’installation.

Ces mécanismes de réutilisation YAML optimisent les des pipelines, en réduisant la duplication et en améliorant la maintenabilité du fichier de configuration.

1. Le fonctionnement des ancres YAML dans GitLab

Dans GitLab, les ancres utilisent trois principaux opérateurs YAML pour la réutilisation et la fusion de configurations :

&(ancre) : définit un bloc réutilisable ;
*(référence) : récupère et applique un bloc précédemment défini ;
<<:(fusion) : intègre une ancre dans un autre bloc en combinant leurs paramètres.

L’utilisation des opérateurs & et *doit obligatoirement être suivie d’un nom pour désigner l’ancre ou la référence.

Il n’y a pas de restriction sur le nom à donner, tant qu’il est identique entre l’ancre (&nom) et sa référence (*nom). Pour une meilleure lisibilité, il est recommandé d’utiliser un nom qui correspond au contenu du bloc réutilisable.

Il y a deux principaux modes d’utilisation des ancres :

avec le tag !reference qui permet de réutiliser uniquement une partie spécifique d’un job sans hériter de l’ensemble de la configuration ;

Contrairement aux ancres YAML (& et *), « !reference » est une fonctionnalité propre à GitLab CI/CD. Le préfixe ! en YAML est généralement utilisé pour introduire des...

Conclusion

Tout au long de ce chapitre, nous avons exploré des concepts avancés permettant d’optimiser, structurer et réutiliser efficacement la configuration des pipelines GitLab.

Nous avons commencé par les variables et les règles qui donnent la possibilité d’adapter dynamiquement l’exécution des jobs en fonction du contexte du pipeline. Ensuite, nous avons découvert les graphes acycliques dirigés (DAG) et des mécanismes de parallélisme qui permettent d’accélérer l’exécution des pipelines en lançant plusieurs jobs simultanément lorsque leurs dépendances le permettent.

Nous avons poursuivi avec les pipelines parent-enfant et multiprojets qui facilitent la gestion des workflows complexes en répartissant les tâches sur plusieurs sous-pipelines ou en orchestrant l’exécution entre plusieurs dépôts. Nous avons ensuite abordé l’héritage de configuration, un outil clé pour contrôler précisément ce qui est transmis d’un pipeline à un autre.

Pour terminer, nous avons vu comment le cache permet d’optimiser la gestion des fichiers et des dépendances entre les exécutions. Pour réduire la duplication et améliorer la maintenabilité des fichiers .gitlab-ci.yml, nous avons exploré les...

Aller plus loin avec les pipelines CI/CD