Expliquez-moi comment livrer une migration de base de données sans interruption de service.

Découpez-la en étapes rétrocompatibles. Déployez d'abord le changement de schéma sous une forme que le code en cours tolère, par exemple l'ajout d'une colonne nullable, puis déployez du code qui écrit à la fois dans l'ancien et le nouveau, remplissez par lots, basculez les lectures, et ne supprimez l'ancienne colonne que dans une version ultérieure. Évitez les verrous longs sur les tables et testez toujours le chemin de retour arrière.

La règle à laquelle je me tiens, c'est que pendant un déploiement progressif deux versions du code parlent à une seule base, donc chaque étape doit être sûre pour les deux. Renommer une colonne est le piège classique. À la place j'étends : j'ajoute la nouvelle colonne nullable dans sa propre migration, je livre du code qui écrit les deux champs et lit encore l'ancien, je remplis les lignes existantes par lots de quelques milliers avec une pause entre chacun pour que la réplication ne décroche pas, puis je bascule les lectures à la version suivante, et seulement à une troisième version je supprime l'ancienne colonne. Les spécificités Postgres comptent aussi. Ajouter une contrainte NOT NULL sur une grosse table prend un verrou lourd, donc j'ajoute la colonne nullable, je remplis, puis je valide la contrainte séparément. Django vous donne separate_database_and_state et des migrations non atomiques quand il en faut, et je règle un lock_timeout court pour qu'une migration bloquée échoue vite au lieu de mettre en file toutes les requêtes derrière elle. Chaque migration reçoit aussi un retour arrière testé.