Module 5Mettre en œuvre les outils de la chaîne DevOps
Chapitre 10 sur 11
Pipelines, stages, jobs, runners, artefacts, variables et le fichier .gitlab-ci.yml complet du projet.
Objectifs
Avec ce chapitre, tu sauras…
.gitlab-ci.yml : stages, jobs, scripts, images, règles, environnements, jobs manuels ;Leçon 1
| Intérêt du pipeline | |
|---|---|
| une séquence reproductible | le logiciel est préparé exactement de la même façon à chaque fois |
| automatiser la livraison | gagner du temps et de la fiabilité dans les déploiements |
| éliminer les erreurs manuelles | plus d'oubli d'une étape ou d'un fichier |
| des retours rapides | le développeur sait en quelques minutes si sa modification casse quelque chose |
| itérer plus vite | livrer plus souvent, en confiance |
| Étape courante | Rôle |
|---|---|
| construction (build) | installer les dépendances, compiler, construire l'image Docker |
| test | tests automatisés, analyse de syntaxe |
| qualité et sécurité | SonarQube, analyse des dépendances vulnérables |
| livraison (release) | publier l'artefact (paquet, image) dans un registre |
| déploiement | installer la version sur un environnement (recette, production) |
| validation | vérifications après déploiement, conformité |
Vidéo · À regarder
FRGitLab CI/CD expliqué simplement (Pour développeurs et DevOps)
chillotech · YouTube
Leçon 2
| Élément | Définition |
|---|---|
| pipeline | l'ensemble de l'exécution, déclenchée par un événement (push, merge request, planification, clic) ; le composant de plus haut niveau |
| stage (étape) | un groupe de jobs ; les stages s'exécutent dans l'ordre ; le stage suivant ne commence que si tous les jobs du stage précédent ont réussi |
| job (tâche) | un ensemble d'instructions (script) exécutées par un runner ; les jobs d'un même stage tournent en parallèle ; si un job échoue, le pipeline échoue (sauf allow_failure: true) |
| runner | l'application qui exécute les jobs, sur une machine ; sur gitlab.com, des runners partagés sont fournis (avec un quota de minutes de calcul) ; on peut aussi installer et enregistrer son propre runner |
Leçon 3
| Mot-clé | Rôle |
|---|---|
stages | la liste ordonnée des stages |
stage | le stage du job |
script | les commandes du job (obligatoire) ; before_script et after_script avant et après |
image | l'image Docker du job ; default: fixe une valeur par défaut pour tous les jobs |
variables | des variables pour le pipeline ou pour un job |
Leçon 4
.gitlab-ci.yml.SONAR_HOST_URL, SONAR_TOKEN, la clé de déploiement… en les cochant Masked (masqués dans les journaux) et Protected (disponibles seulement sur les branches protégées).Leçon 5
| Ce que fait ce pipeline | |
|---|---|
| sur toute branche | installation des dépendances, vérification de la syntaxe, tests unitaires avec couverture |
sur une merge request et sur main | en plus, l'analyse SonarQube ; si la porte qualité échoue, le job échoue et la merge request ne peut pas être fusionnée |
sur main | déploiement automatique en recette, puis déploiement en production manuel (bouton ▶) : c'est de la livraison continue |
1Le fichier de configuration du pipeline s'appelle…
2Les jobs d'un même stage s'exécutent…
3L'application qui exécute les jobs est…
4Un fichier produit par un job et conservé par GitLab est…
5Pour qu'un job ne s'exécute que lorsqu'on clique dessus :
6Un jeton secret se range…
7needs permet à un job de…
8En YAML, l'indentation se fait avec…
L'essentiel du chapitre
.gitlab-ci.yml à la racine du dépôt ; déclenché par les push, les merge requests, une planification ou un clic.script) ; exécutés par des runners (partagés ou propres), dans une image Docker.$CI_…, secrets masqués et protégés), tags (choix du runner), environnements.stages, stage, script, image, variables, artifacts, cache, needs, rules (when: manual), environment, allow_failure.main.| image | l'image Docker dans laquelle le job s'exécute (php:8.3-cli, node:22, composer:2) : chaque job démarre dans un environnement propre |
| artefact | un fichier produit par un job (application construite, rapport de tests, couverture) et conservé par GitLab : téléchargeable et transmis aux jobs suivants |
| cache | des fichiers réutilisés d'un pipeline à l'autre pour aller plus vite (les paquets téléchargés par Composer ou npm) |
| variables | des valeurs disponibles dans les jobs : prédéfinies ($CI_COMMIT_BRANCH, $CI_COMMIT_SHORT_SHA, $CI_DEFAULT_BRANCH) ou définies dans le fichier ou dans les paramètres du projet (les secrets, masqués et protégés) |
| tags | des étiquettes qui choisissent quel runner exécute le job (par exemple un runner avec docker ou avec accès au serveur de production) |
| environnement | une cible de déploiement (recette, production) dont GitLab garde l'historique des déploiements |
Vidéo · À regarder
FRGitLab CI/CD expliqué simplement (Pour développeurs et DevOps)
chillotech · YouTube
artifacts |
les fichiers à conserver (paths, expire_in, reports) |
cache | les fichiers à réutiliser entre pipelines |
needs | les jobs dont celui-ci dépend : il démarre dès qu'ils sont terminés, sans attendre tout le stage, et récupère leurs artefacts |
rules | quand créer le job : sur quelle branche, pour quel événement, when: manual pour un déclenchement manuel |
environment | l'environnement de déploiement (name, url) |
allow_failure | le pipeline continue même si ce job échoue |
tags | choisir le runner |
Vidéo · À regarder
FRGitLab CI/CD expliqué simplement (Pour développeurs et DevOps)
chillotech · YouTube
Vidéo · À regarder
FRGitLab CI/CD expliqué simplement (Pour développeurs et DevOps)
chillotech · YouTube
Les variables prédéfinies utiles
Vidéo · À regarder
FRGitLab CI/CD expliqué simplement (Pour développeurs et DevOps)
chillotech · YouTube
Ce que tu vas voir (11 min) : les chapitres « Présentation de GitLab CI ». Le formateur présente GitLab CI : à quoi sert l'outil, le fichier de configuration et les runners.
Pipeline (déclenché par un push)
┌──────────────┐ ┌──────────────────────────┐ ┌──────────────────────────────┐
│ 1. build │ │ 2. test │ │ 3. deploy │
│ ┌────────┐ │──► │ ┌───────────┐ ┌───────┐ │──► │ ┌──────────┐ ┌────────────┐ │
│ │ build │ │ │ │ unitaires │ │ cover-│ │ │ │ recette │ │ production │ │
│ └────────┘ │ │ └───────────┘ │ age │ │ │ └──────────┘ │ (manuel ▶) │ │
│ │ │ en parallèle └───────┘ │ │ └────────────┘ │
└──────────────┘ └──────────────────────────┘ └──────────────────────────────┘
les stages s'exécutent l'un après l'autre ; les jobs d'un même stage, en parallèleLe fichier est écrit en YAML : une syntaxe de configuration où la structure est donnée par l'indentation (des espaces, jamais de tabulations) et où les listes commencent par un tiret.
stages: # l'ordre des stages
- build
- test
- deploy
construire: # le nom du job (libre)
stage: build
script: # les commandes exécutées par le runner
- echo "Construction de l'application…"
tests-unitaires:
stage: test
script:
- echo "Exécution des tests unitaires…"
couverture: # même stage que tests-unitaires : les deux tournent en parallèle
stage: test
script:
- echo "Calcul de la couverture…"
deployer:
stage: deploy
script:
- echo "Déploiement…"Mettre en place le pipeline
stages:
- build
- test
- quality
- deploy
variables:
COMPOSER_CACHE_DIR: "$CI_PROJECT_DIR/.composer-cache"
default:
image: php:8.3-cli
dependances:
stage: build
image: composer:2
script:
- composer install --no-interaction --prefer-dist --no-progress
cache: # réutiliser les paquets téléchargés
key:
files:
- composer.lock
paths:
- .composer-cache/
artifacts: # transmettre vendor/ aux jobs suivants
paths:
- vendor/
expire_in: 1 hour
syntaxe-php:
stage: test
script:
- find app tests -name "*.php" -print0 | xargs -0 -n1 php -l
tests-unitaires:
stage: test
needs: ["dependances"]
before_script:
- pecl install pcov && docker-php-ext-enable pcov # extension de couverture
script:
- vendor/bin/phpunit --coverage-clover coverage.xml --log-junit rapport-tests.xml
artifacts:
when: always
paths:
- coverage.xml
reports:
junit: rapport-tests.xml # résultats affichés dans la merge request
sonarqube:
stage: quality
image:
name: sonarsource/sonar-scanner-cli:latest
entrypoint: [""]
needs: ["tests-unitaires"] # récupère coverage.xml
variables:
GIT_DEPTH: "0" # tout l'historique, pour détecter le nouveau code
script:
- sonar-scanner -Dsonar.qualitygate.wait=true # échoue si la porte qualité est rouge
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
deployer-recette:
stage: deploy
image: alpine:3.20
script:
- echo "Déploiement de $CI_COMMIT_SHORT_SHA sur la recette"
environment:
name: recette
url: https://recette.kitab.example
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
deployer-production:
stage: deploy
image: alpine:3.20
script:
- echo "Déploiement de $CI_COMMIT_SHORT_SHA en production"
environment:
name: production
url: https://kitab.example
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
when: manual # livraison continue : un humain cliqueLes commandes echo des jobs de déploiement remplacent ici les vraies commandes, qui dépendent de l'hébergement : copie des fichiers par SSH (rsync) et lancement des migrations, construction et envoi d'une image Docker, ou déploiement sur Kubernetes. La clé SSH ou les identifiants sont alors fournis par des variables protégées.
Dans le dépôt GitLab de Kitab : (1) crée le .gitlab-ci.yml avec l'éditeur de pipeline, en commençant par le premier pipeline à trois stages, puis enrichis-le ; (2) ajoute au moins un test PHPUnit qui passe ; (3) ajoute les variables SONAR_HOST_URL et SONAR_TOKEN (masquées) et connecte le job SonarQube à ton serveur (ou à SonarQube Cloud) ; (4) active « Pipelines must succeed » ; (5) ouvre une merge request avec un test volontairement faux, observe l'échec, corrige ; (6) fusionne et déclenche le déploiement manuel ; (7) fais une capture du graphe du pipeline pour ton rapport.
Pour le pipeline complet de Kitab (section 5), réponds : (1) que se passe-t-il quand un développeur pousse sur la branche KIT-12-filtre-prix sans ouvrir de merge request ? (2) Et quand il ouvre une merge request ? (3) Que se passe-t-il si un test unitaire échoue ? (4) Pourquoi sonarqube a-t-il besoin de tests-unitaires ? (5) Comment passer de la livraison continue au déploiement continu ?
Trouve les quatre erreurs de ce fichier :
stages:
- build
- test
build:
stage: compile
script:
- npm ci
tests:
stage: test
script:
- npm test
deploy:
stage: deploy
script:
- echo "SONAR_TOKEN=sqa_8f2c91d7…" && ./deployer.shLe résumé écrit le nom du fichier de plusieurs façons (« gitlab-ci.yml », « .gtilab-ci.yml ») : le seul nom reconnu par GitLab est .gitlab-ci.yml, avec le point au début, à la racine du dépôt. Il dit aussi que les artefacts sont « créés par GitLab après la fin d'un pipeline » : ils sont produits par les jobs (pendant le pipeline) et conservés par GitLab, qui les transmet aux jobs suivants et permet de les télécharger.
Ce que tu vas voir (15 min) : les chapitres « Liste des jobs », « Liste des étapes », « Définir une liste des étapes ». Il détaille les jobs et les étapes (stages), puis définit la liste des étapes du pipeline.
L'erreur la plus fréquente est l'indentation : une ligne décalée d'un espace change toute la structure. Avant de pousser, utilise l'éditeur de pipeline de GitLab (Build → Pipeline editor) : il valide le fichier en direct et affiche une visualisation du pipeline. Et n'écris jamais un mot de passe ou un jeton dans .gitlab-ci.yml : il est versionné et lisible par tous les membres du projet.
Ce que tu vas voir (14 min) : les chapitres « Définir l'image à utiliser », « Les artifacts entre les stages ». Il complète le fichier .gitlab-ci.yml : l'image Docker à utiliser et les artifacts pour partager des fichiers entre les stages.
Dans une merge request, le résultat du pipeline s'affiche directement : on peut interdire la fusion tant que le pipeline n'a pas réussi (Settings → Merge requests → Pipelines must succeed).
Ce que tu vas voir (7 min) : les chapitres « Premier pipeline ». Il crée son premier pipeline et le suit dans l'interface de GitLab.
$CI_COMMIT_BRANCH (la branche), $CI_DEFAULT_BRANCH (en général main), $CI_COMMIT_SHORT_SHA (l'identifiant court du commit), $CI_PIPELINE_SOURCE (push, merge_request_event, schedule, web), $CI_PROJECT_DIR (le dossier du projet dans le runner), $CI_COMMIT_TAG (le tag de version, s'il y en a un). Elles permettent d'écrire des règles précises sans rien coder en dur.
Ce que tu vas voir (6 min) : les chapitres « De la CI vers la CD », « Les étapes de déploiement ». Il passe de l'intégration continue au déploiement continu et présente les étapes de déploiement.
Écris le fichier .gitlab-ci.yml d'un projet front-end Vue (module M201) : stage build (image node:22, npm ci puis npm run build, artefact dist/ conservé une semaine, cache de node_modules/ avec la clé package-lock.json) ; stage test (npm run lint et npm test en parallèle) ; stage deploy (un job manuel, seulement sur main, environnement production).