Créer son premier pipeline CI/CD avec GitLab CI

🎯 Objectifs

• ✅ Comprendre le fonctionnement de GitLab CI/CD
• ✅ Créer un fichier .gitlab-ci.yml
• ✅ Définir des stages et des jobs
• ✅ Utiliser les runners partagés et self-hosted
• ✅ Intégrer Docker dans vos pipelines

📋 Prérequis

📖 Rappel CI/CD

CI (Intégration Continue) = build + tests automatiques à chaque push.

CD (Déploiement Continu) = déploiement automatique vers staging ou production.

💡 GitLab CI est l'outil CI/CD natif de GitLab. Pour une autre approche, consultez les modules GitHub Actions.

🦊 GitLab CI vs GitHub Actions

🔧 Concepts Clés

Structure d'un pipeline :

Pipeline
├── Stage: build
│   └── Job: compile
├── Stage: test
│   ├── Job: unit-test
│   └── Job: lint
└── Stage: deploy
    └── Job: deploy-staging

💡 Les jobs d'un même stage s'exécutent en parallèle. Les stages s'exécutent séquentiellement.

🚀 Premier Pipeline

Créez un fichier .gitlab-ci.yml à la racine de votre projet :

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:20-alpine
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

test:
  stage: test
  image: node:20-alpine
  script:
    - npm ci
    - npm test

deploy:
  stage: deploy
  script:
    - echo "Déploiement en cours..."
  only:
    - main

Explication des mots-clés

🐳 Mot-clé image

Chaque job s'exécute dans un conteneur Docker. Choisissez l'image adaptée à votre projet :

job:
  image: python:3.12
  script:
    - pip install -r requirements.txt
    - pytest

⚙️ Runners

Runners partagés

GitLab.com fournit des runners partagés gratuits. Aucune configuration nécessaire.

Runners self-hosted

Installez un runner sur votre propre machine pour plus de contrôle.

Tags

Utilisez les tags pour cibler un runner spécifique :

job:
  tags:
    - docker
    - linux
  script:
    - echo "Exécuté sur un runner Linux avec Docker"

📦 Artefacts

Les artefacts permettent de passer des fichiers entre stages.

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

💡 expire_in libère automatiquement l'espace de stockage après la durée spécifiée.

Le stage deploy peut ensuite utiliser le dossier dist/ produit par build.

👀 Voir les Résultats

1. Allez dans CI/CD → Pipelines dans l'interface GitLab
2. Chaque stage affiche un statut vert (✅) ou rouge (❌)
3. Cliquez sur un job pour voir ses logs en temps réel

💡 Vous pouvez aussi relancer un job échoué directement depuis l'interface.

🔑 Variables Prédéfinies

GitLab injecte automatiquement des variables dans chaque job :

job:
  script:
    - echo "Commit $CI_COMMIT_SHA sur $CI_COMMIT_BRANCH"

❌ Erreurs Courantes

💡 Utilisez CI/CD → Editor dans GitLab pour valider votre YAML avant de push.

📌 Points Clés

1. .gitlab-ci.yml à la racine déclenche automatiquement le pipeline
2. Les stages définissent l'ordre, les jobs définissent les tâches
3. Chaque job tourne dans un conteneur Docker via image:
4. Les artefacts passent des fichiers entre stages
5. Les runners partagés de GitLab.com sont gratuits et prêts à l'emploi

📚 Ressources

• Documentation GitLab CI/CD
• Référence `.gitlab-ci.yml`
• Linter CI intégré
• Variables prédéfinies

🚀 Prochaines étapes

Vous avez créé vos premiers pipelines GitLab CI. Passez au niveau intermédiaire :

1. GitLab CI : rules, cache et pipelines DAG - Rules, cache, services, pipelines DAG et templates