Architecture de base des pipelines Gitlab CICD
Une chaîne CI/CD (Continuous Integration/Continuous Deployment) GitLab est composée de plusieurs éléments principaux. Voici les composants clés d'une chaîne CI/CD GitLab :
Projet
Le projet Gitlab, avec un repo Git comme composant principal, est le coeur des pipelines de CICD.
Les pipelines sont définies et s'exécutent au sein d'un projet donné.
Pipeline
La pipeline est le composant central d'une chaine de CICD. Il s'agit d'un enchainement de tâches, qui s'exécutent selon différentes conditions, dans un contexte donné, pour réaliser une action donnée.
Dans Gitlab, une pipeline est constituée d'étapes, ou stages, qui comprennent une ou plusieurs tâches, ou jobs.
Elle est définie dans le fichier .gitlab-ci.yml
(! pas .yaml
) par défaut.
!
Stages
Un regroupement logique de jobs qui vont s'exécuter en parallèle (sous réserve de suffisamment de puissance de calcul dispo).
Les stages s'exécutent les uns après les autres (sauf indication contraire avec les needs
, voir Jour 2 : Architecture avancée) selon l'ordre défini dans le fichier de configuration.
En général on regroupe les jobs qui ont des but similaires dans le même stage (ex: test
, code quality
, build
, deploy
...), même si techniquement rien ne l'impose.
!
Jobs
Les jobs sont les briques de base des pipelines. Chaque job est responsable de l'exécution d'une tache donnée.
Le résultat de cette action détermine le statut du job (succès ou échec).
Chaque job fait nécessairement partie d'un stage.
!
Runners
Les runners sont les agents où s'exécutent les étapes des pipelines. Ils peuvent être hébergés sur une infrastructure dédiée.
Chaque runner a des caractéristiques qui lui sont propres (OS, architecture CPU, outils à disposition...).
Les runners peuvent être hébergés sur une infrastructure dédiée. Gitlab propose des runners sur son offre SaaS gitlab.com avec un pricing variant selon la souscription (Community vs Entreprise vs Premium) et le type de runner utilisé (Linux small, medium, large, macOS, GPU pour HPC...).