Comment déployez-vous un changement backend risqué en toute sécurité ?

Découplez le déploiement de l'activation avec un feature flag, puis montez en puissance : utilisateurs internes, un petit pourcentage, puis plus large, en surveillant le taux d'erreur et la latence contre le groupe témoin à chaque palier. Gardez l'ancien chemin intact pour que le retour arrière soit un basculement de flag plutôt qu'un redéploiement, rendez le changement rétrocompatible au niveau des données, et fixez à l'avance des critères explicites d'arrêt. Retirez le flag une fois le déploiement terminé.

L'idée principale, c'est que déployer et activer sont deux événements différents. Le code part éteint derrière un flag, donc le déploiement lui-même est ennuyeux, puis je l'active d'abord pour les comptes internes, puis un pour cent, puis dix, puis le reste, en marquant à chaque palier une pause assez longue pour que les métriques veuillent dire quelque chose. Ce que je surveille, c'est le taux d'erreur, la latence et la métrique métier que le changement touche, comparés aux utilisateurs restés sur l'ancien chemin, puisqu'une courbe globale peut cacher une régression qui ne touche que le groupe traité. Tout changement de schéma suit expand and contract, pour que les deux chemins de code fonctionnent sur les mêmes tables à tout instant et que je puisse revenir en arrière instantanément, ce qui est tout l'intérêt : le retour arrière doit être un changement de flag, pas un redéploiement sous pression. J'écris à l'avance ce qui me ferait arrêter, parce qu'à deux heures du matin personne ne prend bien cette décision. Et le flag a un propriétaire et un ticket de suppression, puisqu'une base de code avec des dizaines de flags périmés devient impossible à raisonner.