Volet 2 : Industrialisation des pipelines

Objectif du Volet 2

Vous avez un pipeline fonctionnel ? Maintenant, faites-le évoluer. Ce volet vous apprend à créer des pipelines maintenables, réutilisables et performants, indispensable quand vous gérez plusieurs projets ou équipes.

Prérequis

Ce volet suppose que vous maîtrisez le Volet 1 : Fondamentaux. En particulier :

Structure .gitlab-ci.yml (stages, jobs, script)
Variables et rules
Artefacts et cache

Les modules

Phase 1 : Réutilisation et factorisation

Cette phase suit une portée croissante : extends et les ancres YAML factorisent à l'intérieur d'un seul .gitlab-ci.yml, include partage entre plusieurs projets, les Components publient une brique versionnée dans le catalogue GitLab. Prenez-les dans cet ordre : include sans extends produit des fichiers partagés que personne n'ose modifier, et un composant écrit avant d'avoir factorisé localement fige des duplications à l'échelle de l'organisation.

Module	Titre	Objectif	Lab associé
V2-01	extends et anchors	Factoriser au sein d'un fichier	Lab 13
V2-02	include et templates	Partager entre projets	Lab 14
V2-03	Components & Catalog	Créer des composants réutilisables	Aucun

Phase 2 : Performance et orchestration

Ici l'objectif change : on ne cherche plus à écrire moins de YAML, on cherche à réduire la durée du pipeline et sa consommation de minutes CI. needs casse l'exécution séquentielle par stages au profit d'un graphe de dépendances, les matrices génèrent plusieurs exécutions d'un même job, les services CI montent une base de données à côté du job plutôt que dans le script. Les trois modules se combinent, un job matriciel restant soumis aux mêmes needs que les autres.

Module	Titre	Objectif	Lab associé
V2-04	DAG et parallélisme	Optimiser avec `needs`	Lab 12
V2-05	Matrices de jobs	Multiplier les exécutions	Lab 15
V2-06	Services CI et cache avancé	Bases de données, Redis en CI	Lab 12

Phase 3 : Orchestration avancée

Les trois modules répondent à une même limite : un .gitlab-ci.yml unique ne passe pas l'échelle d'un monorepo. Les pipelines parent-enfant délèguent une partie du travail à un pipeline séparé déclenché par trigger, les pipelines dynamiques génèrent le YAML enfant à l'exécution en fonction des dossiers réellement modifiés, et les déclenchements multi-projet franchissent la frontière du dépôt. Réservez cette phase aux dépôts qui hébergent plusieurs applications : sur un projet unique, elle ajoute de l'indirection sans gain.

Module	Titre	Objectif	Lab associé
V2-07	Pipelines parent-enfant	Orchestrer les monorepos	Lab 16
V2-08	Pipelines dynamiques	Générer selon le contexte	Lab 16
V2-09	Multi-projet et downstream	Déclencher d'autres projets	Aucun

Phase 4 : Workflows et fiabilité

Cette dernière phase décide quand un pipeline se déclenche et comment il se comporte quand quelque chose rate. Les workflow:rules évitent le doublon classique du pipeline de branche lancé en même temps que celui de merge request ; retry, timeout et l'idempotence des jobs séparent une vraie régression d'un échec réseau passager. Le capstone rassemble les onze modules précédents dans un pipeline unique, c'est la validation du volet.

Module	Titre	Objectif	Lab associé
V2-10	Workflows CI/CD	Patterns MR, branch, release	Lab 17
V2-11	Fiabilité des pipelines	Retry, timeouts, idempotence	Lab 18
V2-12	Capstone industrialisation	Pipeline industriel complet	Lab 19

Parcours recommandé

Les douze modules ne se lisent pas dans l'ordre par obligation. Choisissez l'onglet qui correspond au symptôme que vous constatez aujourd'hui sur vos pipelines : du YAML dupliqué entre dépôts, une durée d'exécution qui dérive, ou un dépôt qui héberge plusieurs applications. Chaque parcours tient en trois modules et donne un résultat mesurable, lignes de YAML supprimées ou minutes CI économisées, avant d'attaquer le reste du volet.

Vous copiez-collez du YAML entre projets ?

Commencer

Si aucun des trois parcours ne correspond à votre situation, ouvrez extends et anchors : c'est le seul module dont les autres dépendent réellement, et il s'applique à n'importe quel .gitlab-ci.yml existant sans rien casser. Les trois autres portes d'entrée ci-dessous répondent chacune à un besoin précis, gain de durée avec needs, découpage d'un monorepo avec les pipelines enfants, ou mutualisation entre dépôts avec include.

extends et anchors Première étape : factoriser au sein d'un fichier.

DAG et parallélisme Accélérer vos pipelines avec needs.

Pipelines parent-enfant Orchestrer les monorepos.

include et templates Partager entre projets.

Labs associés

Chaque module s'accompagne d'un lab à exécuter sur un dépôt GitLab réel : c'est là que vous voyez le pipeline s'exécuter, pas dans la page. L'onglet Fondamentaux rassemble les acquis du volet 1 dont dépendent les exercices d'industrialisation, en particulier la validation YAML avec CI Lint et le débogage d'un job resté en pending. L'onglet Industrialisation donne la correspondance module par module. Deux modules n'ont pas de lab dédié (V2-03 Components et V2-09 multi-projet) : leur mise en pratique passe par le capstone du Lab 19, qui rassemble l'ensemble du volet.

Fondamentaux
Industrialisation

Compétence préalable	Lab
Validation YAML / CI Lint	Lab 07
Débogage pending / skipped	Lab 11
Pipeline de base opérationnel	Labs 01–11

Module	Lab
V2-01	Lab 13
V2-02	Lab 14
V2-04	Lab 12
V2-05	Lab 15
V2-07 / V2-08	Lab 16
V2-10	Lab 17
V2-11	Lab 18
V2-12	Lab 19

Le volet 2 se situe entre les fondamentaux du .gitlab-ci.yml et la sécurité des pipelines. Revenez au volet 1 si rules, artifacts ou cache ne sont pas encore des réflexes : l'industrialisation multiplie ces mécanismes et une base fragile se paye au centuple. Enchaînez sur le volet 3 une fois vos pipelines factorisés, car c'est précisément la factorisation qui crée la surface d'attaque traitée là-bas, un template partagé compromis contaminant tous les projets qui l'incluent.

◀ Volet 1

Fondamentaux

Revoir les bases si nécessaire.

Volet 3 ▶

Sécurité des pipelines

Sécurité, supply chain et conformité.