CI/CD avec GitLab

1. Introduction

Poursuivant notre série sur l'Intégration et le Déploiement Continus (CI/CD), nous explorons aujourd'hui un acteur majeur : GitLab et son système intégré GitLab CI/CD. Cette plateforme offre une solution à la fois puissante et flexible pour automatiser l'intégralité de votre flux de développement, de la phase de test et de build jusqu'au déploiement.

Grâce à GitLab CI/CD, il est possible de détecter rapidement les bogues, garantir que le code déployé en production est conforme aux normes de codage établies et réduire le temps entre l'écriture du code et sa mise en production.

Dans ce troisième tutoriel, vous allez découvrir :

• Les concepts essentiels
• Des exemples pratiques
• Comment utiliser les variables CI/CD pour sécuriser des déploiements.
• Quelques conseils pour diagnostiquer et optimiser des pipelines.

2. Prérequis

Pour suivre ce guide, tu auras besoin de :

• Un compte GitLab et un dépôt actif.
• Un projet compilable hébergé dans ce dépôt. (Pour l'exemple, j'ai utilisé un code statique HTML, CSS, JS)
• Git installé localement.
• Assures-toi que ta branche principale est nommée main (ou master).

ℹ️ Si tu n'as pas encore de projet sur Gitlab, tu peux en créer un : https://gitlab.com

Nous utiliserons la structure de mon projet statique HTML suivante comme référence :

/ (racine du dépôt)
├─ index.html
├─ style.css
├─ script.js
├─ package.json (pour l'exemple avancé)
└─ assets/
   └─ logo.png

3. Pipeline minimal : déployer avec un seul job pages

Dans cette première approche, nous allons volontairement faire le pipeline le plus simple possible.

L’objectif est de comprendre le mécanisme de déploiement de GitLab Pages, sans se préoccuper pour l’instant des tests ou de la construction du projet.

Pour un déploiement statique via GitLab Pages, un seul job est requis : il doit obligatoirement s’appeler pages.
Ce nom permet à GitLab de détecter automatiquement le job chargé de publier le contenu du dossier public/ en tant que site web.

Comme avec GitHub Actions, GitLab CI/CD repose sur un fichier YAML.
À la racine de votre projet, créez un fichier .gitlab-ci.yml contenant le code suivant :

pages:
  stage: deploy
  script:
    - mkdir -p public
    - echo "Mon premier site GitLab Pages" > public/index.html
  artifacts:
    paths:
      - public
  only:
    - main

Une fois le pipeline exécuté avec succès, GitLab publie automatiquement le contenu du dossier public/ via GitLab Pages.

Pour accéder à votre site :

• Rendez-vous dans votre projet GitLab
• Allez dans Deploy → Pages
• Cliquez sur l’URL fournie par GitLab

L’URL suit généralement le format : https://<username>.gitlab.io/<nom-du-projet>/

La première publication peut prendre quelques secondes après la fin du pipeline.

Lorsque tout est correctement configuré, le pipeline apparaît avec un statut réussi dans l’onglet Build → Pipelines.

L’exemple ci-dessous montre un pipeline minimal composé uniquement du job pages, exécuté avec succès.

4. Pipeline avec plusieurs jobs

Maintenant que le mécanisme de base de GitLab Pages est compris, observons un pipeline composé de plusieurs jobs.

⚠️Attention : Ce pipeline n’est pas destiné au déploiement Pages. Ll sert uniquement à comprendre le fonctionnement interne de GitLab CI/CD.

build-job:
  stage: build
  script:
    - echo "Hello, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  script:
    - echo "This job tests something, but takes more time than test-job1."
    - echo "After the echo commands complete, it runs the sleep command for 20 seconds"
    - echo "which simulates a test that runs 20 seconds longer than test-job1"
    - sleep 20

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
  environment: production

Ce type de pipeline est utile pour apprendre à : organiser des jobs, comprendre les stages et exploiter les variables prédéfinies, avant de passer à un vrai pipeline de production.

5. Pipeline avancé : build, test et déploiement avec GitLab Pages

Ce pipeline représente un cas proche d’un projet réel. Il combine une organisation claire des étapes et un déploiement automatique sur GitLab Pages grâce au job pages.

L’objectif d’un pipeline multi-stage est de séparer les responsabilités : le code est d’abord construit, ensuite testé, puis déployé uniquement si toutes les étapes précédentes ont réussi.

Ordre d’exécution :build →test →deploy

# Image Docker utilisée pour tous les jobs
image: node:18-alpine

# Définition des étapes du pipeline
stages:
  - build   # Installation des dépendances et compilation
  - test    # Exécution des tests automatisés
  - deploy  # Déploiement sur GitLab Pages

# Cache partagé entre les jobs pour accélérer les exécutions
cache:
  paths:
    - node_modules/

# Job build : installation et compilation
install:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

# Job test : tests unitaires
unit_tests:
  stage: test
  script:
    - npm test
  dependencies:
    - install

# Job deploy : publication via GitLab Pages
pages:
  stage: deploy
  script:
    - mkdir -p public
    - cp -r dist/* public/
  artifacts:
    paths:
      - public
  only:
    - main

6. Variables CI et gestion sécurisée des secrets

Dans un pipeline CI/CD, il est impératif de ne jamais exposer des informations sensibles (tokens, clés API, mots de passe) dans le code source ou dans le fichier .gitlab-ci.yml.

GitLab fournit un mécanisme sécurisé via l'onglet Settings → CI/CD → Variables. Les valeurs définies dans cette interface sont injectées automatiquement comme variables d’environnement dans vos jobs.

Exemple : une variable nommée MY_API_TOKEN pourra être utilisée directement dans vos scripts.

Bonnes pratiques lors de la configuration :

• Protected : restreint l’utilisation de la variable aux branches protégées (comme main).
• Masked : masque la valeur dans les logs du pipeline.
  👉 À activer systématiquement pour les secrets.

Exemple d’utilisation d’une variable secrète dans un job :

deploy_to_external:
  stage: deploy
  script:
    - curl -X POST -H "Authorization: Bearer $MY_API_TOKEN" https://api.external.com/deploy
    - echo "Déploiement déclenché"
  only:
    - main

7. Dépannage et bonnes pratiques CI/CD

Lors de la mise en place de pipelines, certains problèmes reviennent fréquemment. Voici les plus courants et comment les résoudre.

• Le pipeline ne démarre pas

  Vérifiez que le fichier .gitlab-ci.yml est bien à la racine du dépôt et que les règles d’exécution (only ou rules) correspondent à la branche ou au type de commit.

• Erreur 404 sur GitLab Pages

  Le job pages doit impérativement produire un dossier public/ contenant un fichier index.html.

• Commande introuvable

  Le runner s’exécute dans une image Docker. Assurez-vous que l’image utilisée contient les outils nécessaires (ex. node, python) ou installez-les dans le script.

Bonnes pratiques générales :

• Consultez toujours les logs du job pour identifier précisément l’erreur.
• Gardez des jobs simples et atomiques (une responsabilité par job).
• Préférez rules à only pour un contrôle plus précis et moderne.

8. Conclusion

Vous disposez désormais des bases essentielles pour concevoir des pipelines CI/CD efficaces avec GitLab : du déploiement statique via GitLab Pages à des pipelines multi-stage robustes, sécurisés et maintenables.

Pour aller plus loin vous pouvez :

• Ajouter des analyses de sécurité (SAST, Dependency Scanning).
• Étendre ces pipelines vers des plateformes cloud ou Kubernetes.
• Améliorer la visibilité avec des badges, des logs structurés et une documentation enrichie.