[SalesForce] Why is migrating changes between multiple orgs such a pain

So I've developed a couple of Salesforce / Force.com projects but the one thing I really hate is migrating changes between orgs. Maybe I'm doing it wrong, or I'm missing tools but something just snapped today.

I'm working on a fairly easy Salesforce project, a lot of custom fields, some custom objects, couple of queue's, some assignment rules here and there. I've got 1 production org and 1 dev org. I've made some profile changes, layout changes, visualforce page changes and I've added some fields. So now the hard part, some changes are made via the IDE and some via the GUI. I want to deploy the "neat" way so I wanted to use the change sets. I've set them up and then. I don't remember all of the fields I added, I don't know all the dependencies, so I've added them all.

This all concluded in 1 big bloated change set. It gave me a couple of errors when I tried to upload it about some missing fields… So with these cryptic messages I changed over to the IDE, selected all the things I thought I needed and managed to deploy it to production.

So it's a pain to deploy changes, especially if those changes have been made between 1 – 2 months. The project isn't in source control (I know very bad working on it) but what about all those changed made via the GUI. Why can't SF tell me what the DIFFS are between my "master" or production org and Sandboxes?

I guess I'm missing all the cool kid tools/scripts, but I couldn't find any good tutorials about it. This leading to another somewhat related question. How do you set-up your development environment? I want to use the newest Eclipse, but it errors on me when I try to add the Force.com plugin, so i'm stuck with the IDE force.com provided. Which gives me errors along the lines of:

com.salesforce.ide.api.metadata.types.Metadata$JaxbAccessorF_fullName cannot be cast to com.sun.xml.bind.v2.runtime.reflect.Accessor

So, what am I missing?

Best Answer

When you're building something you know will be deployed, start building the change set at the same time. Every change you make to metadata, add it to the change set or to some spreadsheet you're keeping of required manual changes.

Also, every time I make a new change set I mark it as "v1", since I generally get up to at least v3 before the change set can be deployed. Inevitably I've forgotten a field or something and have to go back and clone v1, add the thing I forgot to v2, and re-upload. Have your change set uploaded and validated against the target org in advance of when you want to deploy, and then deployment can go quickly and smoothly, and you can just run through your manual actions. These things all mostly apply no matter whether you're using Change Sets, Eclipse, or the migration tool.

Note that Eclipse allows for archiving of deployment and target metadata, so there is some record, admittedly not as complete as we would like. To see changes made in the UI, you can use the Setup Audit Trail log.

Related Solutions

[SalesForce] Deploying From Sandbox (Enterprise) – loss of permissions, field security, etc

When you add profiles to assign permissions in a change set, it only impacts the components of the change set. Change sets are never destructive, so they can't remove permissions you've assigned in production. You are safe to include the profiles during the change set deploy.

[SalesForce] Ant Deployment To New Dev Org

The error log shows a number of errors in the metadata you're trying to deploy through the Metadata API which the Force.com Ant Migration Tool ultimately calls. My hunch is that a full save to server from Force IDE would get the same errors.

One thing I've noticed about deployment logs is that you can often ignore the massive number of duplicate lines. For example, the following error appears all over your log:

Error: Required field is missing: type

It's likely that a previous failure is causing this error and fixing the other failures will make this one go away. So, going with that strategy, there are a few errors you need to fix in the metadata files to get the deployment to pass:

[sf:deploy] 1.  settings/Account.settings -- Error: You cannot disable account teams using the Metadata API.  Your system administrator can disable account teams from the Account Team Setup page.

Account Teams are not supported for deployment through the Metadata API: http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_unsupported_types.htm

[sf:deploy] 2.  objects/AccountContactRole.object -- Error: ControlledByParent is not a valid sharing model for AccountContactRole

Adjust the sharing model of AccountContactRole.object or if you didn't make any customizations to it, delete the file locally so it's not a part of your deployment.

[sf:deploy] 3.  objects/Site.object -- Error: Entity cannot be untracked.

This is likely due to the same issue with the same fix as discussed here: https://developer.salesforce.com/forums/ForumsMain?id=906F00000008k09IAA

[sf:deploy] 163.  objects/Contract.object (Contract.APXTConga4__Conga_Mail_Merge) -- Error: Cannot create a new component with the namespace: APXTConga4.  Only components in the same namespace as the organization can be created through the API (line 235, column 15)
...
[sf:deploy] 171.  objects/Solution.object (Solution.APXTConga4__Conga_Mail_Merge) -- Error: Cannot create a new component with the namespace: APXTConga4.  Only components in the same namespace as the organization can be created through the API (line 120, column 15)

These errors indicate that you're trying to deploy metadata which comes from the APXTConga4 package. You can only deploy managed page components by installing the managed package. There is a trick you can do via the migration tool to install managed packages into the org as a separate deployment but covering that is beyond this question.

Edit the offending objects and remove any metadata starting with APXTConga4__

Finally, I wanted to point to another option I've been working with lately. You can create an unmanaged package in your sandbox org (Setup -> Create -> Packages) and then add all the custom code you want to migrate to it. Then you can use Ant to pull down only the metadata you chose to include in that package. This approach helps you avoid a lot of the issues you're seeing as it doesn't pull down anything from standard salesforce or installed packages, only the code you explicitly tell it to include. I plan to write a blog post on this approach soon, but you can get some more details from this answer I posted a few months back:

Using sf:bulkRetrieve do not fetch metadata components associated with a managed package

Best Answer

Related Solutions

[SalesForce] Deploying From Sandbox (Enterprise) – loss of permissions, field security, etc

[SalesForce] Ant Deployment To New Dev Org

Related Topic