CI/CD — Intégration et Déploiement Continus

Pipelines d'intégration continue, tests automatisés et stratégies de déploiement : blue-green, canary et rolling updates.

Qu’est-ce que le CI/CD ?

Le CI/CD (Continuous Integration / Continuous Delivery ou Deployment) est un ensemble de pratiques qui automatisent le processus d’acheminement du code depuis le dépôt jusqu’à la production.

CI (Intégration Continue) : chaque modification de code est intégrée fréquemment, compilée et testée automatiquement
CD (Livraison Continue) : le code qui passe la CI est toujours prêt à être déployé en production
CD (Déploiement Continu) : le code est déployé automatiquement en production sans intervention manuelle

Pipeline de CI/CD

Un pipeline est une séquence d’étapes automatisées que le code traverse depuis le commit jusqu’à la production.

Étapes typiques

Commit → Build → Test → Analyse → Artefact → Deploy Staging → Deploy Production

Build : compiler le code, générer les artefacts
Tests unitaires : exécuter des tests rapides qui valident la logique
Tests d’intégration : vérifier que les composants fonctionnent ensemble
Analyse statique : linting, type checking, analyse de sécurité
Construction de l’artefact : créer une image Docker, un paquet, etc.
Deploy vers staging : déployer automatiquement pour les tests finaux
Deploy vers production : déployer avec la stratégie choisie

Exemple avec GitHub Actions

name: CI/CD Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

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

  deploy-staging:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build Docker image
        run: docker build -t my-app:${{ github.sha }} .
      - name: Push to registry
        run: docker push my-app:${{ github.sha }}
      - name: Deploy to staging
        run: kubectl set image deployment/my-app my-app=my-app:${{ github.sha }} -n staging

Tests automatisés en CI

Les tests sont la colonne vertébrale de la CI. Sans tests fiables, l’automatisation n’a aucun sens.

Pyramide des tests en CI

Tests unitaires (nombreux, rapides) : valident les fonctions et modules individuels
Tests d’intégration (modérés) : valident la communication entre les composants
Tests end-to-end (peu nombreux, lents) : valident les parcours utilisateur complets

Bonnes pratiques

Les tests doivent être déterministes : le même code produit toujours le même résultat
Les tests doivent être rapides : un pipeline lent décourage l’intégration fréquente
Les tests doivent être indépendants : ne dépendre ni de l’ordre d’exécution ni d’un état partagé
Utiliser la parallélisation pour réduire le temps total du pipeline

Stratégies de déploiement

Rolling update

La stratégie par défaut dans Kubernetes. Elle remplace progressivement les anciennes instances par les nouvelles.

Avantage : ne nécessite aucune infrastructure supplémentaire
Inconvénient : pendant la mise à jour, deux versions coexistent
Rollback : automatique si les health checks échouent

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Blue-Green deployment

Maintient deux environnements identiques : Blue (actuel) et Green (nouveau). Le trafic est redirigé de Blue vers Green lorsque Green est prêt.

Avantage : rollback instantané (retour à Blue)
Inconvénient : nécessite le double d’infrastructure pendant le déploiement
Idéal pour : les changements importants ou les migrations de base de données

Canary deployment

Déploie la nouvelle version d’abord auprès d’un petit pourcentage d’utilisateurs. Si tout se passe bien, on l’augmente progressivement jusqu’à 100 %.

Avantage : risque minimal, détection précoce des problèmes
Inconvénient : plus complexe à implémenter et à monitorer
Idéal pour : les changements risqués ou les fonctionnalités expérimentales

Phase 1 : 5 % du trafic → nouvelle version
Phase 2 : 25 % du trafic → nouvelle version
Phase 3 : 50 % du trafic → nouvelle version
Phase 4 : 100 % du trafic → nouvelle version

Feature flags

Ce n’est pas une stratégie de déploiement à proprement parler, mais elle complète les précédentes. Elle permet d’activer ou de désactiver des fonctionnalités sans redéployer.

Le nouveau code est déployé mais désactivé par défaut
Il est activé progressivement pour des utilisateurs spécifiques
En cas de problème, il est désactivé sans rollback

Bonnes pratiques de CI/CD

Faire des commits petits et fréquents : facilite la détection des erreurs
Le pipeline doit être rapide : idéalement moins de 10 minutes pour la CI
Ne jamais contourner le pipeline : chaque changement passe par la CI, sans exception
Artefacts immuables : le même artefact est promu d’un environnement à l’autre
Monitorer les déploiements : alertes automatiques si quelque chose échoue après le déploiement
Automatiser les rollbacks : si les métriques se dégradent, revenir en arrière automatiquement

Résumé

Le CI/CD automatise le chemin du code vers la production. L’intégration continue garantit que chaque changement est validé automatiquement, tandis que les stratégies de déploiement (rolling, blue-green, canary) permettent d’acheminer les changements en production avec confiance et un risque minimal.