Aller au contenu principal

Maitriser GITLAB CI/CD

logo gitlab

GitLab CI/CD est devenu un incontournable de l'automatisation du développement. C'est une solution puissante qui permet de rationaliser et d'automatiser le processus de construction, de test et de déploiement de logiciels, ce qui permet aux équipes de développement de gagner du temps, de réduire les erreurs et d'augmenter la qualité de leurs applications.

Lorsque vous travaillez sur des projets de développement, la gestion efficace des pipelines DevOps est essentielle pour garantir une intégration continue et une livraison continue sans heurts. GitLab CI/CD est un outil puissant qui vous permet de créer ces pipelines et de rationaliser votre processus de développement. Avant de plonger dans les détails de son utilisation, commençons par comprendre les concepts de base.

Comprendre les concepts de base de GitLab CI/CD​

Qu'est-ce qu'un pipeline ?​

Un pipeline dans GitLab CI/CD est constitué une série d'étapes qui sont exécutées automatiquement chaque fois qu'il y a un changement dans votre référentiel de code source. Ces étapes sont conçues pour automatiser diverses tâches, telles que la compilation du code, l'exécution de tests, le déploiement d'applications, et bien plus encore. L'objectif principal d'un pipeline est d'assurer la cohérence, la qualité et la rapidité du processus de développement.

Chaque pipeline est déclenché par un événement spécifique, comme une nouvelle validation de code (push) ou la création d'une demande de fusion (merge request). GitLab CI offre une grande flexibilité pour configurer les déclencheurs en fonction de besoins spécifiques.

Les jobs et les étapes dans GitLab CI​

Les pipelines GitLab CI/CD sont composés de jobs, qui sont des unités d'exécution de tâches spécifiques. Ces jobs sont regroupés en étapes (stages), qui représentent des phases logiques du processus de développement. Par exemple, un pipeline typique pourrait comprendre les étapes suivantes :

  1. Build : Cette étape compile le code source pour créer une application exécutable ou un artefact.
  2. Test : Les tests unitaires, les tests d'intégration et d'autres vérifications de qualité sont exécutés ici.
  3. Deploy : Si les tests réussissent, cette étape déploie l'application sur un environnement de test ou de production.

Les jobs au sein de chaque étape sont exécutés de manière parallèle, ce qui permet d'accélérer le processus global de développement. GitLab CI/CD gère également automatiquement les dépendances entre les jobs, de sorte qu'ils sont exécutés dans le bon ordre.

Les artefacts​

Un artifact peut contenir des fichiers et/ou dossiers qui vont être stockés au sein des pipelines pour être utilisé par d'autres taches.

Les tags​

Les tags permettent de définir un runner spécifique dans la liste de tous les runners disponibles d'un projet.

Création d'un pipeline CI/CD Gitlab​

Prérequis​

Pour commencer, nous avons besoin de : • Un compte GitLab.com • Un repo GitLab

Ici, nous utiliserons les runners de Gitlab.com, mais si vous avez installé votre propre serveur gitlab, vous devrez ajouter vos propres runners sur vos serveurs.

Configuration de base du fichier .gitlab-ci.yml​

La configuration des pipelines GitLab CI/CD est définie dans un fichier au format YAML nommé .gitlab-ci.yml, qui se trouve à la racine de votre projet. Ce fichier contient des instructions pour spécifier les étapes, les jobs, les dépendances et d'autres paramètres importants pour votre pipeline.

Voici un exemple simple de fichier .gitlab-ci.yml :

job 0:
  stage: .pre
  script: echo "make something useful before build stage"

build-job:
  tags:
    - ruby
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."

Dans cet exemple, nous avons :

  • Quatre stages (étapes) : .pre, build, test et deploy
  • L'étape test contient deux jobs : test-job1 et test-job2
  • Les jobs sont de simples echo qui affichent des variables prédéfinies de gitlab.

En fait, il existe deux stages prédéfinis : .pre et .post qui sont toujours lancés respectivement au début et à la fin du ci.

Si vous commitez votre fichier, vous pourrez suivre l'exécution du pipeline dans le menu CI/CD.

Pipeline gitlab ci

Ici le résultat de l'étape build :

Running with gitlab-runner 13.9.0-rc2 (69c049fd)
  on docker-auto-scale ed2dce3a
  feature flags: FF_GITLAB_REGISTRY_HELPER_IMAGE:true
Preparing the "docker+machine" executor
Using Docker executor with image ruby:2.5 ...
Pulling docker image ruby:2.5 ...
Using docker image sha256:b8f85f05a4c615b08acb073a366ccf8559bdde860861712bb178fb4ee01102a3 for ruby:2.5 with digest ruby@sha256:edc40b439ce1e771849bb398f70b4e202c18d30a0db391f437820bd712774c75 ...
Preparing environment
Running on runner-ed2dce3a-project-25219583-concurrent-0 via runner-ed2dce3a-srm-1615992594-66af060f...
Getting source from Git repository
$ eval "$CI_PRE_CLONE_SCRIPT"
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/Bob74/test-gitlab/.git/
Created fresh repository.
Checking out eb21ab21 as master...
Skipping Git submodules setup
Executing "step_script" stage of the job script
00:01
Using docker image sha256:b8f85f05a4c615b08acb073a366ccf8559bdde860861712bb178fb4ee01102a3 for ruby:2.5 with digest ruby@sha256:edc40b439ce1e771849bb398f70b4e202c18d30a0db391f437820bd712774c75 ...
$ echo "Hello, $GITLAB_USER_LOGIN!"
Hello, Bob74!
Cleaning up file based variables
00:01
Job succeeded

Vous remarquerez que gitlab.com fait appel à un runner docker utilisant une image ruby:2.5.

GitLab CI/CD offre la possibilité d'exécuter des scripts de préparation et de nettoyage avant et après l'exécution des jobs des pipelines. Cela peut être utile pour la configuration de l'environnement, la gestion des dépendances ou le nettoyage des artefacts temporaires. On utilise les mots clés before_script et after_script.

before_script:
  - echo "Initialisation de l'environnement..."

after_script:
  - echo "Nettoyage de l'environnement..."

Ces scripts de préparation et de nettoyage vous permettent d'automatiser les tâches courantes, de garantir la cohérence de l'environnement d'exécution et de maintenir votre pipeline propre et efficace.

Utiliser d'autres images dans votre pipeline gitlab CI/CD​

On peut en premier lieu changer l'image par défaut de tout le pipeline.

default:
  image: ruby:2.7.2

build-job:
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

...

Ce qui donne :

Running with gitlab-runner 13.9.0-rc2 (69c049fd)
  on docker-auto-scale 0277ea0f
  feature flags: FF_GITLAB_REGISTRY_HELPER_IMAGE:true
Preparing the "docker+machine" executor
00:34
Using Docker executor with image ruby:2.7.2 ...
Pulling docker image ruby:2.7.2 ...

Il est possible d'utiliser différentes images pour chacune des étapes. Pour cela, il suffit de le spécifier :

default:
  image: ruby:2.7.2

build-job:
  image: alpine:3.12
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"
...

Ce qui donne :

Running with gitlab-runner 13.9.0-rc2 (69c049fd)
  on docker-auto-scale fa6cab46
  feature flags: FF_GITLAB_REGISTRY_HELPER_IMAGE:true
Preparing the "docker+machine" executor
Using Docker executor with image alpine:3.12 ...

Les images utilisées sont celles que vous retrouvez dans le docker hub. Attention au rate limit de docker et stockez vos images dans la registry de Gitlab.

Utiliser des variables​

Il est possible de créer vos propres variables en utilisant variables dans vos jobs. Ces variables sont de la forme clé: valeur

default:
  image: ruby:2.7.2

build-job:
  image: alpine:3.12
  stage: build
  variables:
    test: "je suis un test"
  script:
    - echo "$test"
...

Il est possible d'utiliser des variables dans d'autres variables :

job:
  variables:
    FLAGS: '-al'
    LS_CMD: 'ls "$FLAGS"'
  script:
    - 'eval "$LS_CMD"'  # Executes 'ls -al'

Il est également possible de créer des variables dans les paramètres CI/CD de votre projet. Ces variables sont soit de la forme de fichier (File) ou Variable et peuvent être cachées/protégées. Nous n'avons pas vu encore la notion d'environnement, mais on peut également limiter la portée à un environnement précis.

Pipeline gitlab ci/cd

Pipeline gitlab ci/cd

Précédence des variables​

La notion de "précédence des variables" fait référence à la hiérarchie selon laquelle les variables sont recherchées et utilisées lorsque plusieurs variables du même nom sont définies à différents niveaux.

Dans GitLab CI/CD, les variables peuvent être définies à différents niveaux, et leur priorité varie en fonction de l'endroit où elles sont déclarées. Voici les niveaux de priorité des variables dans GitLab CI/CD, du plus élevé au plus bas :

  1. Variables de projet : Les variables de projet sont définies au niveau du projet GitLab. Elles ont la priorité la plus élevée et sont accessibles à tous les pipelines et jobs du projet. Vous pouvez les définir dans les paramètres du projet via l'interface Web GitLab.

  2. Variables de groupe : Les variables de groupe sont définies au niveau du groupe GitLab qui contient le projet. Elles ont une priorité inférieure aux variables de projet. Si une variable de projet a le même nom qu'une variable de groupe, la variable de projet a la priorité.

  3. Variables de CI/CD pipeline (variables d'environnement) : Les variables d'environnement sont définies au niveau du pipeline GitLab CI/CD dans le fichier .gitlab-ci.yml. Elles ont une priorité inférieure aux variables de projet et de groupe. Vous pouvez les définir directement dans votre fichier de configuration de pipeline et elles seront disponibles uniquement pour ce pipeline spécifique.

Voici comment la priorité des variables fonctionne en pratique :

  • Si une variable est définie à la fois au niveau du projet et du groupe avec le même nom, la variable de projet a la priorité et sera utilisée dans les pipelines du projet.

  • Si une variable est définie au niveau du groupe, mais pas au niveau du projet, elle sera utilisée dans les pipelines de tous les projets appartenant à ce groupe, sauf si un projet définit sa propre variable avec le même nom.

  • Si une variable d'environnement est définie dans le fichier .gitlab-ci.yml pour un pipeline spécifique, elle a la priorité pour ce pipeline, même si une variable du même nom est définie au niveau du projet ou du groupe.

Il est important de comprendre cette hiérarchie des variables dans Gitlab CI/CD, car elle vous permet de gérer efficacement les secrets et les configurations spécifiques à différents niveaux de votre organisation GitLab. Vous pouvez utiliser cette hiérarchie pour contrôler l'accès aux informations sensibles, tout en permettant la personnalisation des pipelines au niveau du projet.

Gérer vos artefacts​

On va modifier la tache build-job pour stocker le fichier test.txt et le conserver pendant une semaine :

default:
  image: ruby:2.7.2

build-job:
  image: alpine:3.12
  stage: build
variables:
    test: "je suis un test"
  script:
    - echo "$test" > test.txt
  artifacts:
    paths:
      - test.txt
    expire_in: 1 week

...

Ce qui donne :

Uploading artifacts for successful job
Uploading artifacts...
test.txt: found 1 matching files and directories
Uploading artifacts as "archive" to coordinator... ok  id=1106004226 responseStatus=201 Created token=bezhCc6-
Cleaning up file based variables
00:01
Job succeeded

On retrouve ce fichier dans le menu ci/cd pipeline

Pipeline gitlab ci

Utilisation des groupes de ressources pour limiter la concurrence.​

Il peut arriver parfois que si deux jobs tournent en même temps cela provoque des erreurs.

Gitlab propose la notion de resource_group. Les groupes de ressources permettent de limiter la concurrence des jobs d'un CI. Il est impossible que deux jobs appartenant au même resource_group de tourner en même temps, même s'ils sont dans deux pipelines différents, ils s'excluent mutuellement.

Exemple :

deploy-to-production:
  script: deploy
  resource_group: production

Conclusion​

GitLab CI/CD offre une flexibilité exceptionnelle pour configurer et personnaliser vos pipelines CI/CD en fonction des besoins spécifiques de vos projets. Vous avez appris à définir des étapes et des jobs, à utiliser le fichier .gitlab-ci.yml pour configurer votre pipeline, et à comprendre comment GitLab CI/CD automatise le déclenchement des pipelines en réponse à des événements tels que les validations de code ou les demandes de fusion.

Il est important de noter que GitLab CI/CD est un outil en constante évolution, offrant de nouvelles fonctionnalités et des améliorations régulières. Par conséquent, il est judicieux de rester à jour avec la documentation officielle de GitLab.

D'autres billets du site​

Plus d'infos​

Sites​

Vidéos​