GitOps et déploiement blue-green / sans interruption

Symptôme

Objectif : déployer les modifications de schéma et d'application sans interruption ; approcher le zéro downtime avec des migrations expand-contract, des environnements blue-green, des feature flags et un retour arrière automatique.

1. GitOps : faites de Git la source unique de vérité

Définissez l'infrastructure, les migrations de schéma et la version de l'application dans Git ; le déploiement est déclenché par un merge dans le dépôt (GitOps). Un réconciliateur (Argo CD/Flux ou CI/CD) applique l'état souhaité à l'environnement réel. Chaque modification est alors auditable, reproductible et peut être ramenée à un commit précédent si nécessaire.

PostgreSQL

# repo/
#   migrations/  (Vxxx__*.sql)
#   k8s/         (Deployment, Service)
#   flags/       (feature flag config)

2. Modifiez le schéma de manière rétrocompatible (expand-contract)

Pour un zéro downtime, ne modifiez pas le schéma en une seule étape cassante ; découpez-la en deux phases. EXPAND : ajoutez la nouvelle structure (nouvelle colonne/table) de sorte que l'ancien et le nouveau code puissent fonctionner en même temps (colonne nullable, avec valeur par défaut, écritures doubles). APRÈS le passage de l'application à la nouvelle structure, CONTRACT : supprimez l'ancienne colonne/table devenue inutile dans une migration séparée. Les anciennes et nouvelles versions de l'application cohabitent alors sans problème pendant le déploiement.

PostgreSQL

-- EXPAND (V5): backward-compatible addition
ALTER TABLE customer ADD COLUMN email text;

-- for a while the code writes/reads both columns

-- CONTRACT (V9): drop the old column
ALTER TABLE customer DROP COLUMN mail_old;

3. Placez les comportements risqués derrière un feature flag

Exécutez le nouveau chemin de code (comme la lecture de la nouvelle colonne) de manière conditionnelle derrière un feature flag ; activez le flag lorsque le schéma est prêt et désactivez-le sans toucher au déploiement en cas de problème. Un flag sépare le déploiement du code (deploy) de l'activation de la fonctionnalité (release). La phase expand est livrée, mais le changement de comportement est activé de manière contrôlée et peut être annulé rapidement.

PostgreSQL

-- application layer (pseudocode)
-- if flag('new_email_field'):
--     SELECT email FROM customer ...
-- else:
--     SELECT mail_old FROM customer ...

4. Mettez en place l'environnement blue-green

Conservez deux environnements identiques : 'blue' (en production) et 'green' (nouvelle version). Déployez la nouvelle version de l'application sur green et validez-la avant qu'elle ne reçoive du trafic réel ; une fois prête, basculez le routeur/le trafic vers green. Point clé : la base est généralement PARTAGÉE, le schéma doit donc être compatible avec les deux versions (l'expand-contract le garantit). Même si la cible de connexion change lors de la bascule, la compatibilité du schéma évite toute interruption.

PostgreSQL

# traffic is switched to green (new version)
# shared DB: schema must be compatible with both blue and green

5. Validez le déploiement par la surveillance (canary/observation)

Avant de basculer tout le trafic, surveillez des métriques telles que le taux d'erreurs, la latence, le nombre d'erreurs/de verrous de la base et le retard de réplication ; envoyez éventuellement un petit pourcentage du trafic (canary) vers green et observez. Si les indicateurs de santé sont bons, augmentez progressivement le trafic ; s'ils sont mauvais, n'allez pas plus loin. La surveillance alimente la décision de retour arrière automatique.

PostgreSQL

-- live health queries
SELECT count(*) FROM pg_stat_activity WHERE wait_event_type='Lock';
SELECT * FROM pg_stat_replication;

6. Préparez le retour arrière automatique

Si les métriques dépassent le seuil, le déploiement doit revenir en arrière automatiquement : en blue-green, rebasculez rapidement le trafic vers blue (l'ancienne version). Le retour arrière applicatif est instantané car blue tourne toujours. Côté schéma, le retour arrière n'est généralement PAS NÉCESSAIRE : grâce à l'expand-contract, le nouveau schéma est aussi compatible avec l'ancien code, il suffit donc de revenir à l'ancienne application. C'est pourquoi les modifications de schéma doivent rester indépendantes du déploiement applicatif et toujours être rétrocompatibles.

PostgreSQL

# traffic instantly returns to blue (application rollback)
# schema is not rolled back: expand-contract is compatible with old code
# if truly needed: write a new corrective migration