Erklär mir, was in deinem Team zwischen einem gemergten Pull Request und dem laufenden Code in der Produktion passiert.

Beim Merge führt die CI Typechecks, Lint sowie Unit- und Integrationstests gegen eine echte Datenbank aus und baut dann ein unveränderliches Artefakt, das mit dem Commit getaggt ist. Dieses Artefakt geht automatisch nach Staging, Smoke-Tests laufen, dann geht es hinter einem schrittweisen Rollout mit Health Checks und automatischem Rollback in die Produktion. Riskantes Verhalten sitzt hinter einem Feature Flag, Code ausliefern und ein Feature starten bleiben also getrennte Ereignisse.

Im letzten Team hat ein Merge auf main die CI gestartet: Typecheck, Lint, Unit-Tests, dann Integrationstests gegen einen Postgres-Container, insgesamt etwa sieben Minuten. Ging das durch, haben wir ein Container-Image gebaut, getaggt mit dem Commit-SHA, und genau dieses Image wandert weiter; nichts wird pro Umgebung neu gebaut, denn dann lieferst du etwas aus, das du nie getestet hast. Es ging automatisch nach Staging, hat dort eine kurze Smoke-Suite gegen echte Endpoints laufen lassen und ging dann als Rolling Deploy mit Health Checks in die Produktion, mit ein paar Minuten Beobachtung von Fehlerrate und Latenz und automatischem Rollback, wenn eines eine Schwelle überschritten hat. Migrationen liefen als eigener Schritt vor dem Deploy und waren immer abwärtskompatibel, ein Rollback des Codes hat das Schema also nie hängen lassen. Alles Nutzersichtbare ging hinter einem Flag raus, standardmäßig aus, dann für interne Nutzer, dann für einen Prozentsatz. Diese Unterscheidung war wichtiger als alles andere, weil ein misslungener Launch damit ein Config-Schalter war und kein Notfall-Deploy um neun Uhr abends.