Pourquoi ma migration de schéma s'exécute-t-elle avant de vérifier que les services déployés peuvent la supporter ?

Lorsque vous poussez une modification de schéma en base de données de production, la migration s'exécute avant qu'un quelconque outil vérifie que les versions de services actuellement en cours d'exécution peuvent lire et écrire la nouvelle structure. Une colonne supprimée ou un champ renommé atteint la base de données avant que les anciens pods aient fini de drainer, et le rollback restaure le schéma mais pas les données écrites par la nouvelle version entre-temps. Les outils ORM génèrent du SQL à partir de diffs mais ne modélisent rien de la topologie de déploiement, des versions de services concurrentes, ni des patterns de lecture-écriture en direct. Les équipes compensent avec des rituels expand-contract documentés dans des wikis et un savoir tribal, non imposés par les outils. Une seule étape mal ordonnée a déclenché des défaillances en cascade sur plusieurs services et un incident documenté à 4,5 millions de dollars rien que l'année dernière.