Tools: Pourquoi j'ai créé un projet pour apprendre GitLab CI/CD (et pourquoi la doc ne suffit pas)

Le problème avec l'apprentissage "théorique" de la CI/CD ## L'idée : un "bac à sable" pédagogique ## Les objectifs concrets de ce repo ## Objectif 1 : Comprendre la structure d'une pipeline ## Objectif 2 : Savoir pourquoi une pipeline "casse" ## Objectif 3 : Construire une CI "professionnelle" ## Ce que tu vas découvrir dans cette série d'articles ## Pourquoi ce projet est différent des tutos classiques ## Les technologies utilisées dans le projet ## Ce que tu peux faire avec ce repo ## 👨‍🎓 Si tu es étudiant ## 👨‍💻 Si tu es dev/ops ## Les prochaines améliorations possibles ## Conclusion : apprendre en cassant, pas en copiant 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. 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. 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. Avant de faire du "DevSecOps avancé", il faut maîtriser les bases : Dans mon projet, je pars d'une pipeline ultra-simple : Puis j'ajoute progressivement de la complexité. Les erreurs les plus frustrantes en CI/CD ? Celles qui ne sont pas dans ton code, mais dans l'environnement : Mon repo documente toutes ces erreurs réelles que j'ai rencontrées. Une bonne pipeline ne fait pas que "build". Elle doit : Mon projet implémente ces 3 étapes, avec des explications sur pourquoi chacune est importante. Je vais publier 7 articles qui détaillent tout le processus, dans l'ordre : La plupart des tutoriels GitLab CI te montrent un .gitlab-ci.yml tout fait, avec 200 lignes, et te disent "voilà, ça marche". Ce projet est un point de départ, pas une solution complète. Voici ce que je pourrais ajouter plus tard : 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 Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK: stages: - basic basic: stage: basic script: - echo "Pipeline fonctionnelle !" Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: stages: - basic basic: stage: basic script: - echo "Pipeline fonctionnelle !" CODE_BLOCK: stages: - basic basic: stage: basic script: - echo "Pipeline fonctionnelle !" - Pourquoi ce job reste en "pending" pendant 10 minutes ? - C'est quoi la différence entre un stage et un job concrè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 ? - 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 - 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 - 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) - 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) - 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 - 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 - 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 - 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)