Ce volet vous rend capable d’écrire et déboguer un pipeline GitLab CI/CD complet. En 15 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, 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 »À 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-5 | Pipeline, anatomie YAML, validation, runners, artifacts/cache |
| Contrôle | 6-9 | Variables, rules, déclencheurs, environnements |
| Qualité | 10 | Rapports junit, coverage |
| Débogage | 11-13 | Pending, skip, logs/retry/timeouts |
| Synthèse | 14-15 | Packaging, 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 que 30% des jobs “pending” sont des problèmes de tags. 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.
Périmètre : les 15 modules
Section intitulée « Périmètre : les 15 modules »Bases et structure (Modules 1-6)
Section intitulée « Bases et structure (Modules 1-6) »| Module | Contenu | Compétence clé |
|---|---|---|
| 1. CI/CD : les bases utiles | Concepts pipeline, stage, job | Comprendre le vocabulaire |
2. Anatomie de .gitlab-ci.yml | Structure YAML, stages, jobs, script | Écrire un pipeline minimal |
| 3. Valider son pipeline | Pipeline Editor, CI Lint, API, IDE | Détecter les erreurs YAML avant push |
| 4. Debug : lire les logs | Logs, sections, erreurs | Comprendre pourquoi un job échoue |
| 5. Runners | Executors, tags, shared/specific | Savoir où s’exécute un job |
| 6. Artifacts vs cache | Stockage, rétention, performance | Optimiser les builds |
Contrôle d’exécution (Modules 7-10)
Section intitulée « Contrôle d’exécution (Modules 7-10) »| Module | Contenu | Compétence clé |
|---|---|---|
| 7. Variables & contexte | Scopes, CI_*, protected, file | Paramétrer les jobs |
8. Conditions (rules) | if, changes, exists, when | Contrôler quand un job s’exécute |
| 9. Déclencheurs | Push, MR, tags, schedules, manual | Comprendre les sources de pipeline |
| 10. Environnements | dev/staging/prod, stop actions | Gérer les déploiements |
Qualité et rapports (Module 11)
Section intitulée « Qualité et rapports (Module 11) »| Module | Contenu | Compétence clé |
|---|---|---|
| 11. Qualité & tests | junit, coverage, artifacts reports | Exploiter les résultats de tests |
Dépannage (Modules 12-13)
Section intitulée « Dépannage (Modules 12-13) »| Module | Contenu | Compétence clé |
|---|---|---|
| 12. Dépannage “pending” | Runner absent, tags, quotas | Débloquer un job |
| 13. Dépannage “skip” | workflow:rules, rules, only/except | Comprendre pourquoi ça ne démarre pas |
Synthèse (Module 14)
Section intitulée « Synthèse (Module 14) »| Module | Contenu | Compétence clé |
|---|---|---|
| 14. Pipeline complet | Mini-capstone, checklist prod | Assembler tout ce que vous avez appris |
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 »À 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.