Rolling back changes in Salesforce

Question

I am just getting started with doing moderate web development work in Salesforce for my company, and I'm looking for some feedback/insight into the deployment process. Right now it's looking like we will be doing a fair amount of custom work using visual force and apex. What I am wondering is if I screw something up in my production org (data or metadata) is there a way to roll back to a snapshot or previously released version of my org that still works? With the mediocre development tools I am worried that when bugs do arise that I won't have a good fast way of addressing the situation.

I was reading about different ways to set up source control here: How can multiple developers efficiently work on one force.com application?

But I haven't found anyone walking through the process of essentially reverting a change set or changing branches. Are the protections built into salesforce good enough that I just won't have to worry about bugs in production? Should I just not worry about having to revert a change set?

Phenomenal

Someone at work pointed me at an app called snapshot. Has anyone used it? dreamfactory.com/appexchange – Phenomenal

We demo'd their product a couple of years ago, and it was very good. We ended up using Eclipse (Force.com IDE) but have never really been happy. Sandbox environments are a must whatever tool you use. – Milwaukee

Answer 1

I've been researching an app on the app exchange that at least looks like it will give me what I want. The product is Snapshot by Dreamfactory. Interestingly the sales people I talked to at Dreamfactory told me that salesforce uses their app internally to manage changes. I find it kind of unfortunate that this capability isn't included with my license but... here are the specifics of what I found that will be helpful for my specific question:

The ability to take a snapshot of your orgs meta data and copy or deploy it to another org. This will allow me to deploy/rollback changes.

The ability to diff 2 different snap shots (from different orgs) and see the details of what changed. This will help me to track down the cause of problems when they do arise.

Phenomenal

Answer 2

One of the ways this is handled is through the proper use of sandbox orgs associated with your production org. You can always keep a sandbox org that has the "blessed" instances of everything while you use another sandbox org to do major development destined for deployment to production. In the event that something seriously wrong occurs between the new development in your dev sandbox being deployed to production, you can roll-forward from your blessed sandbox to revert to what was completely working previously.

That being said, you're on to something when you ask about not worrying about bugs in production. Not that they won't happen, because they will, but rather that you'll soon begin to get a different sense for what broken means. A change set is only one way to get changes from one org to another, and a rather recent development on the platform. They have some limitations like not moving custom setting data, but generally work really well.

But it's true that when you've got good unit tests in place, coupled with all of the rest of the imposed referential integrity checks, it's really not that common to "break the build" so to speak, and wish to revert to some global snapshot of everything at a different point in time. More frequently, in my experience, you will revert isolated units back to previous versions and can do this with sandboxes or source control by pushing an earlier version forward until a fix is found.

Adam

Ellord

I would add to Adam's answer that you can also use one of your developer sandboxes as a production backup. Just initiate a back before a major deployment and that way you will have a copy of your entire configuration. Then you can redeploy from that environment back to your production. – Aleta

Exactly. That's actually what I meant by having a sandbox org with blessed instances of everything. But calling it a production backup is more clear for this purpose, though some rightly question the wisdom of having a production backup in a sandbox. It just sounds volatile ;) – Ellord

Can you walk me through in a little more detail how you would push a change forward from the blessed sandbox or version control. Would you use the metadata api/ant scripts? Rolling something back seems like it would need to be able to delete new custom objects or fields. I know that you can't delete things with a changeset. Can you do that using the metadata API? – Phenomenal

I personally like using the metadata api via Eclipse. You can deploy from any one org into any other and it provides a nice validation pass before actually deploying anything. So with a dev org you would open it in Eclipse, select all components to be deployed, select the org it deploys to (production in this case) and validate if it's going to break anything before doing it. If bugs are discovered after deployment that can't be resolved by subsequent fixes/deployments from dev, then you push from your prod backup org, replacing what you deployed from dev, to "revert" to a previous config. – Ellord

>Deleting objects from metadata? No. However, you can completely overwrite objects that had new fields created as a result of new features. Then if necessary simply manually delete any new custom objects that are no longer needed. – Ellord

Is there an easy way to diff 2 orgs to see if you forgot to deploy/change something when you were moving changes between orgs? – Phenomenal

Nothing native that I'm aware of, though there are a few AppExchange offerings that might be of interest such as this: appexchange.salesforce.com/… – Ellord