Find your content:

Search form

You are here

Homeยป

Rolling Back changes in Production

 
Share

As we know there are two ways to deploy the code from Sandbox to Production

  1. Using Ecclipse
  2. Using ChangeSet - which is Unidirectional, once committed no changes can be rolled back from Production

Ref - : https://login.salesforce.com/help/doc/en/changesets_implementation_notes.htm

Can anybody advice, what the best practice if we want to roll back the commmitted changes in Prodcution and to make problem specifically more clear. I


Attribution to: user619

Possible Suggestion/Solution #1

Wondering - I believe salesforce should give at minimum one backup button for a changset. Let say, if I only want to rollback the changeset I just deployed, its a pain .

Best Practice Include

  1. When Deploying Apex components, deploy through SF IDE, check backup options before deploying

  2. As proposed, on the AppExchange, DreamFactory allows to snaps of the your existing classes and trigger, read more on it on the Appexchange page

Though we use a little expensive tool called - DreamFactory

http://appexchange.salesforce.com/listingDetail?listingId=a0N300000016cejEAA

Problem - Far as deploying with change-set is concerned, long as we deploy code, it is easier, but lets say i deploy reports in Salesforce with some configuration. This is pretty hard to manage without any concrete app or tool


Attribution to: Harshit Pandey

Possible Suggestion/Solution #2

I don't think there's a way to roll back deployment at all. With the IDE or a Changeset.


Attribution to: Salesforce Wizard

Possible Suggestion/Solution #3

If you upload a unmanaged package and install this unmanaged package into your production org then I think you can rollback by uninstalling this package.


Attribution to: doga

Possible Suggestion/Solution #4

A true rollback doesn't necessarily exist in Salesforce. Unfortunately, there are going to be certain aspects of the process that need to be a manual step as they do not currently exist in the API (Approval Process for instance).

However, there are a few steps you can take to mitigate problems you may run into. Obviously, you want to thoroughly test your entire application before you put anything into production. This is also true for your deployment. It is a good practice to do a dry run deploy before you do your final push to production. Make sure everything is fully working and tested in a Sandbox (preferably a recently refreshed Full Copy). It is important to note that once you do your refresh to the Full Copy sandbox that all Prod changes should be stopped. If they are absolute, must-have changes, these changes must also be done in the Sandbox. The goal is to make your sandbox replicate production to find any issues.

Once everything is fully tested, you need a backup of the previous version of the metadata. This can be done a few ways. If this is a long standing application, you may have a tagged version available. If you have an extra sandbox slot available, copying to a developer/config-only sandbox will store the meta data (this would be my preferred approach as not everything is available via the metadata API). You could also do a manual backup just pulling down all of the data using Ant and the Metadata API. Next, you need to make sure you back up your data. You can use the Data Management > Data Export functionality available through the Admin for a weekly export, or you can use the Data Loader. Either way, you are going to want to do a backup of your data.

So, you have everything backed up, but currently you don't have any way to really get the system back into a state that it previously was in. You can now make a destructive changes package file that you can run using Ant to remove all of the recently entered Metadata. Unfortunately, this is just going to remove things and not revert changes you made back to their original version. If you need to compare Metadata versions, you can use a piece of software like SnapShot. Unfortunately, this is all still a very manual process. You need to keep a strict log of all of the changes you are making to revert anything you do if needed.

Salesforce also provides a rollback of data only (NOTE: This is data only. Not Metadata!) for a fee for a 24 hr period as well.

So, the moral of the story is you really don't have a great way of doing rollbacks in Salesforce. At least not in the general sense of normal application development (like replacing a WAR file for a Java app). It is crucial to test heavily well before the production deploy. Regression test everything and keep a good set of unit/integration tests. Good luck!


Attribution to: Jesse Altman

Possible Suggestion/Solution #5

As @mohit mentioned you can use ant undeploy, and using destructive changes xml you can undeploy the code base.

Sample undeployment looks like this in build.xml - 

<!-- This will be used to undeploy any code base from an org. -->
    <!-- Please make sure desctructive folder is present with destructive xml -->
    <target name="undeploy">
        <sf:deploy username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" deployRoot="destructive"/>
    </target>

Let me know if further details required or if it helps

Thanks Ray


Attribution to: Kaushik Ray

Possible Suggestion/Solution #6

Not sure completely but I think there is a option when you are working with IDE. Let's say I've deployed the complete source to target org, but now I want to delete some classes and pages.

First delete those classes and pages from IDE/Server(developer org) and then deploy the complete source again, it will show up the difference and classes and pages in red which are on production(target org) but not on sandbox(developer org). You can then select those and continue the deployment. it will delete all those components from production (if there is no dependencies).

Rolling back the changes is possible by deploying the source from last submitted code in repository.


Attribution to: Forceguru

Possible Suggestion/Solution #7

Those familiar with ANT migration tool we can use to undeploy the classes ,pages and triggers atleast.

The following is a sample destructiveChanges.xml file that names a single custom object to be deleted:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>MyCustomObject__c</members>
        <name>CustomObject</name>
    </types>
    <version>26.0</version>
</Package>

In order to deploy the destructive changes, you must also have a package.xml file that lists no components to deploy and is in the same directory as destructiveChanges.xml:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <version>26.0</version>
</Package>

1)Construct the destructive XML for reverting custom object 2)Also to undeploy the code there is a command in ANT tool


Attribution to: Mohith Shrivastava
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/1702

My Block Status

My Block Content