Cosa otterrai

Farai rollback di una release problematica — prima revertendo i commit, poi ritaggando una versione precedente.

Due scenari

• Rollback del deployment.
• Rollback del codice.

Scenario 1: deploy di un tag piu vecchio

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

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

Scenario 2: revert dei commit

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

Revert di un commit di merge

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

Revert di un range

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

Taggare il rollback

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

L'antipattern del fix in avanti

Tentante ma spesso sbagliato: "lo aggiusteremo in avanti".

Migrazioni database e rollback

• Le migrazioni dovrebbero essere additive.
• Evitare cambi breaking nelle migrazioni.
• Avere un percorso testato di down-migration.
• Usare feature flag.

Coordinarsi con il team

• Annunciare il rollback nello stesso canale delle release.
• Documentare lo SHA che sta venendo rollback.
• Aprire un issue di tracking.
• Pianificare un post-mortem.

Evitare rollback

• Canary release.
• Feature flag.
• Validazione pre-release.
• Release piu piccole.

Riapplicare dopo il fix

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