One strategy I have never seen reliably done is rolling software updates backward.
Rolling back code in my experience is much harder to do, so why bother with it?
Do you have a bug in production? Roll out a hotfix. Having a new feature that wasn't supposed to be exposed to the users? Roll out an update that disables that feature. In other words, roll forward.
Rolling code backward is hard if you work in a team and a lot of new updates are merged into the main branch, rolling your code back would most likely create inconsistencies and conflicts. It's much easier to create the fix and move forward with updates.
There is a distinction between code under version control and code deployed in production.
Code under version control is not necessarily deployed into production but code in prod. should almost always be rolled back temporarily if you have a serious bug in the code that's blocking users from using your software.
One way of temporarily rolling back production code is to have multiple versions "readily available". In web development that means keeping the most up-to-date version and one version before it.
For smaller projects, this is achievable by not overwriting deployed code in production, but having multiple versions in separate folders and a symlink pointing to the version you want. The symlinked folder is the one that the web server has access to.
Switching versions this way is as easy as changing where the symlink points to.
In the meantime having a hotfix that's "rolled forward" in version control and deploying that when it is ready.
Cover photo by Soner Arkan