Créer un pipeline CI/CD avec GitHub Actions

GitHub Actions est un outil d'automatisation qui lance vos tests à chaque push de code et, si tout est au vert, déploie automatiquement votre projet sur le serveur. Il vit à l'intérieur de votre dépôt : aucun service séparé auquel s'abonner, et il offre un quota gratuit généreux pour les projets open source. Dans ce guide, nous allons construire un pipeline CI/CD de zéro : d'abord clarifier les concepts, puis écrire un véritable workflow de test et de déploiement.

Pourquoi le CI/CD et GitHub Actions sont utiles

Le CI (Continuous Integration) consiste à compiler et tester automatiquement chaque modification de code, afin d'attraper un commit cassé avant même qu'il soit fusionné. Le CD (Continuous Delivery/Deployment) consiste à livrer automatiquement le code qui passe les tests vers un environnement de préproduction ou de production. Le flux combiné s'appelle un pipeline CI/CD.

La boucle manuelle « lancer les tests en local, envoyer les fichiers par FTP, croiser les doigts » est lente et propice aux erreurs. GitHub Actions rend cette boucle reproductible :

• Cohérence : le pipeline s'exécute sur une machine virtuelle propre, ce qui élimine en grande partie le problème du « ça marchait sur ma machine ».
• Vitesse : les jobs peuvent tourner en parallèle, donc lint, test et build avancent en même temps.
• Sécurité : les clés SSH et les tokens sont stockés chiffrés dans les secrets du dépôt au lieu d'être codés en dur.

Concepts clés : workflow, job, step, action

Le vocabulaire de GitHub Actions est restreint mais essentiel :

• Workflow : un fichier YAML dans le dossier .github/workflows/. Il définit quand et quoi exécuter.
• Event (déclencheur) : l'événement qui démarre le workflow — push, pull_request, un schedule planifié, ou un workflow_dispatch manuel.
• Job : un groupe d'étapes qui s'exécute sur le même runner. Les jobs tournent en parallèle par défaut, et en séquence avec needs.
• Step : une seule commande (run) dans un job, ou une action toute prête via uses.
• Runner : la machine virtuelle sur laquelle tourne le job, par exemple ubuntu-latest.

Votre premier workflow : lancer les tests

Prenons un projet Node.js. Créez .github/workflows/ci.yml à la racine du dépôt :

name: CI

on:
  push:
    branches: [main]
  pull_request:

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

actions/checkout@v4 clone votre dépôt sur le runner, setup-node installe la bonne version de Node, et cache: npm met en cache vos dépendances. npm ci effectue une installation propre strictement fidèle à package-lock.json — plus fiable que npm install en CI. Dès que vous poussez ce fichier, les tests s'exécutent automatiquement à chaque commit et pull request.

Tester plusieurs versions avec une matrice

Pour tester une bibliothèque sur plusieurs versions d'un langage, strategy.matrix multiplie un seul job :

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

Ce workflow lance les mêmes tests sur Node 18, 20 et 22 en parallèle. Côté PHP/Laravel, appliquez la même idée avec l'action shivammathur/setup-php pour essayer plusieurs versions de PHP, puis lancez php artisan test.

Secrets et le job de déploiement

L'étape de déploiement nécessite un accès à votre serveur, donc des secrets. N'écrivez jamais une clé privée SSH ou un token d'API dans le YAML. Créez plutôt un secret sur GitHub sous Settings → Secrets and variables → Actions (par exemple SSH_PRIVATE_KEY, SSH_HOST) et référencez-le dans le workflow via ${{ secrets.SSH_HOST }}.

L'exemple ci-dessous ajoute un second job qui déploie après la réussite des tests. Grâce à needs: test, le déploiement ne s'exécute que si le job de test a réussi, et la condition if le limite aux push sur main :

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Déployer sur le serveur via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          port: ${{ secrets.SSH_PORT }}
          script: |
            cd ~/app
            git pull origin main
            composer install --no-dev -o
            php artisan migrate --force
            php artisan optimize

Ici, la stratégie de déploiement est un simple flux « se connecter au serveur, tirer, mettre à jour ». Avec Docker, vous construiriez plutôt l'image et la pousseriez vers un registry (docker/build-push-action), puis tireriez la nouvelle image sur le serveur. Le principe reste le même : la configuration dans le code, les secrets dans les secrets.

Astuces pour fiabiliser le pipeline

• Échouer vite : faites du lint et du test des jobs séparés avant le déploiement, pour qu'un test rouge bloque entièrement le déploiement.
• Utilisez le cache : les caches de dépendances et de build font passer la durée du pipeline de quelques minutes à quelques secondes.
• Épinglez les versions d'action : liez-vous à une version majeure fixe comme @v4 ; pour les projets les plus sensibles, épinglez à un SHA de commit.
• Concurrency : utilisez un bloc concurrency pour annuler les anciens runs de la même branche et éviter les déploiements redondants.
• Visibilité : ajoutez un badge de statut à votre README pour voir d'un coup d'œil si le pipeline est vert ou rouge.

Questions fréquentes

GitHub Actions est-il gratuit ?

Les runners standard sont gratuits pour les dépôts publics. Les dépôts privés bénéficient d'un quota mensuel de minutes gratuites ; au-delà, la facturation se fait à la minute. La plupart des petits et moyens projets restent confortablement dans le quota gratuit.

Pourquoi GitHub Actions plutôt que Jenkins ou GitLab CI ?

Si votre code est déjà sur GitHub, Actions vit au même endroit que votre dépôt : vous démarrez sans aucune infrastructure à installer. Jenkins offre plus de contrôle et de plugins mais exige d'exploiter un serveur. Le choix dépend de l'endroit où travaille votre équipe et du degré de personnalisation souhaité.

Que se passe-t-il si un déploiement échoue ?

Le job passe au rouge, les étapes suivantes ne s'exécutent pas et GitHub vous notifie. Les logs montrent la commande exacte et la sortie d'erreur. Pour des déploiements sûrs, concevez vos migrations comme réversibles et, si possible, utilisez une stratégie de déploiement blue-green ou rolling.

Vous voulez mettre en place votre pipeline ou automatiser un flux de déploiement existant ? Je peux vous aider à faire passer votre projet sur un pipeline CI/CD rapide, sûr et reproductible — contactez-moi.