Le problème avec l'apprentissage "théorique" de la CI/CD
Quand j'ai commencé à apprendre GitLab CI/CD dans le cadre de mon TP en BUT Réseaux & Télécoms, j'ai fait comme tout le monde : j'ai lu la documentation officielle, regardé quelques tutoriels YouTube, et copié-collé des exemples.
Résultat ? Rien ne fonctionnait vraiment. Ou plutôt, ça fonctionnait… mais je ne comprenais pas pourquoi.
- Pourquoi ce job reste en "pending" pendant 10 minutes ?
- C'est quoi la différence entre un
stageet unjobconcrètement ? - Pourquoi mon image Docker ne se build pas alors que le YAML est valide ?
- Comment on sécurise une pipeline ? Est-ce qu'on peut juste "build et push" sans vérifier quoi que ce soit ?
La doc GitLab est excellente… pour quelqu'un qui sait déjà ce qu'il cherche. Mais quand tu débutes, tu as besoin de casser, réparer, comprendre.
C'est exactement pour ça que j'ai créé GitLab CI Learning.
L'idée : un "bac à sable" pédagogique
Au lieu de partir sur un vrai projet avec 50 fichiers et des dépendances complexes, j'ai voulu créer un repo volontairement simple, avec :
Un Dockerfile minimal (une app Python/Flask basique)
Une pipeline .gitlab-ci.yml progressive (du plus simple au plus complet)
Des étapes claires : compliance, build, security
Des commentaires explicatifs dans le code
Des erreurs documentées (celles que j'ai réellement rencontrées)
Le principe ? Apprendre par la pratique, pas juste en lisant.
Les objectifs concrets de ce repo
Objectif 1 : Comprendre la structure d'une pipeline
Avant de faire du "DevSecOps avancé", il faut maîtriser les bases :
- Pipeline = l'ensemble du processus CI/CD
- Stages = les grandes étapes (basic, build, test, deploy…)
- Jobs = les tâches concrètes à l'intérieur de chaque stage
Dans mon projet, je pars d'une pipeline ultra-simple :
stages:
- basic
basic:
stage: basic
script:
- echo "Pipeline fonctionnelle !"
Puis j'ajoute progressivement de la complexité.
Objectif 2 : Savoir pourquoi une pipeline "casse"
Les erreurs les plus frustrantes en CI/CD ? Celles qui ne sont pas dans ton code, mais dans l'environnement :
- Job bloqué en "pending" → problème de runner
- "Image not found" → mauvaise configuration Docker
- "Permission denied" → auth registry ratée
- YAML valide mais pipeline inutile → logique métier absente
Mon repo documente toutes ces erreurs réelles que j'ai rencontrées.
Objectif 3 : Construire une CI "professionnelle"
Une bonne pipeline ne fait pas que "build". Elle doit :
- Vérifier la qualité (lint du Dockerfile avec Hadolint)
- Construire l'artefact (image Docker avec Kaniko)
- Scanner la sécurité (détection vulnérabilités avec Trivy)
Mon projet implémente ces 3 étapes, avec des explications sur pourquoi chacune est importante.
Ce que tu vas découvrir dans cette série d'articles
Je vais publier 7 articles qui détaillent tout le processus, dans l'ordre :
- Article 1 (celui-ci) → Pourquoi ce projet existe
- Article 2 → Pipeline, stages, jobs : comprendre l'exécution réelle
- Article 3 → Ma première pipeline fonctionnelle (et pourquoi elle cassait)
- Article 4 → Ajouter une étape "compliance" avec Hadolint
- Article 5 → Build d'image Docker avec Kaniko (sans Docker-in-Docker)
- Article 6 → Scanner l'image avec Trivy (security)
- Article 7 → Ce que j'ai appris (et les erreurs à éviter)
Pourquoi ce projet est différent des tutos classiques
La plupart des tutoriels GitLab CI te montrent un .gitlab-ci.yml tout fait, avec 200 lignes, et te disent "voilà, ça marche".
Mon approche ?
- Partir du strict minimum (1 job qui fait
echo) - Ajouter une complexité à la fois (lint, puis build, puis security)
- Expliquer chaque choix technique (pourquoi Kaniko ? pourquoi Trivy ?)
- Documenter les erreurs réelles (pas juste "ça marche du premier coup")
- Fournir un repo GitHub/GitLab utilisable tel quel
Les technologies utilisées dans le projet
| Outil | Rôle | Pourquoi ce choix ? |
|---|---|---|
| GitLab CI | Orchestration CI/CD | Standard industrie, intégré GitLab |
| Hadolint | Lint Dockerfile | Détecte mauvaises pratiques Docker |
| Kaniko | Build image Docker | Pas besoin de Docker daemon (plus sûr) |
| Trivy | Scan sécurité | Détecte vulnérabilités CVE dans l'image |
Ce que tu peux faire avec ce repo
👨🎓 Si tu es étudiant
- Clone le repo et teste la pipeline sur ton propre GitLab
- Modifie le Dockerfile pour voir comment réagissent Hadolint et Trivy
- Casse volontairement des choses pour comprendre les erreurs
- Adapte la CI à ton propre projet de TP
👨💻 Si tu es dev/ops
- Récupère des snippets réutilisables (job Kaniko, job Trivy…)
- Compare avec ta CI actuelle (tu fais peut-être du Docker-in-Docker dangereux ?)
- Utilise comme base pour former des juniors
Les prochaines améliorations possibles
Ce projet est un point de départ, pas une solution complète. Voici ce que je pourrais ajouter plus tard :
- Déploiement automatique (Ansible, Kubernetes, Docker Swarm)
- Tests applicatifs (pytest, coverage)
- Multi-environnements (staging, production, feature branches)
- Métriques de qualité (coverage, performance)
- Secrets management (HashiCorp Vault, GitLab CI variables)
Conclusion : apprendre en cassant, pas en copiant
GitLab CI/CD, tu peux l'apprendre en une soirée… ou tu peux passer 3 jours à te battre avec une erreur mystérieuse de runner.
Ce repo, c'est mon moyen de transformer ces galères en apprentissage structuré.
Si toi aussi tu en as marre des tutos qui "marchent magiquement", clone le projet et casse tout :
👉 GitLab CI Learning sur GitLab
Et dans le prochain article, on entre dans le concret : comment GitLab exécute vraiment ta pipeline (spoiler : l'ordre des jobs ne dépend pas de l'ordre d'écriture).
Tu as des questions sur le projet ? Des suggestions d'amélioration ? Laisse un commentaire ! 👇
Tags: #gitlab #cicd #devops #learning #docker #security #python #devsecops #student #tutorial
Top comments (0)