CI/CD pour projets JavaScript : GitHub Actions de A à Z

Introduction : Pourquoi le CI/CD est-il nécessaire pour les projets JavaScript ?

Le développement d'applications JavaScript modernes sur Node.js nécessite non seulement l'écriture de code de qualité, mais aussi sa livraison fiable aux utilisateurs finaux. Les tests, la construction et le déploiement manuels sont non seulement lents, mais aussi sujets aux erreurs humaines. C'est là qu'intervient le CI/CD (Continuous Integration / Continuous Deployment) — une méthodologie d'automatisation de toutes les étapes du cycle de vie du logiciel.

Le CI/CD pour les projets JavaScript permet d'exécuter automatiquement les tests à chaque push dans le dépôt, de construire l'application et de la déployer sur un serveur ou dans le cloud. L'un des outils les plus populaires pour mettre en œuvre cette méthodologie est GitHub Actions — un système d'automatisation de flux de travail intégré à la plateforme GitHub.

Dans cet article, nous allons voir comment configurer un pipeline CI/CD complet pour un projet JavaScript (Node.js) en utilisant GitHub Actions : de l'écriture de la configuration au déploiement. Vous apprendrez à accélérer le développement, à améliorer la qualité du code et à oublier les opérations routinières.

Partie principale : Création d'un pipeline CI/CD avec GitHub Actions

1. Qu'est-ce que GitHub Actions et comment fonctionne-t-il ?

GitHub Actions est une plateforme d'automatisation des flux de travail (workflows) qui se déclenche en réponse à des événements dans le dépôt (push, pull request, création d'issue, etc.). Un workflow est un ensemble d'étapes exécutées sur des machines virtuelles (runners). Chaque étape peut exécuter des scripts, installer des dépendances ou appeler des services externes.

Concepts de base :

\n
• Workflow — fichier de configuration YAML, stocké dans le dossier .github/workflows/.
\n
• Event — déclencheur qui lance le workflow (par exemple, push ou pull_request).
\n
• Job — ensemble d'étapes exécutées sur un même runner (dépendances, tests, construction).
\n
• Step — commande ou action individuelle.
\n

Pour les projets JavaScript, nous utiliserons le runner standard avec Ubuntu, car il prend en charge Node.js nativement.

2. Configuration de base : Tests et linting

Commençons par créer un workflow simple pour les tests et le linting du code. Créez un fichier .github/workflows/ci.yml à la racine de votre dépôt.

Exemple de configuration pour un projet Node.js :

name: CI for Node.js\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n\n    strategy:\n      matrix:\n        node-version: [18.x, 20.x]\n\n    steps:\n      - name: Checkout repository\n        uses: actions/checkout@v4\n\n      - name: Setup Node.js ${{ matrix.node-version }}\n        uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.node-version }}\n          cache: 'npm'\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

Analysons les points clés :

\n
• Matrix strategy — permet d'exécuter les tests sur plusieurs versions de Node.js (18.x et 20.x) en parallèle.
\n
• actions/checkout — action standard pour cloner le dépôt.
\n
• actions/setup-node — installe la version souhaitée de Node.js et active la mise en cache de node_modules pour accélérer le processus.
\n
• npm ci — installation propre des dépendances à partir de package-lock.json (plus rapide et plus fiable que npm install).
\n

Après avoir poussé ce fichier dans le dépôt, GitHub Actions exécutera automatiquement les tests. Vous verrez le résultat dans la section "Actions" de votre dépôt.

3. Construction et publication d'une image Docker

E