Exercice 06 : Projet Capstone - Créer Son Premier Pipeline GitLab CI

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Écrire un fichier .gitlab-ci.yml complet avec 3 stages
✅ Définir des jobs dans chaque stage avec script:, image:, only:
✅ Utiliser les runners partagés de GitLab.com
✅ Construire et tester une application dans un pipeline GitLab CI

Durée estimée : 40 minutes

Difficulté : ⭐⭐⭐☆☆ (Intermédiaire)

Prérequis :

Un compte GitLab.com (gratuit)
Module GitLab CI Débutant complété
Notions Docker de base

📖 Contexte

Votre entreprise migre de GitHub vers GitLab. Vous devez créer le premier pipeline CI/CD de l'équipe sur GitLab.com, en utilisant les runners partagés fournis par GitLab. Le pipeline doit construire, tester, et préparer le déploiement d'une application Node.js.

📋 Énoncé

Créez un pipeline GitLab CI avec 3 stages (build, test, package) pour une application Node.js, utilisant les runners partagés de GitLab.com.

🧭 Déroulement de l'exercice

Tâche 1 : Créer le projet GitLab

Créez un nouveau projet devops-gitlab-demo sur GitLab.com. Initialisez-le avec README.md. Clonez-le en local et ajoutez les fichiers de l'application : server.js, server.test.js, package.json.

Indice : Sur GitLab, "New project" → "Create blank project". Activez l'option "Initialize repository with a README". Ensuite git clone <URL>.

Vérification : Le projet existe sur GitLab.com avec le code de l'application. L'onglet "CI/CD" est visible dans la sidebar gauche.

Tâche 2 : Créer la structure .gitlab-ci.yml

À la racine du projet, créez .gitlab-ci.yml. Définissez :

Trois stages dans l'ordre : build, test, package
Une image Docker par défaut : node:20-alpine
Un cache global sur node_modules/ basé sur le hash de package-lock.json

Indice :
`yaml
stages:
- build
- test
- package

default:
image: node:20-alpine

cache:
key:
files:
- package-lock.json
paths:
- node_modules/
`
La clé default: définit des configurations partagées par tous les jobs.

Vérification : gitlab-ci-lint (outil en ligne ou CI Lint dans GitLab) valide la syntaxe du fichier.

Tâche 3 : Ajouter le job d'installation (stage build)

Créez un job install-dependencies dans le stage build qui exécute npm ci. Ce job produit node_modules/ qui sera mis en cache pour les jobs suivants.

Indice : Le cache GitLab est restauré au début de chaque job et uploadé à la fin. Contrairement à GitHub Actions, le cache GitLab est automatiquement partagé entre jobs du même pipeline si la clé est identique.

Vérification : Le job install-dependencies apparaît dans le pipeline avec statut vert.

Tâche 4 : Ajouter les jobs de test et de lint

Créez deux jobs dans le stage test :

run-tests : exécute npm test et génère un rapport JUnit (jest --reporters=jest-junit)
run-lint : exécute npm run lint (avec ESLint)

Pour run-tests, configurez la section artifacts:reports:junit pour que GitLab affiche les résultats des tests directement dans la merge request.

Indice : Les rapports JUnit dans GitLab :
`yaml
artifacts:
reports:
junit: junit.xml
when: always
expire_in: 1 week
`
when: always publie l'artefact même si les tests échouent.

Vérification : Dans le pipeline GitLab, le job run-tests affiche un badge "X tests passed". Dans une MR, les résultats des tests apparaissent.

Tâche 5 : Ajouter le job de package Docker

Créez un job build-docker dans le stage package. Ce job utilise l'image docker:26 avec le service docker:26-dind pour construire l'image Docker. Il ne s'exécute que sur la branche main.

Indice : GitLab utilise Docker-in-Docker (dind) pour construire des images :
`yaml
build-docker:
stage: package
image: docker:26
services:
- docker:26-dind
variables:
DOCKER_TLS_CERTDIR: "/certs"
only:
- main
script:
- docker build -t $CI_PROJECT_NAME:$CI_COMMIT_SHORT_SHA .
`
$CI_PROJECT_NAME et $CI_COMMIT_SHORT_SHA sont des variables prédéfinies par GitLab.

Vérification : Sur un push vers main, le stage package s'exécute et construit l'image Docker.

Tâche 6 : Analyser les variables prédéfinies GitLab

Ajoutez un job debug-env (stage build) qui affiche les principales variables prédéfinies GitLab : $CI_COMMIT_BRANCH, $CI_COMMIT_SHORT_SHA, $CI_PROJECT_NAME, $CI_PIPELINE_URL, $GITLAB_USER_NAME.

Indice : GitLab injecte automatiquement des dizaines de variables dans chaque job. Ces variables permettent aux scripts de connaître le contexte (branche, commit, projet, utilisateur...).

Vérification : Les logs du job debug-env affichent les valeurs des 5 variables.

🗂️ Mini-Projet : Pipeline GitLab CI complet

Pipeline visualisé dans GitLab :

Stage: build    →  Stage: test      →  Stage: package
─────────────      ────────────────    ───────────────
install-deps       run-tests           build-docker
debug-env          run-lint            (main seulement)

Checkpoints de validation :

.gitlab-ci.yml passe le linter GitLab CI sans erreur
Le pipeline se déclenche automatiquement sur git push
Les jobs install-deps et debug-env s'exécutent en parallèle dans le stage build
Le rapport JUnit est visible dans le pipeline GitLab
Le job build-docker ne s'exécute que sur main
Les variables prédéfinies sont correctement affichées

Exercice 06 : Projet Capstone - Créer Son Premier Pipeline GitLab CI

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Écrire un fichier .gitlab-ci.yml complet avec 3 stages
✅ Définir des jobs dans chaque stage avec script:, image:, only:
✅ Utiliser les runners partagés de GitLab.com
✅ Construire et tester une application dans un pipeline GitLab CI

Durée estimée : 40 minutes

Difficulté : ⭐⭐⭐☆☆ (Intermédiaire)

Prérequis :

Un compte GitLab.com (gratuit)
Module GitLab CI Débutant complété
Notions Docker de base

📖 Contexte

📋 Énoncé

Créez un pipeline GitLab CI avec 3 stages (build, test, package) pour une application Node.js, utilisant les runners partagés de GitLab.com.

🧭 Déroulement de l'exercice

Tâche 1 : Créer le projet GitLab

Indice : Sur GitLab, "New project" → "Create blank project". Activez l'option "Initialize repository with a README". Ensuite git clone <URL>.

Vérification : Le projet existe sur GitLab.com avec le code de l'application. L'onglet "CI/CD" est visible dans la sidebar gauche.

Tâche 2 : Créer la structure .gitlab-ci.yml

À la racine du projet, créez .gitlab-ci.yml. Définissez :

Trois stages dans l'ordre : build, test, package
Une image Docker par défaut : node:20-alpine
Un cache global sur node_modules/ basé sur le hash de package-lock.json

Indice :
`yaml
stages:
- build
- test
- package

default:
image: node:20-alpine

cache:
key:
files:
- package-lock.json
paths:
- node_modules/
`
La clé default: définit des configurations partagées par tous les jobs.

Vérification : gitlab-ci-lint (outil en ligne ou CI Lint dans GitLab) valide la syntaxe du fichier.

Tâche 3 : Ajouter le job d'installation (stage build)

Créez un job install-dependencies dans le stage build qui exécute npm ci. Ce job produit node_modules/ qui sera mis en cache pour les jobs suivants.

Indice : Le cache GitLab est restauré au début de chaque job et uploadé à la fin. Contrairement à GitHub Actions, le cache GitLab est automatiquement partagé entre jobs du même pipeline si la clé est identique.

Vérification : Le job install-dependencies apparaît dans le pipeline avec statut vert.

Tâche 4 : Ajouter les jobs de test et de lint

Créez deux jobs dans le stage test :

run-tests : exécute npm test et génère un rapport JUnit (jest --reporters=jest-junit)
run-lint : exécute npm run lint (avec ESLint)

Pour run-tests, configurez la section artifacts:reports:junit pour que GitLab affiche les résultats des tests directement dans la merge request.

Indice : Les rapports JUnit dans GitLab :
`yaml
artifacts:
reports:
junit: junit.xml
when: always
expire_in: 1 week
`
when: always publie l'artefact même si les tests échouent.

Vérification : Dans le pipeline GitLab, le job run-tests affiche un badge "X tests passed". Dans une MR, les résultats des tests apparaissent.

Tâche 5 : Ajouter le job de package Docker

Créez un job build-docker dans le stage package. Ce job utilise l'image docker:26 avec le service docker:26-dind pour construire l'image Docker. Il ne s'exécute que sur la branche main.

Indice : GitLab utilise Docker-in-Docker (dind) pour construire des images :
`yaml
build-docker:
stage: package
image: docker:26
services:
- docker:26-dind
variables:
DOCKER_TLS_CERTDIR: "/certs"
only:
- main
script:
- docker build -t $CI_PROJECT_NAME:$CI_COMMIT_SHORT_SHA .
`
$CI_PROJECT_NAME et $CI_COMMIT_SHORT_SHA sont des variables prédéfinies par GitLab.

Vérification : Sur un push vers main, le stage package s'exécute et construit l'image Docker.

Tâche 6 : Analyser les variables prédéfinies GitLab

Indice : GitLab injecte automatiquement des dizaines de variables dans chaque job. Ces variables permettent aux scripts de connaître le contexte (branche, commit, projet, utilisateur...).

Vérification : Les logs du job debug-env affichent les valeurs des 5 variables.

🗂️ Mini-Projet : Pipeline GitLab CI complet

Pipeline visualisé dans GitLab :

Stage: build    →  Stage: test      →  Stage: package
─────────────      ────────────────    ───────────────
install-deps       run-tests           build-docker
debug-env          run-lint            (main seulement)

Checkpoints de validation :

.gitlab-ci.yml passe le linter GitLab CI sans erreur
Le pipeline se déclenche automatiquement sur git push
Les jobs install-deps et debug-env s'exécutent en parallèle dans le stage build
Le rapport JUnit est visible dans le pipeline GitLab
Le job build-docker ne s'exécute que sur main
Les variables prédéfinies sont correctement affichées