Pipelines CI/CD expliqués avec GitHub Actions

Vous venez de pousser un commit et vous exécutez maintenant manuellement les tests, construisez l'application et téléversez les fichiers sur un serveur. Ça fonctionne, mais c'est lent, source d'erreurs et difficile à faire évoluer. C'est là que les pipelines CI/CD entrent en jeu.

Dans ce guide, nous allons décortiquer les concepts CI/CD et vous montrer comment construire un véritable pipeline avec GitHub Actions. À la fin, vous saurez automatiser les tests, la construction et le déploiement pour n'importe quel projet.

Qu'est-ce que la CI/CD ?

La CI (Intégration Continue) est la pratique consistant à tester et fusionner automatiquement les modifications de code dans une branche partagée. Chaque push déclenche une construction et une exécution des tests, ce qui permet de détecter les problèmes d'intégration très tôt.

Le CD (Livraison/Déploiement Continus) étend la CI en préparant automatiquement (et éventuellement en déployant) votre application en production. La Livraison Continue signifie que le code est toujours prêt à être déployé ; le Déploiement Continu signifie qu'il est déployé automatiquement.

Ensemble, la CI/CD forme un pipeline : une série d'étapes automatisées qui font passer votre code du commit à la production.

Pourquoi utiliser GitHub Actions pour la CI/CD ?

GitHub Actions est une plateforme CI/CD intégrée à GitHub. Elle est gratuite pour les dépôts publics et offre un quota généreux de minutes pour les dépôts privés. Principaux avantages :

• Intégrée : aucun service externe nécessaire ; les workflows résident dans votre dépôt.
• Événementielle : déclenchez des workflows sur push, pull request, planification ou déclenchement manuel.
• Extensible : des milliers d'actions prêtes à l'emploi dans le GitHub Marketplace.
• Builds matriciels : testez facilement sur plusieurs OS et versions de langage.

Concepts fondamentaux de GitHub Actions

Avant d'écrire votre premier workflow, comprenez ces termes :

Construire votre premier pipeline CI

Créons un workflow CI de base pour un projet Node.js. Il exécutera les tests à chaque push et pull request sur la branche principale.

Créez .github/workflows/ci.yml :

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x, 20.x]

    steps:
    - uses: actions/checkout@v4
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v4
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm test

Ce workflow :

1. Se déclenche sur les pushs et les PRs vers main.
2. Exécute un job appelé test sur le dernier runner Ubuntu.
3. Utilise une matrice pour tester avec Node.js 18 et 20.
4. Récupère le code, configure Node, installe les dépendances et exécute les tests.

Poussez ce fichier et observez l'onglet Actions. Vous verrez deux jobs parallèles (un par version de Node). Si un test échoue, le workflow échoue et GitHub vous notifie.

Ajouter le déploiement continu

La CI c'est bien, mais c'est dans le CD que l'automatisation brille. Étendons le workflow pour déployer sur un serveur après que les tests réussissent sur la branche principale.

Nous allons ajouter un job deploy qui dépend de test et ne s'exécute que sur les pushs vers main.

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Deploy to server
      uses: appleboy/ssh-action@v1.0.0
      with:
        host: ${{ secrets.SSH_HOST }}
        username: ${{ secrets.SSH_USER }}
        key: ${{ secrets.SSH_KEY }}
        script: |
          cd /var/www/myapp
          git pull origin main
          npm ci --production
          pm2 restart myapp

Points clés :

• needs: test garantit que le déploiement ne s'exécute que si les tests réussissent.
• La condition if limite le déploiement aux pushs sur main.
• Les secrets (SSH_HOST, SSH_USER, SSH_KEY) sont stockés dans les paramètres du dépôt GitHub et injectés de manière sécurisée.

Ce modèle fonctionne pour de nombreuses cibles de déploiement : SSH, registres Docker, plateformes cloud (AWS, Vercel, Netlify) ou Kubernetes.

Bonnes pratiques pour la CI/CD avec GitHub Actions

• Gardez les workflows rapides : mettez en cache les dépendances (par ex. actions/cache) pour réduire les temps de build.
• Échouez vite : exécutez les vérifications rapides (linting) avant les tests plus lents.
• Utilisez les environnements : configurez des règles de protection pour les déploiements en production.
• Sécurisez les secrets : ne codez jamais les identifiants en dur ; utilisez GitHub Secrets.
• Surveillez et alertez : configurez des notifications pour les workflows échoués.

Déboguer les workflows échoués

Lorsqu'un workflow échoue, GitHub affiche les logs de chaque étape. Les problèmes courants incluent :

• Dépendances manquantes : assurez-vous que npm ci ou l'équivalent s'exécute avant les tests.
• Secrets incorrects : vérifiez les noms et les valeurs.
• Erreurs de permission : vérifiez les permissions du runner et les clés SSH.

Vous pouvez également activer la journalisation de débogage en définissant le secret de dépôt ACTIONS_STEP_DEBUG sur true.

FAQ

Quelle est la différence entre CI et CD ?

La CI automatise les tests et l'intégration des modifications de code. Le CD automatise la livraison ou le déploiement de ces modifications vers un environnement. La CI assure la qualité du code ; le CD assure qu'il atteint les utilisateurs rapidement et de manière fiable.

GitHub Actions est-il gratuit ?

GitHub Actions est gratuit pour les dépôts publics. Pour les dépôts privés, vous bénéficiez d'un quota mensuel de minutes gratuites (par ex. 2 000 minutes pour les comptes Free) et payez pour l'usage supplémentaire. Les runners auto-hébergés sont également une option.

Puis-je utiliser GitHub Actions pour des projets non hébergés sur GitHub ?

Oui, GitHub Actions peut exécuter n'importe quel outil en ligne de commande. Vous pouvez l'utiliser pour construire et déployer des projets hébergés ailleurs, tant que le code est sur GitHub ou que vous utilisez des actions pour le récupérer.

Prêt à rationaliser votre CI/CD ? Commencez par automatiser vos tests avec GitHub Actions. Pour analyser rapidement les logs de déploiement, essayez notre Analyseur de Logs Nginx pour repérer les erreurs et les problèmes de performance après chaque déploiement.