Lab 12 — Accélérer le pipeline

Un pipeline lent finit par coûter cher : attente développeur, review ralentie, files runners saturées. Dans ce lab, vous optimisez les points qui apportent le plus de gains sans complexifier inutilement le YAML : cache bien clés, images allégées et parallélisme contrôlé.

Ce que vous allez apprendre

Choisir une clé de cache stable et pertinente
Éviter les caches inutilisables ($CI_COMMIT_SHA)
Utiliser needs pour lancer des jobs en parallèle
Mesurer l’impact réel des optimisations

Dans quel contexte ?

Les pipelines lents sont un problème de productivité avant d’être un problème technique. Si chaque push met 8 minutes, les développeurs poussent moins souvent et accumulent des changements plus gros, ce qui augmente le risque de conflit et d’erreur.

Ce lab répond à des cas fréquents :

cache jamais réutilisé à cause d’une clé trop spécifique
jobs indépendants bloqués par la logique de stage séquentielle
images trop lourdes téléchargées à chaque run

Prérequis

Lab 11 — Débugger un job bloqué terminé
Avoir lu DAG et parallélisme et Artifacts et cache

Point de départ

Basculez sur la branche du lab
Fenêtre de terminal
```
cd pipeline-craft
git checkout starter/lab-12
```
Lancez un run de référence
Fenêtre de terminal
```
git push origin starter/lab-12
```
Notez la durée du pipeline

Cette valeur sert de baseline avant optimisation.

Le problème

La lenteur vient souvent de trois causes combinées :

cache inexploitable
exécution trop séquentielle
images ou builds non optimisés

Vous allez corriger ces trois zones sans rendre le pipeline illisible.

L’exercice

Étape 1 — Corriger la stratégie de cache

Remplacez une clé instable par key.files

Mauvais exemple :

cache:
  key: $CI_COMMIT_SHA

Bon exemple :

cache:
  key:
    files:
      - requirements-dev.txt
  paths:
    - .pip-cache/

Vérifiez sur deux runs successifs

Le second run doit restaurer le cache.

Étape 2 — Paralléliser avec `needs`

Identifiez les jobs indépendants

ruff-lint et pytest peuvent démarrer sans dépendance forte l’un envers l’autre.
Ajoutez des needs explicites si nécessaire
```
pytest:
  stage: test
  needs: []
```
Cette approche active un comportement DAG et réduit l’attente artificielle liée aux stages.

Étape 3 — Vérifier les images utilisées

Confirmez l’usage de variantes allégées (python:3.12-slim)
Gardez docker:27 uniquement pour les jobs qui en ont besoin

Chaque job doit utiliser l’image minimale adaptée à son besoin.

Étape 4 — Mesurer le gain

Poussez votre optimisation

git add .gitlab-ci.yml
git commit -m "ci: speed up pipeline with cache and dag"
git push origin starter/lab-12

Comparez la durée avec la baseline

Vous devez observer une réduction tangible dès le second run optimisé.

Vérification

Le cache est restauré sur un run suivant
Les jobs indépendants ne s’attendent plus inutilement
Le pipeline total est sensiblement plus court
Le YAML reste lisible et maintenable

Pièges fréquents

Un pipeline très optimisé mais illisible devient vite un problème de maintenance. Cherchez un équilibre entre performance et clarté.

Autre piège : annoncer un gain après un seul run. Le premier run sert souvent à alimenter le cache. Mesurez au minimum sur deux à trois exécutions comparables.

À retenir

Une bonne clé de cache change quand les dépendances changent, pas à chaque commit
Le DAG (needs) réduit l’attente artificielle des stages
Les images allégées accélèrent le pull et donc le pipeline
Mesurer avant/après est indispensable pour valider une optimisation

Prochaines étapes

Lab 13 — DRY : extends et anchors Réduire la duplication YAML proprement

Guide : DAG et parallélisme Approfondir le modèle d'exécution GitLab CI

Guide : cache avancé Aller plus loin sur les stratégies de cache