Comment configurer un pipeline CI/CD avec GitHub Actions – Guide

Pipeline CI/CD avec GitHub Actions : Guide d'installation complet

Pipeline CI/CD avec GitHub Actions : Guide d'installation complet

Dans le développement logiciel moderne, tester manuellement le code et exécuter des scripts de déploiement après chaque modification constitue un goulot d'étranglement qui ralentit la livraison et introduit des erreurs humaines. Un pipeline CI/CD automatise l'ensemble de ce processus, du test du code à son déploiement en production. Ce guide vous apprendra à configurer un pipeline CI/CD avec GitHub Actions, une plateforme d'automatisation puissante et intégrée, en utilisant des exemples YAML concrets et pratiques pour que vous puissiez livrer du code plus rapidement et de manière plus fiable.

Ce que vous allez apprendre

À la fin de ce guide, vous comprendrez les concepts fondamentaux de l'Intégration Continue et du Déploiement Continu (CI/CD) et serez capable de mettre en œuvre un pipeline multi-étapes avec GitHub Actions. Vous apprendrez à rédiger des workflows pour les tests automatisés, la construction d'images Docker et le déploiement d'applications. Vous repartirez avec du code YAML fonctionnel pour tester, construire et déployer vos propres projets, qu'il s'agisse d'applications Python, Node.js ou conteneurisées.

Comprendre les fondamentaux de GitHub Actions

GitHub Actions est une plateforme d'automatisation pilotée par les événements, intégrée directement dans les dépôts GitHub. Elle permet d'exécuter des workflows automatisés déclenchés par des événements comme push, pull_request ou release. À la base, un workflow est défini dans un fichier YAML situé dans le répertoire .github/workflows/ et se compose d'un ou plusieurs jobs qui s'exécutent en parallèle par défaut, chacun contenant une série d'étapes.

Composants principaux

• Événement (on) : Le déclencheur qui lance le workflow, comme push vers une branche spécifique ou un pull_request.
• Runner (runs-on) : La machine sur laquelle le job s'exécute. ubuntu-latest est le choix le plus courant et recommandé pour ses performances et sa large disponibilité logicielle.
• Étapes : Tâches individuelles au sein d'un job. Il peut s'agir de scripts shell (run) ou d'actions pré-construites (uses) provenant du GitHub Marketplace.
• Actions : Unités de code réutilisables, comme actions/checkout@v4 pour cloner votre dépôt ou actions/setup-node@v4 pour installer Node.js.

Un workflow de base pour commencer

Le workflow le plus simple peut être déclenché à chaque push. Créez un fichier à .github/workflows/main.yml pour exécuter une commande "Hello World" basique.

name: exemple
on: push
jobs:
  salutation:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Bonjour, monde CI/CD !"

Après avoir commité et poussé ce fichier dans votre dépôt, vous pouvez visualiser la sortie du job dans l'onglet "Actions" de votre dépôt GitHub.

Construire un pipeline CI complet

La partie "CI" d'un pipeline garantit que les modifications de code sont automatiquement testées et vérifiées avant d'être fusionnées. Cela implique généralement du linting, de la vérification de types et l'exécution de tests unitaires.

Le fichier de workflow CI

Créez .github/workflows/ci.yml. Ce workflow se déclenche à chaque push et pull_request sur la branche main. L'exemple ci-dessous montre un pipeline complet pour un projet Node.js, mais le modèle s'applique à d'autres langages, comme Python avec actions/setup-python.

name: Pipeline CI

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

jobs:
  lint:
    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

  test:
    runs-on: ubuntu-latest
    needs: lint
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

  build:
    runs-on: ubuntu-latest
    needs: [lint, test]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run build

Fonctionnalités clés expliquées

1. Mise en cache des dépendances : L'option cache: 'npm' dans actions/setup-node accélère considérablement le workflow en réutilisant les dépendances des exécutions précédentes.
2. Dépendances entre jobs : Le mot-clé needs définit l'ordre d'exécution. Par exemple, le job build ne s'exécute que si les jobs lint et test réussissent. Cela évite de perdre du temps à construire du code cassé.
3. Variables d'environnement : Pour des services comme les bases de données, vous pouvez définir des variables d'environnement. Par exemple, un job test peut démarrer un conteneur de service PostgreSQL et utiliser env pour s'y connecter.

Scénarios avancés : Déploiements conteneurisés et multi-environnements

Pour les applications modernes, le pipeline implique souvent la construction d'images conteneurisées et leur déploiement. Le tableau suivant présente les stratégies de déploiement courantes et leurs déclencheurs.

Comparaison des déclencheurs de déploiement

Stratégie	Déclencheurs de déploiement	Idéal pour
Basée sur les branches	push vers main	Déploiement continu du dernier code de développement.
Basée sur les tags	push d'un nouveau tag (ex. v1.0.0)	Publication de logiciels stables et versionnés en production.
Basée sur les releases	release publiée sur GitHub	Versions officielles du produit qui génèrent également des notes de version.

Exemple : Déploiement d'un conteneur Docker avec un workflow CI/CD

Cet exemple complet montre un pipeline qui teste une application Python, construit une image Docker et la pousse vers un registre. Il utilise une série d'actions Docker officielles pour une construction sécurisée et performante.

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

name: Pipeline CI/CD complet

on:
  push:
    branches: [ main ]
  release:
    types: [published]

env:
  DOCKER_HUB_USERNAME: ${{ secrets.DOCKER_HUB_USERNAME }}
  DOCKER_HUB_TOKEN: ${{ secrets.DOCKER_HUB_TOKEN }}
  IMAGE_NAME: my-app

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v4
        with:
          python-version: '3.9'
      - run: pip install -r requirements.txt
      - run: pytest

  build-and-push:
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push' || github.event_name == 'release'
    steps:
      - uses: actions/checkout@v4
      - name: Configurer Docker Buildx
        uses: docker/setup-buildx-action@v3
      - name: Connexion à Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ env.DOCKER_HUB_USERNAME }}
          password: ${{ env.DOCKER_HUB_TOKEN }}
      - name: Extraire les métadonnées
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.DOCKER_HUB_USERNAME }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch
            type=semver,pattern={{version}}
            type=raw,value=latest,enable={{is_default_branch}}
      - name: Construire et pousser
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  deploy:
    runs-on: ubuntu-latest
    needs: build-and-push
    if: github.event_name == 'release'
    steps:
      - name: Exécuter le script de déploiement
        run: |
          echo "Déploiement de l'image ${{ env.DOCKER_HUB_USERNAME }}/${{ env.IMAGE_NAME }}:${{ github.event.release.tag_name }}"

Important : Gestion des secrets

Pour que le workflow ci-dessus fonctionne, vous devez stocker vos identifiants de manière sécurisée dans votre dépôt GitHub. Accédez à Paramètres > Secrets et variables > Actions et ajoutez les secrets suivants :

1. DOCKER_HUB_USERNAME : Votre nom d'utilisateur Docker Hub.
2. DOCKER_HUB_TOKEN : Un jeton d'accès personnel Docker Hub avec des autorisations de lecture/écriture.

⚠️ Avertissement de sécurité : Ne codez jamais en dur des mots de passe, jetons ou autres données sensibles directement dans vos fichiers YAML. Utilisez toujours les secrets GitHub, qui sont chiffrés et accessibles uniquement pendant l'exécution des workflows.

Questions fréquentes

Quelles sont les premières étapes pour configurer un pipeline CI/CD avec GitHub Actions ?

Pour commencer, créez un répertoire .github/workflows dans votre dépôt. À l'intérieur, créez un fichier YAML (par exemple ci.yml) et définissez votre name, on (événements déclencheurs comme push) et jobs (les tâches à exécuter). Commitez et poussez ce fichier pour démarrer votre premier workflow automatisé.

Puis-je utiliser GitHub Actions pour exécuter des tests sur les pull requests ?

Oui, tester les pull requests est un cas d'usage fondamental. En définissant le déclencheur on sur pull_request pour la branche main, le workflow s'exécutera automatiquement sur chaque nouvelle pull request, garantissant la qualité du code avant la fusion.

Comment construire et pousser une image Docker avec un workflow GitHub Actions ?

Vous pouvez utiliser des actions composites officielles comme docker/login-action, docker/setup-buildx-action et docker/build-push-action. Cela simplifie le processus, gère automatiquement l'authentification et active des fonctionnalités comme la mise en cache de la construction et les constructions multi-plateformes.

Est-il possible de déployer sur GitHub Pages avec GitHub Actions ?

Oui. Vous pouvez utiliser l'action communautaire JamesIves/github-pages-deploy-action. Vous la configurez avec le dossier contenant votre site construit, et elle gère les opérations git pour commiter et pousser les modifications vers la branche gh-pages.

Quelle est la différence entre un déclencheur d'événement push et release ?

Un événement push déclenche le workflow chaque fois que du code est poussé vers une branche spécifiée. Un événement release se déclenche lorsqu'une release GitHub est publiée. push est généralement utilisé pour l'IC et les déploiements de staging, tandis que release est souvent utilisé pour le déploiement en production.

Sources

• Configurer un pipeline CI/CD GitHub Actions · Issue #176 (Exemples YAML pratiques pour CI, E2E et déploiement)
• DevOps : Configurer un pipeline CI/CD GitHub Actions · Issue #19 (Montre le linting, la vérification de types et la validation de construction)
• GitHub - kamrun111/GitHubActionTest (Un exemple CI/CD Python simple et adapté aux débutants)
• @jamesives/github-pages-deploy-action (Documentation pour le déploiement sur GitHub Pages)
• GitHub - CarlosQuintero8/cicdsimulation (Montre un pipeline multi-étapes avec tests, construction et déploiement sur GitHub Pages)
• GitHub - anuragstark/Py-app-CI-CD-Pipeline- (Guide complet incluant le déploiement Docker et Minikube)
• CI/CD automatisé avec GitHub Actions, en partant de zéro (Un tutoriel pour construire progressivement des workflows CI/CD)
• Étendre l'application avec GitHub Actions · Documentation AccelByte (Exemple de déploiement déclenché par un événement release)
• Configurer CI/CD pour votre application C++ · Documentation Docker (Montre la configuration de GitHub Actions avec Docker Hub)
• Bonjour monde CI · Formation HSF (Un tutoriel de base pour créer et exécuter un premier workflow)

— Editorial Team