Deux chemins de déploiement, et savoir sur lequel tu es

Un échange progressif de conteneurs a une fenêtre — quelques secondes — où le nouveau schéma est en direct et certains anciens processus back-end servent encore des requêtes. Que cette fenêtre soit inoffensive ou un incident dépend entièrement de la migration, et le runbook existe pour me faire décider laquelle avant de taper la commande de déploiement.

Chemin A — routine

Les migrations purement additives — une nouvelle colonne nullable, une nouvelle table, une nouvelle valeur d'enum — sont sûres avec l'ancien code qui tourne contre le nouveau schéma. L'ancien code n'utilise juste pas la nouvelle chose. Pas de mode maintenance, pas de cérémonial. Le script de déploiement prend une sauvegarde, construit chaque image, lance la migration, monte la stack, sonde l'endpoint de santé, scanne les logs de chaque service pour de vraies erreurs sur une courte fenêtre, et élague le cache de build en sortie.

Chemin B — cassant

Un drop ou renommage de colonne, un nouveau NOT NULL sans défaut, un changement de type. L'ancien code back-end se comportera mal contre ce schéma, alors :

1. Lève d'abord le drapeau de maintenance au niveau application — un vrai feature flag imposé à la périphérie, pas juste une page statique. Sur cette plateforme, il faut un code à usage unique envoyé par e-mail pour le basculer, spécifiquement pour qu'il ne puisse pas être activé à la légère ni par une seule session compromise.
2. Confirme que la page de maintenance s'affiche réellement à un utilisateur normal avant de toucher à quoi que ce soit. C'est le vrai moment « les utilisateurs voient que c'est tombé », pas le basculement.
3. Lance le déploiement.
4. Seulement après que le health check passe et que le scan de logs est propre, désactive la maintenance.

Le guard de maintenance laisse délibérément passer la surface d'admin de l'opérateur, /auth et /health — sinon activer la maintenance te verrouille hors de l'écran qui la désactive. Cette exclusion n'est pas un cas limite ; c'est la première chose à réussir.

Des choses qui ne sont ni A ni B et qui mordent quand même

• Un nouvel index sur une table qui contiendra de vraies données va dans sa propre migration, construit en mode concurrent — un build d'index simple prend un verrou d'écriture sur la table pendant toute sa durée.
• SET NOT NULL sur une colonne existante erreur si une ligne est actuellement nulle. Vérifie d'abord ; ce n'est pas automatique.
• Une migration qui rapporte « 27 lignes écrites » est une preuve sur la migration, pas sur la fonctionnalité. Re-parcours le flux visible par l'utilisateur avant de le déclarer fait — j'ai regardé un backfill rapporter un succès pendant que la fonctionnalité restait cassée parce qu'un second filtre, ailleurs, excluait aussi les lignes.