Stratégies de déploiement : blue-green, canary et rollback

Une stratégie de déploiement est la manière de remplacer l'ancienne version d'une application par la nouvelle en production : d'un seul coup, instance par instance, en basculant entre deux environnements (blue-green) ou en exposant d'abord une petite partie des utilisateurs (canary). Elle détermine la coupure de service, le risque pris et la vitesse du retour arrière (rollback). Ce chapitre compare ces stratégies, présente les interrupteurs de fonctionnalité, puis détaille comment revenir en arrière quand un déploiement se passe mal.

Recréation : arrêter, puis démarrer

La stratégie la plus simple : on arrête l'ancienne version, puis on démarre la nouvelle. C'est ce que fait docker compose up -d dans le script du chapitre 11.

• Avantage : simple, une seule version tourne à la fois, aucune question de compatibilité entre versions.
• Inconvénient : une coupure, de quelques secondes à quelques minutes, et un retour arrière qui demande un nouveau redémarrage.
• Quand : une application interne, déployée hors des heures de travail ; un projet de BTS.

Déploiement progressif (rolling update)

L'application tourne sur plusieurs instances derrière un répartiteur de charge (load balancer). On remplace les instances une par une : on en retire une du répartiteur, on la met à jour, on vérifie qu'elle répond, on la remet, puis on passe à la suivante.

• Avantage : pas de coupure, pas de matériel en plus.
• Inconvénient : pendant le déploiement, les deux versions servent des utilisateurs en même temps ; elles doivent être compatibles (même API, même schéma de base). Un retour arrière refait le même chemin à l'envers, instance par instance.
• Quand : c'est la stratégie par défaut de Kubernetes (réglages maxSurge et maxUnavailable d'un Deployment) et de Docker Swarm.

Bleu-vert (blue-green)

On maintient deux environnements de production identiques, le bleu et le vert. Un seul reçoit le trafic. On déploie la nouvelle version sur celui qui est au repos, on le teste tranquillement, puis on bascule tout le trafic d'un coup en changeant la configuration du répartiteur.

Sur un seul serveur, avec Nginx en frontal, le bleu peut écouter sur le port 3001 et le vert sur le port 3002. La bascule consiste à changer une ligne et à recharger Nginx, sans coupure :

# /etc/nginx/conf.d/sorbier-frais-upstream.conf
upstream sorbier_frais {
    server 127.0.0.1:3002;   # vert, en service ; le bleu (3001) garde l'ancienne version
}

sudo nginx -t && sudo systemctl reload nginx   # vérifie la configuration, puis la recharge sans couper les connexions

• Avantage : bascule instantanée, et retour arrière instantané : on rebascule vers l'environnement précédent, toujours démarré.
• Inconvénient : deux environnements à maintenir (le double de ressources pendant le déploiement), et la base de données est généralement partagée : le nouveau schéma doit rester compatible avec l'ancienne version, d'où les migrations par expansion puis contraction (les migrations).
• Quand : une application où une coupure coûte cher et où l'on veut un retour arrière en quelques secondes.

Canari (canary)

Le nom vient des canaris que les mineurs emportaient au fond des galeries : l'oiseau, plus sensible, signalait le gaz avant les hommes. On déploie la nouvelle version sur une petite partie de l'infrastructure, qui reçoit une petite part du trafic (1 %, 5 %, 10 %). On compare ses indicateurs (taux d'erreurs, temps de réponse) à ceux de l'ancienne version. Si tout va bien, on augmente progressivement la part (25 %, 50 %, 100 %) ; sinon, on retire le canari, et seule une petite partie des utilisateurs a été touchée.

Avec Nginx, des poids sur les serveurs de l'upstream suffisent pour un premier canari :

upstream sorbier_frais {
    server 127.0.0.1:3001 weight=9;   # ancienne version : 9 requêtes sur 10
    server 127.0.0.1:3002 weight=1;   # canari : 1 requête sur 10, soit 10 %
}

• Avantage : le risque est limité à une fraction des utilisateurs, et la décision repose sur des mesures réelles.
• Inconvénient : il faut une supervision fine, capable de comparer les deux versions, et un routage du trafic pondéré ; les deux versions coexistent longtemps.
• Quand : des applications à fort trafic, où les mesures sont significatives. Les outils comme Argo Rollouts (Kubernetes) automatisent les paliers et le retour arrière selon les indicateurs.

Comparer les stratégies

Les interrupteurs de fonctionnalité

Un interrupteur de fonctionnalité (feature flag, feature toggle) est une condition dans le code, pilotée par la configuration, qui active ou désactive une fonctionnalité sans redéployer :

if (await drapeaux.estActif('export-pdf', utilisateur)) {
  routeur.get('/notes/:id/pdf', exporterPdf);
}

Ils séparent le déploiement de la mise à disposition : le code de l'export PDF part en production désactivé, avec les autres changements ; on l'active ensuite pour l'équipe comptable seulement, puis pour tout le monde. Si un problème apparaît, on coupe l'interrupteur en quelques secondes : c'est un retour arrière de la fonctionnalité, sans toucher au reste.

Des outils libres (Unleash, GrowthBook) et le standard ouvert OpenFeature fournissent les interrupteurs, leur interface d'administration et leur historique. Un simple réglage dans la configuration suffit pour commencer. Le revers : chaque interrupteur ajoute un if ; on le supprime du code une fois la fonctionnalité stabilisée, sinon ils s'accumulent en dette technique.

Revenir en arrière : le rollback

Un retour arrière (rollback) remet en service la dernière version qui fonctionnait. Quand la production va mal après un déploiement, la règle est simple : d'abord rétablir le service, ensuite comprendre. On ne débogue pas en direct sur la production.

Un workflow de retour arrière, lancé à la main avec la version voulue :

name: Retour arrière

on:
  workflow_dispatch:
    inputs:
      version:
        description: Étiquette de l'image à redéployer, par exemple sha-3f9c2e1
        required: true
        type: string
      environnement:
        description: Environnement cible
        type: choice
        options: [recette, production]
        default: production

permissions:
  contents: read

jobs:
  rollback:
    runs-on: ubuntu-latest
    environment: ${{ inputs.environnement }}
    steps:
      - name: Vérifier l'étiquette
        env:
          VERSION: ${{ inputs.version }}
        run: |
          [[ "$VERSION" =~ ^(sha-[0-9a-f]{7}|[0-9]+\.[0-9]+\.[0-9]+)$ ]] || { echo "Étiquette invalide"; exit 1; }
      - name: Préparer la connexion SSH
        env:
          SSH_KEY: ${{ secrets.DEPLOY_SSH_KEY }}
          KNOWN_HOSTS: ${{ vars.DEPLOY_KNOWN_HOSTS }}
        run: |
          install -m 700 -d ~/.ssh
          printf '%s\n' "$SSH_KEY" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519
          printf '%s\n' "$KNOWN_HOSTS" > ~/.ssh/known_hosts
      - name: Redéployer
        env:
          VERSION: ${{ inputs.version }}
          DEPLOY_HOST: ${{ vars.DEPLOY_HOST }}
        run: ssh "deploy@$DEPLOY_HOST" "MIGRER=non /opt/sorbier-frais/deployer.sh $VERSION"

MIGRER=non dit au script de ne pas lancer les migrations : l'ancienne version ne connaît pas les migrations les plus récentes, déjà appliquées, et certains outils (Knex, par exemple) refusent alors de s'exécuter, ce qui ferait échouer le retour arrière lui-même. L'environnement production garde ses règles : un retour arrière en production demande aussi une approbation. La valeur saisie passe par une variable d'environnement et est vérifiée avant usage, comme toute donnée fournie par une personne (l'injection de script).

Et la base de données ? Revenir à l'ancien code est facile ; revenir à l'ancien schéma l'est beaucoup moins. Les migrations « descendantes » (down) qui suppriment une colonne détruisent les données écrites entre-temps. D'où trois règles : des migrations compatibles avec la version précédente (expansion, puis contraction), une sauvegarde avant chaque migration en production, et la restauration de cette sauvegarde seulement en dernier recours, en sachant qu'elle efface tout ce qui a été saisi depuis (sauvegarde et PRA).

Après l'incident : le post-mortem

Une fois le service rétabli, l'équipe écrit un court post-mortem : la chronologie (déploiement à 14 h 02, premières erreurs à 14 h 05, retour arrière à 14 h 11), l'impact (combien d'utilisateurs, combien de temps), la cause, et surtout les actions pour que cela ne se reproduise pas : un test ajouté, un contrôle de santé plus complet, une étape de pipeline en plus. Il est sans reproche (blameless) : on cherche ce qui, dans le processus, a laissé passer l'erreur, pas un coupable. C'est la même démarche que la gestion des incidents d'ITIL (gestion des incidents) et que le retour d'expérience après un incident de sécurité (réponse aux incidents).

Exercices