Was Sie erreichen werden

Sie werden ein problematisches Release zurucksetzen — zuerst durch Reverten der Commits, dann durch Re-Tagging einer fruheren Version.

Zwei Szenarien

• Deployment-Rollback.
• Code-Rollback.

Szenario 1: einen alteren Tag deployen

git tag --sort=-v:refname | head

gh workflow run deploy.yml -f tag=v2.3.5

Szenario 2: die Commits reverten

git checkout main
git pull
git revert <bad-sha>
git push

Einen Merge-Commit reverten

git log --merges -10
git revert -m 1 <merge-sha>
git push

Einen Bereich reverten

git revert <older-sha>..<newer-sha>

Den Rollback taggen

git tag -a v2.4.1 -m "Roll back v2.4.0 due to checkout regression"
git push origin v2.4.1

Das Forward-Fix-Antimuster

Verlockend aber oft falsch: "wir werden es einfach forward fixen".

Datenbank-Migrationen und Rollback

• Migrationen sollten additiv sein.
• Breaking Changes in Migrationen vermeiden.
• Einen getesteten Down-Migrationspfad haben.
• Feature-Flags verwenden.

Mit dem Team koordinieren

• Den Rollback im selben Kanal wie Releases ankundigen.
• Den SHA dokumentieren, der rolled back wird.
• Ein Tracking-Issue offnen.
• Ein Post-Mortem planen.

Rollbacks vermeiden

• Canary-Releases.
• Feature-Flags.
• Pre-Release-Validierung.
• Kleinere Releases.

Nach dem Fix erneut anwenden

git revert <revert-sha>
git commit -am "Fix the issue that caused the original revert"