Premiers pas avec GitLab CI/CD

GitLab CI/CD automatise les tâches répétitives de votre projet : compiler le code, lancer les tests, vérifier la qualité, déployer l’application. Vous écrivez un fichier de configuration, et GitLab fait le reste à chaque modification de code.

Ce que vous allez apprendre

À la fin de ce module, vous saurez :

Comprendre ce qu’est GitLab CI/CD : l’outil d’automatisation intégré à GitLab
Connaître les 4 concepts clés : pipeline, stage, job, runner
Identifier le fichier .gitlab-ci.yml : où le placer, ce qu’il contient
Visualiser un pipeline : naviguer dans l’interface GitLab
Lire les logs d’un job : comprendre ce qui s’est passé

C’est quoi GitLab CI/CD ?

CI signifie Continuous Integration (Intégration Continue) : à chaque commit, le code est automatiquement compilé et testé. Si quelque chose casse, vous le savez immédiatement.

CD signifie Continuous Delivery/Deployment (Livraison/Déploiement Continu) : le code validé est automatiquement préparé (ou déployé) vers un environnement.

GitLab CI/CD est directement intégré à GitLab. Pas besoin d’installer Jenkins, CircleCI ou autre outil externe. Tout se configure dans votre repository.

Pourquoi l’utiliser ?

Imaginez votre workflow actuel sans CI/CD :

Vous codez une fonctionnalité
Vous lancez les tests… manuellement (ou vous oubliez)
Vous envoyez le code sur le serveur… via FTP ou SSH
Un bug en production ? Vous ne savez pas quel commit l’a introduit

Maintenant, avec GitLab CI/CD :

Vous codez une fonctionnalité
Vous faites un git push
Automatiquement : compilation, tests, analyse de code, déploiement
Si quelque chose échoue, vous recevez une alerte avec le détail

Sans CI/CD	Avec GitLab CI/CD
Tests oubliés	Tests à chaque commit
Déploiement manuel risqué	Déploiement automatisé
”Ça marche sur ma machine”	Environnement reproductible
Feedback après des heures	Feedback en quelques minutes

Comment ça marche ?

Le principe est simple :

Vous créez un fichier .gitlab-ci.yml

Ce fichier, placé à la racine de votre projet, décrit les tâches à automatiser.
Vous poussez votre code

git push envoie votre code sur GitLab.
GitLab lit le fichier et crée un pipeline

Un pipeline, c’est l’ensemble des tâches à exécuter pour ce commit.
Les tâches s’exécutent sur des runners

Des machines (fournies par GitLab ou les vôtres) exécutent les commandes.
Vous voyez le résultat

Vert = tout va bien. Rouge = quelque chose a échoué. Les logs détaillent ce qui s’est passé.

Les 4 concepts à retenir

GitLab CI/CD repose sur 4 notions fondamentales. Une fois que vous les comprenez, tout le reste devient logique.

1. Le Pipeline

Un pipeline représente l’ensemble du workflow automatisé. C’est le “grand tout” qui se déclenche quand vous poussez du code.

Analogie : le pipeline, c’est comme une chaîne de montage automobile. La voiture (votre code) passe par différentes stations (étapes) avant d’être prête.

Un pipeline est créé à chaque git push
Il peut être déclenché par d’autres événements (merge request, planning, bouton manuel)
Il a un statut : en cours, réussi, échoué, annulé

2. Les Stages (étapes)

Les stages sont les grandes étapes du pipeline. Ils s’exécutent dans l’ordre, l’un après l’autre.

Analogie : dans la chaîne de montage, on assemble d’abord le châssis, puis on installe le moteur, puis on peint. Impossible de peindre avant d’avoir le châssis.

stages:
  - build      # Étape 1 : compiler le code
  - test       # Étape 2 : lancer les tests (après build)
  - deploy     # Étape 3 : déployer (après test)

Règle importante : si un stage échoue, les stages suivants ne s’exécutent pas. Logique : à quoi bon déployer du code qui ne compile pas ?

3. Les Jobs (tâches)

Un job est une tâche unitaire à l’intérieur d’un stage. C’est la brique de base, celle où vous écrivez vos commandes.

Analogie : dans la station “installation moteur”, il y a plusieurs postes de travail : un pour fixer le moteur, un pour brancher les câbles, un pour vérifier le niveau d’huile. Tous peuvent travailler en même temps.

test-unitaires:
  stage: test
  script:
    - npm test

test-integration:
  stage: test
  script:
    - npm run test:integration

Point clé : les jobs d’un même stage s’exécutent en parallèle. Dans l’exemple, les tests unitaires et d’intégration tournent simultanément.

4. Les Runners (exécuteurs)

Un runner est la machine qui exécute réellement les jobs. Sans runner, votre pipeline reste en attente.

Analogie : les runners sont les ouvriers de la chaîne de montage. GitLab est le chef d’équipe qui distribue le travail, mais ce sont les runners qui font le job.

Type	Description	Pour qui ?
Shared runners	Fournis par GitLab.com, partagés entre tous les utilisateurs	Débutants, projets standards
Project runners	Installés par vous, dédiés à votre projet	Besoins spécifiques, performance

Pour l’instant, vous utiliserez les shared runners de GitLab. Ils sont disponibles immédiatement, sans configuration.

Vue d’ensemble : comment tout s’articule

Architecture GitLab CI/CD : pipeline contenant 3 stages (build, test, deploy) avec leurs jobs, exécutés par des runners

Lecture du schéma :

Le pipeline contient 3 stages qui s’enchaînent de gauche à droite
Le stage “test” contient 2 jobs (test + lint) qui tournent en parallèle
Si le stage “build” échoue, les stages “test” et “deploy” ne s’exécutent pas
Les runners exécutent chaque job dans un environnement isolé

Le fichier `.gitlab-ci.yml`

Toute la configuration se fait dans un fichier nommé .gitlab-ci.yml placé à la racine de votre repository Git.

Un exemple minimal

# Définir les étapes (dans l'ordre)
stages:
  - build
  - test

# Premier job : compiler
build:
  stage: build
  script:
    - echo "Compilation du code..."
    - echo "Terminé !"

# Deuxième job : tester
test:
  stage: test
  script:
    - echo "Lancement des tests..."
    - echo "Tous les tests passent !"

Explications :

stages: définit l’ordre des étapes
Chaque job a un nom (build, test)
stage: indique à quelle étape appartient le job
script: contient les commandes à exécuter

Anatomie d’un job complet

mon-job:
  stage: test                    # Étape à laquelle appartient le job
  image: node:18                 # Image Docker utilisée (environnement)
  before_script:                 # Commandes AVANT le script principal
    - npm install
  script:                        # Commandes principales (OBLIGATOIRE)
    - npm test
  after_script:                  # Commandes APRÈS (même si échec)
    - echo "Nettoyage..."
  artifacts:                     # Fichiers à conserver après le job
    paths:
      - coverage/

Seul script: est obligatoire. Tout le reste est optionnel.

Variables prédéfinies utiles

GitLab met à disposition des variables dans chaque job. Les plus courantes :

Variable	Description	Exemple
`CI_COMMIT_BRANCH`	Nom de la branche	`main`, `feature/login`
`CI_COMMIT_SHORT_SHA`	Hash court du commit	`a1b2c3d4`
`CI_PROJECT_NAME`	Nom du projet	`mon-app`
`CI_PIPELINE_SOURCE`	Déclencheur du pipeline	`push`, `merge_request_event`

build:
  script:
    - echo "Build du commit $CI_COMMIT_SHORT_SHA sur la branche $CI_COMMIT_BRANCH"

Visualiser vos pipelines

Dans GitLab, cliquez sur Build > Pipelines dans la barre latérale pour voir :

La liste de tous vos pipelines
Le graphe visuel des stages et jobs
Le statut de chaque job (vert/rouge/orange)
Les logs détaillés de chaque job

Graphe d'un pipeline GitLab - vue des stages et jobs

Le graphe montre les stages (colonnes) et les jobs (cases). Ici, le stage build s’est terminé avec succès (vert), puis le stage test s’exécute. Les jobs d’un même stage tournent en parallèle.

Cliquez sur un job pour voir ses logs en temps réel pendant l’exécution :

Logs d'un job GitLab CI en cours d'exécution

Les logs affichent chaque commande exécutée et sa sortie. Remarquez les variables CI ($CI_COMMIT_BRANCH, $CI_COMMIT_SHORT_SHA) résolues avec leurs valeurs réelles.

À retenir

Concept	Définition	Analogie
Pipeline	Workflow complet déclenché par un événement	Chaîne de montage
Stage	Étape du pipeline (s’enchaînent dans l’ordre)	Station de montage
Job	Tâche unitaire avec des commandes (parallèles dans un stage)	Poste de travail
Runner	Machine qui exécute les jobs	Ouvrier
`.gitlab-ci.yml`	Fichier de configuration à la racine	Plan de montage

Contrôle des connaissances

Testez vos connaissances sur les fondamentaux des pipelines GitLab CI/CD.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

5 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

Prochaines étapes

Vous avez compris les bases. Passez à la pratique :

Créer votre premier pipeline Écrire un .gitlab-ci.yml fonctionnel de A à Z.

Runners Comprendre où s'exécutent vos jobs.

Premiers pas avec GitLab CI/CD

Ce que vous allez apprendre

C’est quoi GitLab CI/CD ?

Pourquoi l’utiliser ?

Comment ça marche ?

Les 4 concepts à retenir

1. Le Pipeline

2. Les Stages (étapes)

3. Les Jobs (tâches)

4. Les Runners (exécuteurs)

Vue d’ensemble : comment tout s’articule

Le fichier `.gitlab-ci.yml`

Un exemple minimal

Anatomie d’un job complet

Variables prédéfinies utiles

Visualiser vos pipelines

À retenir

Contrôle des connaissances

Contrôle de connaissances

Informations

Vérification

Profil de compétences

Quoi faire maintenant

Prochaines étapes

Premiers pas avec GitLab CI/CD

Ce que vous allez apprendre

C’est quoi GitLab CI/CD ?

Pourquoi l’utiliser ?

Comment ça marche ?

Les 4 concepts à retenir

1. Le Pipeline

2. Les Stages (étapes)

3. Les Jobs (tâches)

4. Les Runners (exécuteurs)

Vue d’ensemble : comment tout s’articule

Le fichier .gitlab-ci.yml

Un exemple minimal

Anatomie d’un job complet

Variables prédéfinies utiles

Visualiser vos pipelines

À retenir

Contrôle des connaissances

Contrôle de connaissances

Informations

Profil de compétences

Quoi faire maintenant

Prochaines étapes

Le fichier `.gitlab-ci.yml`