Rollback deployments made by CI jobs
Manual deployments and change monitoring jobs can be rolled back. Add the same function to CI jobs in case it accidentally deploys something unwanted
Work completed on December 22nd, 2021
-
Endrit Sino commented
Guys, I think this is crucial for every Salesforce Team. Especially, considering applications that have Community Implementations for example, and have thousands of customers whom could be impacted by a certain bug.
Having the ability to immediately roll it back, and then proceed with a fix-resoultion or aligning git history could be tackled in a 2nd moment, I think might be a way to move forward with this.
This is much needed for our use case.
-
Jose commented
This is a must and as you already have it on regular deployments I don't see why don't have it as well for Ci jobs
-
Abay commented
Need the ability to rollback to one or more deployments in the CI automation area
-
Deepak Dhingra commented
This feature would be really helpful to roll back a deployment as soon as you realize that something went wrong with the CI job.
-
Waldo Vargas commented
Hello....we are using the automated CI jobs functionality to deploy from the corresponding branch at our official salesforce git repository to the respective organization (Production and UAT sandbox at this point) when a push even occurs....As part of the pipeline testing we found that there is no rollback option for the CI job deployments like you can find on the Gearset deployment history page. This is key for us as it is directly related with our automated deployment strategy.
When talked with Gearset support they ask a couple of questions which I consider very helpfull to share over here along with its answers:
1. In the use case above, after rolling back in production, would you also change the source manually?
2. Or would it be better for us to develop the functionality in the source and trigger another CI run to migrate the correct metadata on both the source and target of the CI job?
Answer to both questions:
Those are good questions...I will say that it all depends on the scenario...for example the way our pipeline is design rigth now we are doing a deploy from the developer sandbox to a feature branch once that is done we create a pull request to the branch that is linked to the CI job (using the feature one)...so I will say that it will be great to be able to rollback the latest CI deployment the same way we will do from the deployment page history allowing us to put the org in the previous state...that will be at the org level and for the branches we can just revert the merge at the GIT repository itself for the CI linked branch and use the rollback option at the Gearset deployment history page for the feature branch (or we just can delete the feature branch and start another from scratch)....this is just at the top of my mind....and as mentioned before the context will have a great deal of saying in the final path selection -
jenkins commented
Addendum to my comment: We are using Gearset with prod, we are not using CI jobs with prod.
-
jenkins commented
I didn't even realize that we couldn't roll these back. A strong rollback strategy is something we sold our senior execs on to get approval to purchase Gearset. Not having this for CI jobs is concerning.
For now, we are not deploying to prod using Gearset so this isn't a massive concern, but this will be a requirement before we can use Gearset in our production environment. This combined with the ability to do a validation only in the CI job (https://gearset.uservoice.com/forums/283474-help-us-improve-gearset/suggestions/18399832-be-able-to-create-a-ci-job-with-the-option-to-vali) are required features for us to use Gearset with prod.