Maîtriser GitLab CI/CD pour React et Node.js

🧭 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 par npm 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