5

I'm reading about the Salesforce development lifecycle, but I can't figure out whether (and if so, how) Salesforce provides for rolling back a code deployment from a sandbox to production.

Improve this question

2 Answers 2

Reset to default
3

Salesforce doesn't provide this functionality out of the box. But you can keep the old code backup and when needed revert back your code from the backup. to keep the old code backup you can use eclipse or Mavens mate. You can keep the backup in your system and if anything goes wrong. You can deploy the code.

Or else you can take help of github. Keep your code repository their and manage your code

Or you can use third party apps available on app exchange like flosum or many other apps are there (most of them are paid apps and I haven't use them much).

But I personally suggest to go with Eclipse or github. You can't redeploy the old change set again so you will not get any help from there too.

Improve this answer
2
  • 2
    Please consider adding some detail to this answer. What are the third party apps? How would you keep the old code backed up? Can one simply redeploy from an older change set? These details would be helpful.
    – Jagular
    Commented May 27, 2016 at 17:12
  • @Jagular check my updated answer.
    – Tushar Sharma
    Commented May 27, 2016 at 17:21
8

Keep your code and metadata under version control and deploy a previous revision to your org.

That's the short answer, but it doesn't quite get you a full rollback. New metadata components that were introduced in the revision that has since been rolled back will not automatically get deleted.

In many cases, this doesn't cause any problems. For example, if you added a new Custom Field to an object or added a new Visualforce page, these components will still be there, but there will be no code referencing them.

But if you had added a new trigger, it won't be deleted by deploying a previous revision so it will remain active after rolling back. You will need to delete it or deactivate it, either manually or by adding it to a destructiveChanges.xml file. Other metadata like Workflow Rules, Process Builder Flows, and Validation Rules should be given the same consideration.

If your new revision included destructive changes, you may need to manually restore data lost by deleting these metadata components. For example, if you deleted a Custom Field, you will need to manually restore the values of this field from a pre-deployment backup. Or if you deleted a Queue or Permission Set, you will need to reassign Users.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .