Livrer plus vite avec des pipelines automatisés : CI/CD avec GitHub Actions

GitHub Actions automatise les workflows logiciels directement dans votre dépôt. Ce guide couvre les fondamentaux du CI/CD, la structure des workflows et les patterns de production pour construire, tester et déployer des applications.

Qu'est-ce que le CI/CD ?

Le CI/CD est un ensemble de pratiques qui automatisent le processus de livraison logicielle. Il garantit que les modifications de code sont automatiquement testées, validées et déployées avec un minimum d'intervention manuelle.

VUE D'ENSEMBLE DU PIPELINE CI/CD

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│   Code   │    │ Build    │    │  Tests   │    │Déploie-  │
│  Poussé  │───▶│ Étape    │───▶│  Étape   │───▶│  ment    │
│          │    │          │    │          │    │  Étape   │
└──────────┘    └──────────┘    └──────────┘    └──────────┘
     │               │               │               │
     │               │               │               │
     ▼               ▼               ▼               ▼
  Déclenche      Compile         Lance les      Production
  Pipeline       Assets          tests          Staging
                 Bundle          Lint           Review
                                 Type Check

Intégration continue (CI)

La CI construit et teste automatiquement les modifications de code lorsque les développeurs poussent vers le dépôt. Elle détecte les bugs tôt en validant chaque commit.

• Builds automatisés : Compiler et bundler le code à chaque push
• Tests automatisés : Lancer les tests unitaires, d'intégration et end-to-end
• Qualité du code : Lint, formatage et vérification des types
• Feedback rapide : Les développeurs savent en quelques minutes si leurs modifications ont cassé quelque chose

Livraison continue (CD)

La CD étend la CI en déployant automatiquement le code validé vers des environnements de staging ou de production. La différence entre Livraison et Déploiement :

• Livraison continue : Le code est toujours déployable, mais nécessite une approbation manuelle
• Déploiement continu : Chaque modification validée se déploie automatiquement en production

Fondamentaux de GitHub Actions

GitHub Actions est une plateforme CI/CD intégrée directement dans GitHub. Les workflows sont définis dans des fichiers YAML et déclenchés par des événements du dépôt.

ARCHITECTURE DE GITHUB ACTIONS

┌─────────────────────────────────────────────────────────────┐
│                          Dépôt                              │
│                                                             │
│   .github/workflows/                                        │
│   ├── ci.yml   ──▶  Déclenché sur pull_request              │
│   └── cd.yml   ──▶  Déclenché sur push vers main            │
│                                                             │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                     GitHub Runners                          │
│                                                             │
│   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐       │
│   │   ubuntu    │   │   windows   │   │    macos    │       │
│   │   latest    │   │   latest    │   │   latest    │       │
│   └─────────────┘   └─────────────┘   └─────────────┘       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Structure d'un workflow

Un workflow est composé de déclencheurs, de jobs et d'étapes. Les jobs s'exécutent sur des runners (machines virtuelles), et les étapes exécutent des commandes ou des actions.

name: Nom du Workflow

on:                          # Déclencheurs
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  nom-du-job:                # Définition du job
    runs-on: ubuntu-latest   # Runner

    steps:                   # Étapes séquentielles
      - name: Nom de l'étape
        uses: action@version # Utiliser une action

      - name: Lancer une commande
        run: npm test        # Lancer une commande shell

Déclencheurs de workflows

Les workflows sont déclenchés par des événements dans votre dépôt.

on:
  # Push sur des branches spécifiques
  push:
    branches: [main, develop]

  # Événements de pull request
  pull_request:
    branches: [main]
    types: [opened, synchronize, reopened]

  # Après la fin d'un autre workflow
  workflow_run:
    workflows: [CI]
    types: [completed]

Variables d'environnement et secrets

Les secrets stockent les données sensibles. Les variables d'environnement configurent le comportement du workflow.

jobs:
  deploy:
    runs-on: ubuntu-latest

    env:
      # Variables au niveau du workflow
      NODE_ENV: production
      REGISTRY: ${{ secrets.CONTAINER_REGISTRY }}

    steps:
      - name: Déployer
        env:
          # Variables au niveau de l'étape
          API_KEY: ${{ secrets.API_KEY }}
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
        run: |
          echo "Déploiement vers $NODE_ENV"
          ./deploy.sh

Pattern de workflow CI

Un workflow CI valide le code à chaque pull request. Il construit le projet, lance les tests et rapporte les résultats.

FLUX DU WORKFLOW CI

Pull Request
     │
     ▼
┌────────────────────────────────────────────────────────────────┐
│                         Pipeline CI                            │
│                                                                │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐     │
│  │ Checkout │──▶│ Installer│──▶│   Lint   │──▶│  Build   │     │
│  │   Code   │   │   Dép.   │   │   Code   │   │  Projet  │     │
│  └──────────┘   └──────────┘   └──────────┘   └──────────┘     │
│                                                    │           │
│                                                    ▼           │
│                                              ┌──────────┐      │
│                                              │  Suite   │      │
│                                              │  Tests   │      │
│                                              └──────────┘      │
│                                                    │           │
└────────────────────────────────────────────────────┼───────────┘
                                                     ▼
                                            ✓ Fusion autorisée
                                            ✗ Fusion bloquée

Workflow CI complet

name: CI

on:
  pull_request:
    branches:
      - main

jobs:
  build:
    name: Build and Test
    timeout-minutes: 15
    runs-on: ubuntu-latest

    env:
      TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
      TURBO_TEAM: ${{ vars.TURBO_TEAM }}
      TURBO_REMOTE_ONLY: true

    steps:
      - name: Check out code
        uses: actions/checkout@v4

      - name: Cache turbo build setup
        uses: actions/cache@v4
        with:
          path: .turbo
          key: ${{ runner.os }}-turbo-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-turbo-

      - name: Setup Node.js environment
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Build
        run: npm run build

      - name: Test
        run: npm run test

Mise en cache avec Turborepo

Le cache distant de Turborepo partage les artefacts de build entre les exécutions CI et les développeurs. Quand une exécution construit un package, les exécutions suivantes sautent la reconstruction.

• TURBO_TOKEN : Authentification pour le cache distant Vercel
• TURBO_TEAM : Identifiant de l'équipe ou de l'organisation
• TURBO_REMOTE_ONLY : N'utiliser que le cache distant, ignorer le local
• actions/cache : Met en cache le dossier .turbo pour des restaurations plus rapides

Pattern de workflow CD

Un workflow CD déploie le code validé en production. Il construit des images Docker, les pousse vers un registre, et met à jour les services de conteneurs.

FLUX DU WORKFLOW CD

Push vers Main
     │
     ▼
┌──────────────────────────────────────────────────────────────┐
│                      Pipeline CD                             │
│                                                              │
│  ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   │
│  │ Checkout │──▶│  Build   │──▶│  Push    │──▶│ Déploie- │   │
│  │   Code   │   │  Docker  │   │ Registre │   │  ment    │   │
│  └──────────┘   └──────────┘   └──────────┘   └──────────┘   │
│                      │                             │         │
│                      ▼                             ▼         │
│               ┌────────────┐                ┌────────────┐   │
│               │ Tag avec   │                │  Redémarrer│   │
│               │ Commit SHA │                │  Services  │   │
│               └────────────┘                └────────────┘   │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Workflow CD complet

name: CD

on:
  push:
    branches:
      - main

jobs:
  deploy:
    name: Deploy to Azure
    runs-on: ubuntu-latest

    env:
      TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
      TURBO_TEAM: ${{ vars.TURBO_TEAM }}
      AZURE_CONTAINER_REGISTRY: ${{ secrets.AZURE_CONTAINER_REGISTRY }}
      AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
      REGISTRY_USERNAME: ${{ secrets.REGISTRY_USERNAME }}
      REGISTRY_PASSWORD: ${{ secrets.REGISTRY_PASSWORD }}

    steps:
      - name: Check out code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install dependencies
        run: npm ci

      - name: Azure Login
        uses: azure/login@v2
        with:
          creds: '{"clientId":"${{ secrets.AZURE_CLIENT_ID }}","clientSecret":"${{ secrets.AZURE_CLIENT_SECRET }}","tenantId":"${{ secrets.AZURE_TENANT_ID }}"}'

      - name: Build Docker Image
        run: |
          docker build --platform=linux/amd64 \
            -t my-service \
            -f apps/my-service/Dockerfile .

          docker tag my-service \
            ${{ env.AZURE_CONTAINER_REGISTRY }}/my-service:${{ github.sha }}

      - name: Login to ACR
        run: |
          az acr login --name ${{ env.REGISTRY_USERNAME }}

      - name: Push to Registry
        run: |
          docker push ${{ env.AZURE_CONTAINER_REGISTRY }}/my-service:${{ github.sha }}

      - name: Deploy to Container Apps
        run: |
          az containerapp update \
            --name my-service \
            --resource-group my-project \
            --image ${{ env.AZURE_CONTAINER_REGISTRY }}/my-service:${{ github.sha }}

Déploiement initial versus mises à jour

Utilisez az containerapp create pour le déploiement initial, puis az containerapp update pour les déploiements suivants.

# Déploiement initial avec configuration complète
- name: Create Container App
  run: |
    az containerapp create \
      --name my-service \
      --resource-group my-project \
      --environment my-environment \
      --image ${{ env.REGISTRY }}/my-service:${{ github.sha }} \
      --target-port 3000 \
      --ingress external \
      --min-replicas 1 \
      --max-replicas 10 \
      --env-vars \
        DATABASE_URL=${{ secrets.DATABASE_URL }} \
        REDIS_HOST=${{ secrets.REDIS_HOST }}

# Déploiements suivants (mise à jour de l'image uniquement)
- name: Update Container App
  run: |
    az containerapp update \
      --name my-service \
      --resource-group my-project \
      --image ${{ env.REGISTRY }}/my-service:${{ github.sha }}

Stratégies de taguage des images

Un taguage approprié des images permet la traçabilité et le retour arrière.

• ${{ github.sha }} : Hash de commit unique pour un suivi de version exact
• latest : Pointe toujours vers le build le plus récent
• v1.0.0 : Versionnage sémantique pour les releases
• ${{ github.ref_name }} : Nom de branche pour les builds spécifiques à l'environnement

- name: Tag Image
  run: |
    # Commit SHA (recommandé pour la traçabilité)
    docker tag my-service $REGISTRY/my-service:${{ github.sha }}

    # Tag latest
    docker tag my-service $REGISTRY/my-service:latest

    # Tag basé sur la branche
    docker tag my-service $REGISTRY/my-service:${{ github.ref_name }}

Bonnes pratiques

Sécurité

• Ne jamais coder les secrets en dur : Utilisez les GitHub Secrets pour les valeurs sensibles
• Moindre privilège : Les principaux de service doivent avoir les permissions minimales requises
• Épingler les versions des actions : Utilisez les SHA de commits plutôt que les tags pour les actions tierces
• Auditer les workflows : Examinez les modifications de workflow dans les pull requests

Performance

• Mettre en cache les dépendances : Réduisez le temps d'installation avec actions/cache
• Cache distant : Partagez les artefacts de build entre les exécutions avec Turborepo
• Jobs parallèles : Exécutez les jobs indépendants en parallèle
• Limites de délai d'attente : Définissez des délais raisonnables pour échouer rapidement

Fiabilité

• Déploiements idempotents : Exécuter le même workflow deux fois doit produire le même résultat
• Stratégie de retour arrière : Taguez les images avec le SHA de commit pour un retour arrière facile
• Vérifications de santé : Vérifiez que les déploiements ont réussi avant de les marquer comme terminés
• Notifications : Alertez en cas d'échec via Slack, e-mail ou GitHub Issues

Maintenabilité

• Noms descriptifs : Utilisez des noms clairs pour les jobs et les étapes afin de faciliter le débogage
• Documentation : Commentez la logique de workflow complexe
• Contrôle de version : Les workflows sont du code — examinez-les comme du code

Conclusion

GitHub Actions fournit une plateforme CI/CD complète intégrée directement dans votre dépôt. Les workflows CI valident chaque modification avec des builds et des tests automatisés, détectant les bugs avant qu'ils n'atteignent la production. Les workflows CD automatisent le déploiement, réduisant les erreurs manuelles et permettant des releases fréquentes.

La combinaison du cache distant de Turborepo et du cache intégré de GitHub Actions réduit considérablement les temps de build. Pour les applications containerisées, le workflow du push de code au registre de conteneurs jusqu'au déploiement en production devient entièrement automatisé et traçable grâce aux tags d'images basés sur les commits.

Que vous déployiez un service unique ou orchestriez plusieurs microservices, ces patterns s'adaptent des projets simples aux systèmes de production complexes.

Lectures complémentaires

Ces articles étendent les concepts CI/CD abordés ici vers la containerisation et le déploiement cloud :

• Du code au conteneur : un guide Docker de production — les builds Docker multi-étapes et l'orchestration Compose qui alimentent les pipelines GitHub Actions décrits ci-dessus.
• Comment nous avons déployé et mis à l'échelle sur Azure : un guide de production — comment le workflow CD GitHub Actions se connecte à Azure Container Apps pour compléter le pipeline de déploiement sans étape manuelle.

Découvrez comment ces patterns CI/CD sont appliqués dans les projets d'infrastructure réalisés par Brahim Boumlik.