Bien utiliser GitLab CI/CD

Un pipeline GitLab bien fait teste, construit et déploie à chaque push, sans intervention. Voici comment je structure un .gitlab-ci.yml propre : stages, cache, artefacts, environnements et déploiement conditionnel.

StackGitLab CIrunnersDockerartifactsenvironments

Le modèle mental

GitLab CI lit un fichier .gitlab-ci.yml à la racine. Il définit des jobs, groupés en stages qui s'exécutent en séquence : un stage ne démarre que si le précédent a réussi. Les jobs tournent sur des runners — des machines qui exécutent tes commandes dans un conteneur.

jobune unité de travail (lint, test, build…)

stageun groupe de jobs qui tournent en parallèle

runnerla machine qui exécute le job

artifactun fichier passé d’un stage au suivant

Un pipeline complet

Trois stages suffisent pour la plupart des apps : tester, construire, déployer. Le cache évite de réinstaller les dépendances à chaque job ; les artefacts transportent le build.

.gitlab-ci.ymlYAMLCopier

# .gitlab-ci.yml — un pipeline en 3 stages
stages: [test, build, deploy]
variables:
  NODE_ENV: test
cache:                      # reutilise node_modules entre les jobs
  key: ${CI_COMMIT_REF_SLUG}
  paths: [node_modules/]
test:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm run lint && npm test
build:
  stage: build
  image: node:20
  script: [npm ci, npm run build]
  artifacts:                # passe le build au stage suivant
    paths: [.next/]
deploy:
  stage: deploy
  script: ./scripts/deploy.sh
  environment: production
  only: [main]              # ne deploie que depuis main

Les bonnes pratiques

Cache & artefacts

Cache = ce qu'on reconstruit (node_modules). Artefact = ce qu'on transmet (le build). Ne pas confondre.

Déploiement conditionnel

only: [main] ou des rules : la prod ne se déploie que depuis la bonne branche, jamais sur une feature branch.

Environments

Déclare staging et production : GitLab suit ce qui est déployé où, et permet le rollback en un clic.

Secrets en variables

Jamais de secret dans le YAML : mets-les en variables CI/CD masquées, dans les settings du projet.

À retenir

Le même script de déploiement doit tourner en CI et en local — c'est le principe de rendre un déploiement ennuyeux.

Sources & ressources

01GitLab — .gitlab-ci.yml keyword referenceLa référence complète des mots-clés YAML : stages, script, artifacts, cache, environment, rules.↗02GitLab — Caching in GitLab CI/CDLa différence cache vs artefacts expliquée par GitLab, avec les stratégies de clés et de fallback.↗03GitLab — Environments and deploymentsDéclarer staging et production, suivre les déploiements et faire un rollback.↗04GitLab — Specify when jobs run with rulesLe remplaçant moderne de only/except : conditions, variables et migration.↗05GitLab — CI/CD variablesVariables masquées et protégées : la bonne façon de ranger un secret hors du YAML.↗06GitLab — Pipeline architecturesPipelines basiques, DAG avec needs et pipelines parent-enfant : quand choisir quoi.↗07GitLab — RunnersRunners hébergés par GitLab ou auto-gérés : ce qui exécute réellement tes jobs.↗

En résumé

Un bon pipeline GitLab est invisible : il teste et déploie sans que tu y penses, et t'arrête net quand quelque chose casse. Trois stages, du cache, des artefacts, des secrets bien rangés — et tu pushes l'esprit tranquille.

GitLab CI/CD docs ↗

À lire ensuite

Guide

Coder un SaaS en 24h avec Claude Code

Du repo vide au produit en ligne en une journée : le plan, les raccourcis, et ce qui casse quand on va trop vite.

Technique

Les erreurs courantes avec Claude Code

Méga-prompts, pas de CLAUDE.md, jamais de tests, aucun commit : les pièges qui transforment l'agent en boulet.

Technique

Pourquoi Vercel pour son SaaS

Zéro infra, previews par PR, edge global : ce que Vercel te fait gagner — et le jour où il faut en partir.