GitHub Actions : automatiser les tests et le déploiement

GitHub Actions est la plateforme CI/CD native de GitHub. Vos workflows vivent dans le repo, se déclenchent sur des événements Git, et s'exécutent sur l'infrastructure de GitHub. Pas de compte Jenkinks à maintenir, pas de webhook à configurer : tout est dans .github/workflows/.

Les concepts de base

Un workflow est un fichier YAML qui définit :

quand il se déclenche (push, PR, schedule, manuel)
quels jobs s'exécutent (chacun dans une VM fraîche)
quelles steps composent chaque job (commandes shell ou actions réutilisables)

.github/workflows/ci.yml

name: CI
 
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
 
      - run: npm ci
      - run: npm test
      - run: npm run build

Ce fichier déclenche automatiquement tests et build sur chaque push vers main et chaque PR. actions/checkout clone le repo, actions/setup-node installe Node.js avec le cache npm. En 30 lignes, vous avez une CI qui fonctionne.

Séparer les environnements

Les jobs sont isolés par défaut. Pour partager des artifacts entre jobs :

.github/workflows/pipeline.yml

name: Pipeline
 
on:
  push:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test
 
  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/
 
  deploy:
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist/
      - name: Deploy
        run: |
          # Votre commande de déploiement ici
          rsync -r dist/ user@server:/var/www/app/

needs: test signifie que build ne démarre que si test a réussi. needs: build enchaîne le déploiement. Le pipeline s'arrête proprement à la première erreur.

Variables d'environnement et secrets

Les secrets ne doivent jamais être dans le code. GitHub stocke les secrets chiffrés — ajoutez-les dans Settings → Secrets and variables → Actions.

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      NODE_ENV: production
    steps:
      - name: Deploy to server
        env:
          SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }}
          SERVER_HOST: ${{ secrets.SERVER_HOST }}
        run: |
          echo "$SSH_KEY" > /tmp/deploy_key
          chmod 600 /tmp/deploy_key
          rsync -e "ssh -i /tmp/deploy_key" -r dist/ deploy@$SERVER_HOST:/var/www/

${{ secrets.DEPLOY_SSH_KEY }} injecte le secret dans la step. Il n'apparaît jamais dans les logs.

Matrix builds : tester sur plusieurs configurations

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

GitHub Actions lance trois jobs en parallèle — un par version de Node. Si les tests passent sur 18, 20 et 22, vous êtes sûr que votre package est compatible. Idéal pour les librairies publiées sur npm.

Déploiement sur Vercel, Netlify ou un VPS

Pour Vercel et Netlify, les intégrations GitHub sont natives — pas besoin de GitHub Actions sauf pour des workflows custom. Pour un VPS :

.github/workflows/deploy.yml

name: Deploy
 
on:
  push:
    branches: [main]
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.9.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
 
      - name: Deploy
        run: |
          ssh -o StrictHostKeyChecking=no deploy@${{ secrets.SERVER_HOST }} << 'EOF'
            cd /var/www/app
            git pull origin main
            npm ci --only=production
            pm2 restart app
          EOF

Workflow complet : CI + déploiement conditionnel

.github/workflows/main.yml

name: CI/CD
 
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
 
jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run type-check
      - run: npm test -- --coverage
 
  deploy-staging:
    needs: quality
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/develop'
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to staging
        env:
          DEPLOY_KEY: ${{ secrets.STAGING_DEPLOY_KEY }}
        run: echo "Deploy to staging..."
 
  deploy-production:
    needs: quality
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to production
        env:
          DEPLOY_KEY: ${{ secrets.PROD_DEPLOY_KEY }}
        run: echo "Deploy to production..."

environment: production active les protection rules — vous pouvez configurer une approbation manuelle requise avant tout déploiement en production.

Ce qui vient du Marketplace

Le GitHub Marketplace contient 20 000+ actions. Les plus utilisées :

actions/cache — cache les dépendances entre runs
codecov/codecov-action — upload la couverture de code
docker/build-push-action — build et push une image Docker
aws-actions/configure-aws-credentials — configure les credentials AWS
slackapi/slack-github-action — notifications Slack

Ce workflow SSH suppose que les clés d'authentification sont configurées sur le serveur — sans ça, le déploiement échoue en silence.

GitHub Actions a démocratisé la CI/CD. Ce qui nécessitait un Jenkins maintenu par une équipe Ops est maintenant dans un fichier YAML commité dans le repo, visible et modifiable par tout le monde. Le bon point de départ est simple : commencez avec npm test automatisé sur chaque PR, ajoutez le déploiement une fois que ça tourne.