Rollback a promotion

[kfidelak94]

Rollback changes to a previous version.

Common use-case for this is where a change has been promoted to production and needs to quickly be "undone".

Please comment with your specific use-cases and desires for a rollback capability.

[renatoliveira]

A common scenario is a deployment that depends on an external integration by another team and system. If their implementation doesn't work and isn't deployed in time after our deployment on Salesforce, then we might need to rollback the implementation. That usually involves deleting classes deployed, reverting to old version of other classes and removing objects and fields from the environment. This includes the permission metadata related to all of those as well (i.e.: permission sets, profiles).

Ideally the rollback feature saves a snapshot of the target org before the changes are applied to the environment, and then that snapshot is available for a rollback demotion deployment.

A consideration for this is that the previous snapshot should also have its tests passing (if the deployment contains compiled components such as Apex classes and triggers), otherwise this demotion deployment (rollback) will fail on the testing phase.

Speaking of tests: a nice-to-have feature would be to be able to specify only specific tests, because it might need to be faster than a deployment that runs all the tests.

---

Scenario 1:

New class, test class and fields on existing object are deployed. Something happens and this needs to be reverted. The rollback would delete both classes and the field. Probably need to rerun the test for the class as it does with a destructive changes deployment.

Scenario 2:

Same as Scenario 1, but it changes an existing class instead. Upon rollback the test for the class that was just modified, not created, also fails, blocking the demotion deployment.

[SAxcell]

With several people working on different (but sometimes overlapping) projects in different sandboxes, we could use this function before we even get to production. I ran into it just this weekend:

I created a custom field and added it to the page layout, then migrated it from my dev to our (shared) UAT sandbox for testing. User tested it, it passed. However before I could get it moved to our Staging sandbox a coworker referenced the same object in a related list somewhere. Suddenly, I couldn't migrate because the reference wasn't available yet in the target (Staging) sandbox.. If I could have rolled back his work item I would have been able to move forward, but instead we had to promote his (untested) WI to Staging and then hide it.

We run into this ALL THE TIME! Its really just a matter of timing, with so many of us pushign things to the same UAT and Staging sandboxes.

And, of course, as you said, there are times when we need to be able to quickly roll back something that was pushed to production and caused an unanticipated problem. In our case, that's often to do with integrated systems not updating at the same time we do, so the applications get out of sync and it stops people in their tracks. We use Oracle CPQ, for example, and it depends on a lot of information from our Opportunities in Salesforce. If we make a change and promote it to Production, but the CPQ team doesn't promote their related change it can stop our users in their tracks, unable to create a quote for a customer, and that's never a situation we want to be in. We need to roll it back quickly, until we can get the timing coordinated.

[rgarikapati21github]

Also, Facility to change a Work Item status to Never at any stage until final promotion (e.g.; Production), should be available.

[brigadecs]

Changes should not only be able to be rolled back from production but from all stages in the pipeline. As it stands, a separate WI has to be created with negative changes and deployed to the source of the rollback. This is untenable.

[rsandsSFDC]

This would be such a great feature. I have worked with customers where the lack of this capability has put entire salesforce deployment at risk. More and more customers are moving to automated CD with rapid release cycles, even daily releases. This approach relies on the ability to rapidly roll back any problematic changes. This is normally possible with developer intervention, but can be complex and time consuming in some cases and with other platforms can be automated. This feature would be a great move towards Salesforce support for CD.

[john-eichsteadt-marcusmillichap]

I know this was discussed from the beginning, but I definitely think this is a priority. Rollback is one of the big benefits of source control and versioning that has always been inaccessible to admins.

[lmalkasf]

We must have control over a work item when its rolling up the pipeline. We might change the status to never at any stage. This is a must for us.

[premsingh82]

Very much needed in case of issues with conflicts which you don't want to merge while testing salesforce devops 😁

[Tythus]

this is very much need for us to in reverting failed UAT/etc runs

[jack-donnelly-thunder]

This would be super helpful! I'd also love to know what the current best practice is if a Work Item is deployed to say "QA" and fails QA testing. Currently the UI can fill up quickly in the QA environment with work items that have been left behind. Are there any manual steps recommended?

[Sanbalan]

Two developers is working on same class and the developer 1 deployed his changes to Prod but it needs to be deployed with developer 2 changes because of few dependency. At this case developer 1 needs to revert his changes in production. This is one of the use case for roll back option.