Stratégies de Déploiement¶

Comprendre les différentes stratégies pour mettre à jour une application en production, leurs compromis et les contextes ou chacune s'applique.

Recreate¶

La stratégie la plus simple : on arrêté l'ancienne version, puis on démarré la nouvelle. Il y a une interruption de service pendant la transition.

sequenceDiagram
    participant U as Utilisateurs
    participant LB as Load Balancer
    participant V1 as Version 1
    participant V2 as Version 2

    U->>LB: requetes
    LB->>V1: trafic normal
    Note over V1,V2: Arret de V1
    LB-->>U: 503 Service Unavailable
    Note over V1,V2: Demarrage de V2
    LB->>V2: trafic reprend
    U->>LB: requetes

Quand l'utiliser : environnements de dev/staging, applications avec peu d'utilisateurs, migrations de base de données incompatibles avec le rolling.

Rolling¶

Le déploiement progressif remplacé les instances une par une (ou par groupe). À tout moment, des instances de l'ancienne et de la nouvelle version coexistent.

graph LR
    subgraph "Etape 1 — debut"
        A1["Pod V1"] 
        A2["Pod V1"]
        A3["Pod V1"]
    end
    subgraph "Etape 2 — en cours"
        B1["Pod V2"]
        B2["Pod V1"]
        B3["Pod V1"]
    end
    subgraph "Etape 3 — termine"
        C1["Pod V2"]
        C2["Pod V2"]
        C3["Pod V2"]
    end
    A1 --> B1
    A2 --> B2
    A3 --> B3
    B1 --> C1
    B2 --> C2
    B3 --> C3

Quand l'utiliser : applications stateless, API REST sans changement cassant du schéma de base de données.

Blue/Green¶

Deux environnements identiques coexistent en permanence : Blue (version courante) et Green (nouvelle version). Le basculement du trafic est instantané.

graph TB
    LB["Load Balancer"]
    subgraph "Environnement Blue — actif"
        B1["Instance Blue"]
        B2["Instance Blue"]
    end
    subgraph "Environnement Green — en attente"
        G1["Instance Green"]
        G2["Instance Green"]
    end
    LB -->|"100% du trafic"| B1
    LB -->|"100% du trafic"| B2
    LB -.->|"Bascule instantanee"| G1
    LB -.->|"Bascule instantanee"| G2

Le rollback est immédiat : on rebascule le load balancer vers Blue. Green reste disponible pour debugging.

Quand l'utiliser : applications critiques ou le downtime zero est obligatoire, releases importantes avec risque de régression.

Canary¶

Le trafic est redirige progressivement vers la nouvelle version : d'abord un petit pourcentage, puis on augmente si tout va bien.

graph LR
    U["Utilisateurs"] --> LB["Load Balancer"]
    subgraph "Phase 1 — 10% canary"
        LB -->|"90%"| V1a["V1"]
        LB -->|"10%"| V2a["V2 canary"]
    end
    subgraph "Phase 2 — 50% canary"
        LB2["Load Balancer"] -->|"50%"| V1b["V1"]
        LB2 -->|"50%"| V2b["V2"]
    end
    subgraph "Phase 3 — 100%"
        LB3["Load Balancer"] -->|"100%"| V2c["V2"]
    end

On surveille les métriques (taux d'erreur, latence, alertes métier) sur le segment canary avant de progresser. Si une anomalie est détectée, on ramene le canary a 0%.

Quand l'utiliser : nouvelles fonctionnalités a fort impact, changements de performance, A/B testing.

Comparatif¶

Arbre de décision¶

graph TD
    A{"L'app tolere\nun downtime ?"}
    A -->|Oui| B["Recreate"]
    A -->|Non| C{"Schema BDD\ncassant ?"}
    C -->|Oui| D["Blue/Green"]
    C -->|Non| E{"Budget\n2x infra ?"}
    E -->|Oui| F{"Release\ncritique ?"}
    E -->|Non| G["Rolling"]
    F -->|Oui| D
    F -->|Non| H["Canary"]

Outils¶