🧭 Introduction
La mise en place de pipelines CI/CD est devenue une compétence indispensable dans le quotidien d’un développeur professionnel. GitLab CI/CD permet d’automatiser les tâches de test, de vérification de code, de build et de déploiement avec une puissance et une flexibilité redoutables. Dans ce guide complet, nous allons passer d’une simple introduction à l’automatisation jusqu’à la conception d’un pipeline de production robuste pour une application web moderne utilisant React.js, Node.js, Prettier, ESLint, et une phase de build suivie du déploiement.
🔍 Contexte
GitLab CI/CD est intégré nativement dans GitLab, sans installation de service supplémentaire. Il s’appuie sur des fichiers de configuration YAML nommés .gitlab-ci.yml
pour décrire des pipelines composés de jobs (tâches), organisés en stages (étapes). Il permet notamment :
- L’automatisation de tests unitaires et fonctionnels
- Le contrôle qualité du code via des outils comme ESLint et Prettier
- La génération d’artefacts (fichiers temporaires ou finaux de build)
- La construction de l’application frontend/backend
- Le déploiement vers un serveur, un conteneur, ou une infrastructure cloud
Ce document servira de référence complète et progressive, avec une mise en situation réaliste : une application React en frontend et un serveur Node.js en backend.
🛠️ Explication ou Étapes
1. Création du projet
Nous partons d’une structure classique :
/mon-app
├── backend/ # Node.js / Express
│ ├── src/
│ └── package.json
├── frontend/ # React.js
│ ├── src/
│ └── package.json
├── .gitlab-ci.yml # Fichier de configuration CI/CD
├── .prettierrc
├── .eslintrc.js
└── README.md
Les deux dossiers frontend
et backend
sont indépendants et disposent de leur propre gestion de dépendances avec npm
ou yarn
.
2. Objectifs du pipeline
Notre pipeline GitLab CI/CD devra :
- Vérifier la qualité du code avec Prettier et ESLint
- Lancer les tests
- Compiler le frontend React (
npm run build
) - Construire et tester le backend Node.js
- Générer des artefacts de build
- Déployer automatiquement sur un environnement distant (via SSH ou autre méthode)
3. Fichier .gitlab-ci.yml
de base
Créons un premier fichier .gitlab-ci.yml
avec des stages clairs.
1stages:
2 - lint
3 - test
4 - build
5 - deploy
4. Jobs de linting (ESLint & Prettier)
Lint frontend
1lint:frontend:
2 stage: lint
3 script:
4 - cd frontend
5 - npm ci
6 - npm run lint
7 - npm run format:check
8 only:
9 - merge_requests
10 - branches
Commentaire : Le job s’exécute uniquement sur les branches et MRs. Il vérifie que le code respecte les règles ESLint et le formatage Prettier.
Lint backend
1lint:backend:
2 stage: lint
3 script:
4 - cd backend
5 - npm ci
6 - npm run lint
7 - npm run format:check
5. Jobs de test
1test:frontend:
2 stage: test
3 script:
4 - cd frontend
5 - npm run test
6 artifacts:
7 paths:
8 - frontend/coverage
9 when: always
10
11test:backend:
12 stage: test
13 script:
14 - cd backend
15 - npm run test
16 artifacts:
17 paths:
18 - backend/coverage
19 when: always
6. Jobs de build
Build frontend
1build:frontend:
2 stage: build
3 script:
4 - cd frontend
5 - npm run build
6 artifacts:
7 paths:
8 - frontend/dist
Build backend
1build:backend:
2 stage: build
3 script:
4 - cd backend
5 - npm run build
6 artifacts:
7 paths:
8 - backend/dist
7. Déploiement
1deploy:production:
2 stage: deploy
3 script:
4 - echo "Déploiement vers production"
5 - rsync -avz frontend/dist/ user@server:/var/www/frontend
6 - rsync -avz backend/dist/ user@server:/var/www/backend
7 only:
8 - main
💡 Exemples concrets
Script ESLint
package.json
(frontend et backend) :
1"scripts": {
2 "lint": "eslint src --ext .js,.jsx,.ts,.tsx",
3 "format:check": "prettier --check ."
4}
Exemple de job avec needs
Pour optimiser la vitesse d’exécution, on peut utiliser needs
:
1build:frontend:
2 stage: build
3 script:
4 - cd frontend
5 - npm run build
6 needs:
7 - job: lint:frontend
8 - job: test:frontend
Cela permet d’exécuter ce job dès que les jobs nécessaires sont terminés, sans attendre toute la fin du stage précédent.
✅ Conclusion
Cette première partie vous a permis de comprendre comment créer un pipeline CI/CD complet et fonctionnel avec GitLab pour une application web moderne. Vous avez appris à :
- Organiser les étapes avec
stages
- Créer des jobs indépendants pour frontend et backend
- Intégrer des outils de qualité de code (Prettier, ESLint)
- Construire et déployer une application
🧭 Introduction
Après avoir mis en place les fondations d'un pipeline GitLab CI/CD pour une application React + Node.js, nous allons maintenant explorer les fonctionnalités avancées permettant d’optimiser les performances, la maintenabilité et la modularité du pipeline. Cette seconde partie est consacrée à la gestion des artefacts, du cache, des dépendances, et des optimisations de pipeline via des mécaniques telles que needs
, rules
ou encore des pipelines enfants.
🔍 Contexte
Dans un environnement de développement professionnel, le pipeline CI/CD ne se contente pas de faire des vérifications basiques. Il doit aussi être rapide, fiable, et résilient aux erreurs. Une bonne gestion du cache et des artefacts permet notamment :
- De réduire les temps d’exécution
- De rendre les étapes inter-dépendantes plus fluides
- D’éviter de reconstruire inutilement des modules
- De partager des données entre jobs et stages
Nous allons maintenant affiner notre pipeline avec ces outils professionnels.
🛠️ Explication ou Étapes
1. Artefacts : transférer les résultats d’un job à un autre
Les artefacts sont les fichiers produits par un job, qui peuvent être utilisés par les jobs suivants. Par exemple :
- Les fichiers
dist/
produits parnpm run build
- Les rapports de test ou de couverture
1build:frontend:
2 stage: build
3 script:
4 - cd frontend
5 - npm run build
6 artifacts:
7 paths:
8 - frontend/dist
9 expire_in: 1 hour
Ici, le build est conservé une heure. Cela suffit pour être consommé par d’autres jobs.
2. Cache : accélérer les jobs avec des fichiers communs
Le cache sert à réutiliser localement des fichiers dans le runner GitLab, comme :
- Le dossier
node_modules
- Les dépendances téléchargées
1cache:
2 key: ${CI_COMMIT_REF_SLUG}
3 paths:
4 - frontend/node_modules
5 - backend/node_modules
Le cache est partagé entre jobs, mais différent à chaque branche (grâce à
${CI_COMMIT_REF_SLUG}
)
3. Optimiser avec needs
needs
permet d’exécuter les jobs en parallèle, sans attendre toute la fin du stage précédent. Exemple :
1build:backend:
2 stage: build
3 script:
4 - cd backend && npm run build
5 needs:
6 - job: lint:backend
7 - job: test:backend
Cela réduit le temps global du pipeline.
4. Utiliser rules
à la place de only/except
Les rules
permettent un contrôle fin de l’exécution d’un job. Exemple : ne déployer que sur main
.
1deploy:production:
2 stage: deploy
3 script: ./deploy.sh
4 rules:
5 - if: '$CI_COMMIT_BRANCH == "main"'
5. Gérer les dépendances avec before_script
Pour éviter de répéter npm install
dans chaque job, on peut utiliser before_script
globalement :
1default:
2 before_script:
3 - npm ci || true
Mais il est souvent préférable de l’expliciter dans chaque job pour garder la traçabilité.
6. Organisation des jobs par template
Pour factoriser les jobs redondants (build/test/lint des deux apps), on peut utiliser l’ancrage YAML :
1.lint_template:
2 script:
3 - npm ci
4 - npm run lint
5
6lint:frontend:
7 extends: .lint_template
8 stage: lint
9 script:
10 - cd frontend && npm run lint
💡 Exemples concrets
Exemple complet avec artefacts, cache, needs
et rules
1stages:
2 - lint
3 - test
4 - build
5 - deploy
6
7cache:
8 key: ${CI_COMMIT_REF_SLUG}
9 paths:
10 - frontend/node_modules
11 - backend/node_modules
12
13lint:frontend:
14 stage: lint
15 script:
16 - cd frontend && npm ci && npm run lint
17
18test:frontend:
19 stage: test
20 script:
21 - cd frontend && npm test
22 artifacts:
23 paths:
24 - frontend/coverage
25
26build:frontend:
27 stage: build
28 script:
29 - cd frontend && npm run build
30 needs:
31 - lint:frontend
32 - test:frontend
33 artifacts:
34 paths:
35 - frontend/dist
36 expire_in: 1 hour
37
38deploy:production:
39 stage: deploy
40 script:
41 - rsync -a frontend/dist/ user@server:/var/www/frontend/
42 rules:
43 - if: '$CI_COMMIT_BRANCH == "main"'
✅ Conclusion
La bonne gestion des artefacts et du cache dans GitLab CI/CD est une compétence fondamentale pour tout développeur souhaitant professionnaliser ses workflows. Ces mécaniques permettent de :
- Rendre les pipelines plus rapides
- Partager efficacement les fichiers entre jobs
- Réduire la redondance et améliorer la lisibilité du fichier
.gitlab-ci.yml