Rolling back personalization changes
The term rolling back changes can apply to two different situations. The first is when you want to undo a deployment of customizations to an environment. This just removes the personalization from the environment. The second is when you want to undo any changes that have been made into the Git repository, so that the removed changes never get deployed to any environment.
Rolling back Git changes
If you want to undo the changes in your repository, you have a couple of choices. The best options are to either undo a Merge Request, or to manually undo the changes.
If you have enabled branch protection, and have a Merge Request that contains the changes that were made, you can revert that Merge Request and the changes that were part of that Merge Request will be undone.
If you haven’t enabled branch protection, or if the Merge Request contains several changes including ones that you want to keep, then you can manually undo the changes in VBS and commit those changes.
In either of these cases, you will need to re-publish that branch to get the changes into your desired environment.
Undeploying an Extension
If you just want to undeploy the last extension deployed to an environment, you also have a couple of options.
Let’s say you used Manage Extension Lifecycle to copy a deployment to an unintended environment. In this case you want to keep the changes that have been made, but just remove the extension and personalizations that have been deployed. For this, you can just delete the deployed extension and re-deploy the correct extension from an alternate environment.
What happens if a mistake is made and you need to deploy a previous version of the extension? If you have disabled CI/CD pipelines then you must go the republish route where you redeploy from a different or fixed-up branch in Git.
If you are using pipelines, though, you can build a pipeline to deploy a previous build version. To do this you simply create a duplicate of your deployment job, change the parameters to specify the results of the desired build (e.g. build job 61), and then you can run just that deploy job (not a pipeline) to deploy the previous version of the extension.
Good luck with your implementation!