Ce volet vous rend capable d'écrire et déboguer un pipeline GitLab CI/CD complet. En 16 modules, vous passez de « je ne sais pas ce qu'est un stage » à « je sais structurer un pipeline propre, gérer les variables, contrôler l'exécution avec rules, publier des images et packages, activer les scanners de sécurité, et surtout déboguer quand ça ne marche pas ».
Pas de théorie abstraite : chaque concept est rattaché à un cas d'usage réel. Vous apprenez à poser les bonnes questions, utiliser les bons mots-clés YAML, et résoudre les problèmes avant qu'ils n'arrivent en production.
Pour qui ?
Section intitulée « Pour qui ? »Ce volet s'adresse à trois profils :
Le débutant motivé, Vous n'avez jamais écrit de .gitlab-ci.yml. Vous savez que GitLab peut « lancer des tests automatiquement », mais vous ne savez pas par où commencer. Vous voulez comprendre la logique avant de copier-coller des exemples.
Le dev qui subit la CI, Vous modifiez parfois le pipeline de votre projet, mais dès qu'un job reste « pending » ou « skip », vous êtes bloqué. Vous savez que le problème est « quelque part dans le YAML », mais vous ne savez pas où chercher.
L'ops qui veut structurer ses connaissances, Vous avez appris GitLab CI/CD sur le tas, en dépannant des pipelines cassés. Vous voulez combler les trous, comprendre les mécanismes sous-jacents, et avoir une méthodologie de débogage systématique.
Objectifs opérationnels
Section intitulée « Objectifs opérationnels »Ces dix objectifs sont écrits sous forme de gestes, pas de connaissances. C'est volontaire : sur un pipeline, savoir ce qu'est un stage ne sert à rien tant qu'on ne sait pas dire pourquoi le job n'a pas démarré. Les deux derniers points (déboguer « pending » et « skip ») sont ceux qui font gagner le plus de temps au quotidien, et ce sont aussi ceux qui demandent d'avoir compris tous les précédents.
À la fin de ce volet, vous serez capable de :
- Structurer un
.gitlab-ci.yml: stages, jobs, scripts, avec les bonnes pratiques. - Comprendre les runners : savoir pourquoi un job s'exécute sur telle machine, avec tels tags.
- Gérer artifacts et cache : stocker les résultats, accélérer les builds, éviter les pièges.
- Utiliser les variables : scopes, précédence, variables CI_*, secrets protégés.
- Contrôler l'exécution avec
rules: conditions if, changes, exists, when. - Configurer les déclencheurs : push, MR, tags, schedules, manual.
- Utiliser les environnements : dev, staging, prod, stop actions.
- Générer des rapports : junit, coverage, artifacts reports.
- Déboguer "pending" : identifier runner absent, tags mismatch, quotas.
- Déboguer "skip" : comprendre workflow:rules vs rules, only/except legacy.
Pourquoi ce format pédagogique ?
Section intitulée « Pourquoi ce format pédagogique ? »Partir de ce que vous connaissez déjà
Section intitulée « Partir de ce que vous connaissez déjà »Vous avez déjà vu un pipeline GitLab dans l'interface web. Vous avez vu des jobs verts, rouges, ou gris. Ce volet accroche les concepts sur ces expériences : on part de ce que vous voyez (le job bloqué) pour remonter à la cause (le runner mal taggé).
Une progression logique
Section intitulée « Une progression logique »La formation suit un chemin structuré :
| Phase | Modules | Ce que vous apprenez |
|---|---|---|
| Bases | 1-6 | Pipeline, anatomie YAML, validation, logs, runners, artifacts/cache |
| Contrôle | 7-10 | Variables, rules, déclencheurs, environnements |
| Qualité | 11 | Rapports junit, coverage |
| Débogage | 12-13 | Pending, skip |
| Synthèse | 14 | Pipeline complet |
Chaque module s'appuie sur les précédents. Vous ne verrez pas rules (module 7) avant d'avoir compris les variables (module 6).
Chaque concept = un cas de panne
Section intitulée « Chaque concept = un cas de panne »On n'apprend pas les runners « parce que c'est au programme ». On les apprend parce qu'un job "pending" vient presque toujours d'un runner absent ou d'un tags: qui ne correspond à aucun runner disponible. On n'apprend pas workflow:rules pour la culture générale, mais parce que c'est la cause des pipelines qui ne démarrent pas du tout.
Périmètre : les 16 modules
Section intitulée « Périmètre : les 16 modules »Bases et structure (Modules 1-6)
Section intitulée « Bases et structure (Modules 1-6) »Ce premier bloc construit le vocabulaire et les réflexes de vérification. Notez l'ordre : on écrit un pipeline (module 2), on apprend à le valider avant de pousser (module 3), puis à lire un échec (module 4). Beaucoup de débutants sautent les modules 3 et 4 pour aller plus vite ; ce sont pourtant eux qui évitent les allers-retours de commits « fix ci » sur la branche.
| Module | Contenu | Compétence clé | Lab associé |
|---|---|---|---|
| 1. Premiers pas avec GitLab CI/CD | Concepts pipeline, stage, job | Comprendre le vocabulaire | Aucun |
2. Écrire un fichier .gitlab-ci.yml | Structure YAML, stages, jobs, script | Écrire un pipeline minimal | Lab 01 |
| 3. Valider son pipeline | Pipeline Editor, CI Lint, API, IDE | Détecter les erreurs YAML avant push | Lab 07 |
| 4. Debug : lire les logs | Logs, sections, erreurs | Comprendre pourquoi un job échoue | Lab 02 |
| 5. Runners | Executors, tags, shared/specific | Savoir où s'exécute un job | Lab 03 |
| 6. Artefacts et cache | Stockage, rétention, performance | Optimiser les builds | Lab 04 |
Contrôle d'exécution (Modules 7-10)
Section intitulée « Contrôle d'exécution (Modules 7-10) »Ce bloc répond à une seule question : quand un job doit-il s'exécuter, et avec quelles valeurs ? Les variables (module 7) viennent avant les rules (module 8) parce qu'une condition rules:if s'écrit presque toujours en testant une variable CI_*. Sans cette base, la syntaxe des règles reste une formule qu'on recopie sans comprendre.
| Module | Contenu | Compétence clé | Lab associé |
|---|---|---|---|
| 7. Variables et secrets | Scopes, CI_*, protected, file | Paramétrer les jobs | Lab 05 |
8. Conditions (rules) | if, changes, exists, when | Contrôler quand un job s'exécute | Lab 06 |
| 9. Déclencheurs | Push, MR, tags, schedules, manual | Comprendre les sources de pipeline | Lab 08 |
| 10. Environnements | dev/staging/prod, stop actions | Gérer les déploiements | Aucun |
Qualité et rapports (Module 11)
Section intitulée « Qualité et rapports (Module 11) »Un module isolé, mais rentable : c'est celui qui fait remonter les résultats de tests dans l'interface de la merge request, au lieu de les laisser enfouis dans les logs du job. C'est la différence entre une CI que l'équipe consulte et une CI que personne ne lit.
| Module | Contenu | Compétence clé | Lab associé |
|---|---|---|---|
| 11. Rapports qualité | junit, coverage, artifacts reports | Exploiter les résultats de tests | Lab 10 |
Dépannage (Modules 12-13)
Section intitulée « Dépannage (Modules 12-13) »| Module | Contenu | Compétence clé | Lab associé |
|---|---|---|---|
| 12. Dépannage "pending" | Runner absent, tags, quotas | Débloquer un job | Lab 11 |
| 13. Dépannage "skip" | workflow:rules, rules, only/except | Comprendre pourquoi ça ne démarre pas | Lab 11 |
Synthèse (Module 14)
Section intitulée « Synthèse (Module 14) »Ce module n'apporte aucune notion nouvelle : il vous fait assembler tout le volet en un seul .gitlab-ci.yml complet, avec une checklist de mise en production. C'est le meilleur révélateur des notions comprises à moitié, et le pipeline obtenu vous servira de modèle de départ sur vos propres projets.
| Module | Contenu | Compétence clé | Lab associé |
|---|---|---|---|
| 14. Synthèse : pipeline complet | Mini-capstone, checklist prod | Assembler tout ce que vous avez appris | Aucun |
Registries et sécurité (Modules 15-16)
Section intitulée « Registries et sécurité (Modules 15-16) »Ces deux modules sortent du pipeline pour s'intéresser à ce qu'il produit et à ce qu'il laisse passer. Le module 15 couvre la construction et la publication d'images sans mode privilégié ; le module 16 branche les scanners GitLab (SAST, Secret Detection, Dependency et Container Scanning) pour que les vulnérabilités remontent dans la merge request plutôt qu'en production.
| Module | Contenu | Compétence clé | Lab associé |
|---|---|---|---|
| 15. Registries GitLab | Container Registry, Package Registry, Dependency Proxy, Buildah | Construire et publier images et packages | Lab 09 |
| 16. Scanners de sécurité | SAST, DAST, Secret Detection, Dependency/Container Scanning | Détecter les vulnérabilités dans la MR | Aucun |
Méthode de travail recommandée
Section intitulée « Méthode de travail recommandée »Rythme : 2 à 3 modules par semaine. Chaque module demande 20 à 45 minutes de lecture + pratique.
Pratique systématique : Après chaque module, créez un repo de test et écrivez le YAML correspondant. Un concept non pratiqué est un concept oublié.
Prise de notes : Gardez une « cheatsheet » personnelle avec les mots-clés YAML et les patterns que vous découvrez. Elle vous servira en dépannage.
Modules disponibles
Section intitulée « Modules disponibles »Les seize cartes ci-dessous suivent l'ordre pédagogique du volet, pas l'ordre alphabétique. Si vous démarrez de zéro, suivez-les de gauche à droite. Si vous venez chercher une réponse précise, les trois cartes de débogage (Debug : lire les logs, Debug pending, Debug skip) sont autonomes et se lisent sans le reste.
Labs associés
Section intitulée « Labs associés »Chaque lab est un exercice guidé à faire sur votre propre projet de test, après la lecture du module correspondant. Le premier onglet couvre ce volet, le second anticipe la suite du parcours : n'y allez pas tant que les labs 01 à 11 ne sont pas terminés, ils supposent acquis tout ce qui précède. Certains modules n'ont pas de lab, ce sont les modules de vocabulaire et de synthèse.
| Module | Lab |
|---|---|
2. Écrire un fichier .gitlab-ci.yml | Lab 01 |
| 3. Valider son pipeline | Lab 07 |
| 4. Debug : lire les logs | Lab 02 |
| 5. Runners | Lab 03 |
| 6. Artefacts et cache | Lab 04 |
| 7. Variables et secrets | Lab 05 |
8. Conditions (rules) | Lab 06 |
| 9. Déclencheurs | Lab 08 |
| 11. Rapports qualité | Lab 10 |
| 12. Dépannage "pending" | Lab 11 |
| 13. Dépannage "skip" | Lab 11 |
| 15. Registries GitLab | Lab 09 |
| Suite logique | Lab |
|---|---|
| Démarrer l'industrialisation (DAG + cache avancé) | Lab 12 |
Factoriser le YAML (extends, anchors) | Lab 13 |
Externaliser avec templates include | Lab 14 |
| Tester en matrice multi-versions | Lab 15 |
| Orchestration parent-enfant / dynamique | Lab 16 |
| Workflows MR/branches/tags | Lab 17 |
| Fiabilité (retry/timeout/resource_group) | Lab 18 |
| Capstone industriel | Lab 19 |
À la fin de ce volet
Section intitulée « À la fin de ce volet »Vous aurez un pipeline de référence que vous pourrez adapter à vos projets. Ce pipeline inclura :
- Une structure claire (stages logiques, jobs bien nommés)
- Des variables bien scopées (projet, groupe, pipeline)
- Des rules qui contrôlent précisément l'exécution
- Des artifacts et cache configurés pour la performance
- Une gestion des environnements (dev → staging → prod)
- Des rapports de tests intégrés
Surtout, vous aurez une méthodologie de débogage : face à un job "pending", "skip" ou "failed", vous saurez exactement où chercher.