CI/CD de bout en bout (4/5) : stratégies de déploiement et retour arrière

1. Les stratégies #

Choisir selon le risque et l'infrastructure.

Vue d'ensemble #

Rolling update #

# Kubernetes : jamais moins de 100 % de capacité pendant la mise à jour
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/shop/api:3f9c2e1
          readinessProbe:                     # le trafic n'arrive qu'aux pods prêts
            httpGet: { path: /health, port: 8080 }
            periodSeconds: 5

À savoir : Sans readiness probe, Kubernetes envoie du trafic à un pod qui démarre encore : le rolling update produit alors des erreurs.

Blue/green #

Canary #

# Argo Rollouts : canary avec paliers et analyse automatique
strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 5m }
      - analysis: { templates: [{ templateName: taux-erreur }] }
      - setWeight: 20
      - pause: { duration: 10m }
      - setWeight: 50
      - pause: { duration: 15m }

2. Découpler déploiement et mise en service #

Feature flags et dark launch.

Feature flags #

Un feature flag permet de déployer du code inactif et de l'activer plus tard, pour un pourcentage d'utilisateurs, une région ou les seuls testeurs internes. C'est ce qui rend possible le trunk-based development avec des fonctionnalités inachevées.

if flags.is_enabled("nouveau-panier", user_id=user.id):   # OpenFeature, Unleash, LaunchDarkly, Flagsmith...
    return nouveau_panier(user)
return ancien_panier(user)

Erreur Courante : Chaque drapeau est une dette : supprimez-le dès que la fonctionnalité est activée pour tous, sinon le code accumule des branches mortes difficiles à tester.

Dark launch #

La nouvelle version reçoit une copie du trafic réel (mirroring) sans que ses réponses soient renvoyées aux utilisateurs : on mesure performance et erreurs sans risque.

3. Vérifier et revenir en arrière #

Un déploiement n'est fini que lorsqu'il est vérifié.

Vérifications automatiques #

1. Smoke tests juste après le déploiement : la page d'accueil répond, la connexion fonctionne, l'API de santé est verte.
2. Analyse des métriques pendant la montée en charge : taux d'erreur, latence p95, saturation, comparés à la version précédente.
3. Décision automatique : poursuivre, mettre en pause ou annuler.

# smoke test minimal dans le pipeline
for i in $(seq 1 10); do
  curl -fsS --max-time 3 https://staging.example.com/health && exit 0
  sleep 6
done
echo "smoke test en échec" >&2 ; exit 1

Rollback ou roll forward #

kubectl rollout undo deployment/api
kubectl rollout history deployment/api
helm rollback shop 41
git revert <sha> && git push      # GitOps : l'annulation passe aussi par Git