Pipeline CI/CD pour JavaScript : configuration de zéro en 10 étapes

Comment arrêter de déployer manuellement et ne plus avoir peur des commits

Avez-vous déjà passé un vendredi soir à regarder la production en vous disant : « Bon, tout a l’air de fonctionner, et si je lance la construction maintenant, rien ne va casser ? » Ça vous parle ? Le déploiement manuel, c’est comme sauter en parachute sans instructeur : il y a bien de l’adrénaline, mais ça finit trop souvent par faire mal.

Un pipeline CI/CD est votre corde de sécurité automatique. Il construit le projet, exécute les tests, vérifie le code et, si tout va bien, déploie la mise à jour sur le serveur. Fini les « Oups, j’ai oublié de lancer la construction » ou « Pourquoi les tests échouent-ils alors que tout fonctionnait en local ? ».

Dans cet article, nous allons configurer de zéro un pipeline CI/CD complet pour un projet JavaScript. Sans blabla, avec des exemples de code concrets et des configurations prêtes à l’emploi. C’est parti !

Qu’est-ce qu’un pipeline CI/CD et pourquoi un développeur JavaScript en a-t-il besoin

Commençons par clarifier les termes pour éviter toute confusion.

Continuous Integration (CI) — Intégration continue. Cela signifie que chaque commit est automatiquement vérifié : le code passe par des linters, des tests, une construction. Si quelque chose est cassé, vous le savez en 2 minutes, pas une semaine plus tard.

Continuous Delivery (CD) — Livraison continue. Déploiement automatique du code prêt sur le serveur une fois que toutes les vérifications CI ont réussi.

Pour les projets JavaScript, le CI/CD est particulièrement important. Pourquoi ? Parce que l’écosystème JS repose sur des milliers de dépendances qui peuvent se mettre à jour à tout moment et casser votre code. L’automatisation vous protège de ces surprises.

Ce que nous allons configurer

\n
• GitHub Actions — un outil CI/CD gratuit (suffisant pour la plupart des projets)
\n
• Linter — vérification du style de code (ESLint)
\n
• Tests — exécution automatique de Jest
\n
• Construction — build du projet (Webpack ou Vite)
\n
• Déploiement — mise en ligne automatique sur le serveur ou l’hébergement
\n

Étape 1 : Préparer le projet

Supposons que vous ayez déjà un projet JavaScript (React, Vue, Node.js — peu importe). Sinon, créez un projet simple pour tester :

mkdir my-ci-cd-project\ncd my-ci-cd-project\nnpm init -y\nnpm install --save-dev jest eslint

Ajoutons un script de base dans package.json :

{\n  "scripts": {\n    "test": "jest",\n    "lint": "eslint src/",\n    "build": "webpack --mode production",\n    "deploy": "rsync -avz dist/ user@server:/var/www"\n  }\n}

Nous avons maintenant des commandes locales que le CI/CD exécutera automatiquement.

Étape 2 : Créer un workflow GitHub Actions

GitHub Actions est le cerveau de notre pipeline. Tout est géré par des fichiers YAML dans le dossier .github/workflows/.

Créez le fichier .github/workflows/ci-cd.yml :

name: CI/CD Pipeline\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n    \n    steps:\n    - uses: actions/checkout@v3\n    \n    - name: Setup Node.js\n      uses: actions/setup-node@v3\n      with:\n        node-version: '18'\n        \n    - name: Install dependencies\n      run: npm ci\n      \n    - name: Run linter\n      run: npm run lint\n      \n    - name: Run tests\n      run: npm test\n      \n    - name: Build project\n      run: npm run build

Que se passe-t-il ici ? À chaque push sur main ou develop, GitHub lance une machine virtuelle avec Ubuntu, installe Node.js 18, installe les dépendances (installation propre via npm ci — plus rapide et plus fiable que npm install), vérifie le code avec le linter, exécute les tests et construit le projet.

Si une seule étape échoue, le pipeline s’arrête et vous recevez une notification.

Étape 3 : Ajouter le linter et les tests

ESLint et Jest sont la norme pour JavaScript. Configurons-les ta