Racontez-moi ce qui se passe entre une pull request mergée et ce code qui tourne en production dans votre équipe.

Au merge, la CI lance la vérification de types, le lint, les tests unitaires et d'intégration contre une vraie base, puis construit un artefact immuable tagué avec le commit. Cet artefact se déploie automatiquement en staging, les tests de fumée tournent, puis il part en production derrière un déploiement graduel avec health checks et retour arrière automatique. Le comportement risqué est derrière un feature flag, donc livrer du code et lancer une fonctionnalité restent deux événements distincts.

Dans ma dernière équipe, merger sur main lançait la CI : vérification de types, lint, tests unitaires, puis tests d'intégration contre un conteneur Postgres, à peu près sept minutes en tout. Si ça passait, on construisait une image de conteneur taguée avec le SHA du commit, et c'est exactement cette image qui avance ; rien n'est reconstruit par environnement, parce que sinon vous livrez quelque chose que vous n'avez jamais testé. Ça se déployait automatiquement en staging, lançait une courte suite de fumée contre de vrais endpoints, puis partait en production en déploiement progressif avec des health checks, en surveillant le taux d'erreur et la latence pendant quelques minutes avec un retour arrière automatique si l'un des deux franchissait un seuil. Les migrations tournaient dans une étape séparée avant le déploiement et étaient toujours rétrocompatibles, donc un retour arrière du code ne laissait jamais le schéma orphelin. Tout ce qui était visible par l'utilisateur sortait derrière un flag, désactivé par défaut, puis pour les utilisateurs internes, puis pour un pourcentage. Cette distinction comptait plus que tout le reste, parce que ça voulait dire qu'un mauvais lancement était un basculement de configuration et non un déploiement d'urgence à vingt-et-une heures.