Ce que vous accomplirez

Vous ferez rollback d'une release problématique — d'abord en revertant les commits, puis en re-taggant une version antérieure pour redéploiement.

Deux scénarios

• Rollback du déploiement.
• Rollback du code.

Scénario 1 : déployer un tag plus ancien

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

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

Scénario 2 : revert des commits

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

Revert d'un merge commit

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

Revert d'une plage

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

Tagger le 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 forward-fix

• Le fix prend des heures et les clients sont impactés maintenant.
• Le bug corrompt les données.
• Le fix nécessite des tests soigneux.

Migrations de base de données et rollback

• Les migrations devraient être additives.
• Évitez les changements brisants dans les migrations.
• Ayez un chemin de down-migration testé.
• Utilisez des feature flags.

Coordonner avec l'équipe

• Annoncez le rollback.
• Documentez le SHA reverté.
• Ouvrez un issue de suivi.
• Planifiez un post-mortem.

Éviter les rollbacks

• Releases canary.
• Feature flags.
• Validation pre-release.
• Releases plus petites.

Réappliquer après le fix

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