Comment livreriez-vous un changement de schéma de base de données cassant sans interruption de service ?

Utilisez le motif expand and contract. D'abord l'expansion : ajoutez la nouvelle colonne ou la nouvelle table de façon rétrocompatible pour que le code déployé actuellement continue de marcher. Puis déployez du code qui écrit à la fois dans l'ancien et le nouveau, remplissez les lignes existantes par petits lots, basculez les lectures vers la nouvelle forme, et ne supprimez l'ancienne colonne que dans une release ultérieure. Gardez chaque migration compatible avec la version de l'application qui tourne avant et après elle.

La règle à laquelle je me tiens, c'est que tout schéma déployé doit fonctionner avec la version précédente et la suivante du code, parce que pendant un déploiement progressif les deux tournent en même temps. Donc je ne renomme jamais une colonne, je fais expand and contract. Disons qu'on découpe un champ nom. Première migration : ajouter les nouvelles colonnes nullable, ce qui coûte peu et ne touche aucune ligne existante. Puis une release où l'application écrit à la fois l'ancienne et la nouvelle forme mais lit encore l'ancienne, donc rien côté utilisateur ne dépend encore des nouvelles données. Ensuite un remplissage qui tourne par lots de quelques milliers avec une pause entre chaque, pour ne pas tenir une longue transaction ni faire exploser le retard de réplication sur les réplicas. Puis une release qui lit les nouvelles colonnes, les anciennes étant toujours écrites comme filet de sécurité. Une fois que c'est stable depuis une release ou deux, seulement alors j'arrête la double écriture et je supprime les anciennes colonnes. Je garde aussi les migrations hors du chemin de déploiement lui-même, et tout ce qui prend un verrou lourd, comme la construction d'un index, tourne en mode concurrent et hors des heures de pointe.