Erklär mir, wie du eine CI/CD-Pipeline für einen Service designen würdest, der mehrmals täglich deployt.

Jeder Commit stößt eine Pipeline an, die ein einziges unveränderliches Artefakt baut, es testet und genau dieses Artefakt durch die Umgebungen promotet. Nichts wird pro Umgebung neu gebaut. Die schnellen Feedback-Stages kommen zuerst (Lint, Unit Tests, Build), damit Fehler in Minuten sichtbar werden, Integration und Security-Scans laufen parallel, dann automatisches Deployment nach Staging und in Produktion hinter einem progressiven Rollout mit automatischem Rollback.

Das Kernprinzip ist einmal bauen, dasselbe Artefakt promoten. Bei einem Commit baut die Pipeline ein Container-Image, getaggt mit dem Commit-SHA, und genau dieser Digest läuft am Ende in Produktion, es wird also nichts unterwegs mit anderen Dependencies neu gebaut. Die Stage-Reihenfolge folgt der Feedbackzeit: Lint und Unit Tests zuerst, damit eine schlechte Änderung in etwa zwei Minuten scheitert, dann der Image-Build, dann Integrationstests, Contract Tests und Security-Scanning parallel, weil keines vom anderen abhängt. Ein Merge auf main deployt automatisch nach Staging und fährt Smoke Tests. Produktion ist dieselbe Pipeline mit progressivem Rollout, also zuerst zehn Prozent des Traffics, während wir Error Rate und Latenz gegen die Baseline beobachten, plus automatischem Rollback bei Überschreitung. Die Pipeline-Definition liegt im selben Repository wie der Code, damit sie wie alles andere reviewt wird, und ich tracke ein paar Zahlen zur Pipeline selbst, vor allem wie lange eine Änderung bis in Produktion braucht und welcher Anteil der main-Builds grün ist.