GitHub Actions : construire votre pipeline de déploiement automatique

L'anatomie d'un pipeline CI/CD e-commerce

Un pipeline GitHub Actions pour un site e-commerce headless se déroule en quatre phases séquentielles. Chaque phase est un garde-fou : si elle échoue, le déploiement s'arrête avant d'atteindre la production.

1. Phase 1 — Build : Compilation du front Nuxt 3. Si le build échoue, rien n'est envoyé sur le serveur.
2. Phase 2 — Tests : Vérification des URLs critiques en préproduction (curl -I, codes HTTP).
3. Phase 3 — Deploy préproduction : Transfert via SSH + archive tar, reload PM2 Graceful (Zero-Downtime).
4. Phase 4 — Validation post-deploy : Vérification que la préproduction répond en 200 sur les pages clés avant de libérer le déploiement production.

Structure du fichier workflow

name: Deploy Preprod
on:
  push:
    branches: [preprod]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Nuxt
        run: npm ci && npm run build
      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /srv/hub
            ./deploy-nuxt.sh --all
      - name: Verify deploy
        run: |
          sleep 5
          curl -sf https://preprod.votresite.fr | grep -q "200"

Les trois règles non-négociables du pipeline

• Jamais de docker restart dans le script de deploy — utiliser exclusivement le graceful reload PM2 pour garantir le zero-downtime.
• Secrets dans GitHub Secrets, jamais en clair dans le workflow — VPS_HOST, SSH_PRIVATE_KEY, ANTHROPIC_API_KEY.
• Un commit = un deploy tracé — chaque exécution du pipeline est visible dans l'onglet Actions, avec logs complets et possibilité de re-run manuel.

Ce pipeline devient la colonne vertébrale de votre processus de livraison. Il transforme un geste risqué (déployer) en un acte de confiance (pousser sur la branche preprod).