Tell me more ×
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.
up vote 0 down vote favorite

I'm using the Force.com IDE for the first time and attempting to migrate all the meta-data from one instance to a brand new developer edition account. I am fine doing this piece by piece however long it takes

I am running into what seems to be a rookie error.

Let's say I am only bringing over the Lead's meta-data, which includes custom fields, business proceses, and custom record types. I get all types of errors saying things like:

File Name: objects/Lead.object Full Name: Lead.Real_Money_Account_Status__c Action: NO ACTION Result: FAILED Problem: The entity: Lead does not have history tracking enabled

File Name: objects/Task.object Full Name: Task.Historical_Task Action: NO ACTION Result: FAILED Problem: Picklist value: Historical in picklist: Status not found

I understand how to resolve these specific errors (ie. enable tracking and add a picklist value) but it was my understanding that that is the whole purpose of the Force.com IDE?

What am I doing wrong?

I got good advice from someone here about Person accounts and indeed the source account is a person account. But still NOTHING is being created and I'm not even trying to bring over the accounts object or feilds yet.

share|improve this question

1 Answer

up vote 1 down vote

What we can say :D It IS full of kludges, especially with big deployments.

Force.com & IDE have many limitations, from all your code sitting in one "package" (leads to amusingly long class names) to stuff like that. It has some deficiencies in regards to dependency resolution... enabling field tracking of flipping lookup to master detail or attempt to change sharing settings via api... all of these (and possibly more) will fail and you'll have to perform them from web UI.

Overall it's OK-ish but I for one don't have tips for you other than "merge often". Dependency resolution is so-so... I have a feeling that you'd be much easier working in "developer sandbox" rather than "developer edition" with loose link to your production. Private managed package seems like more hassle than it's worth...

As stupid as it sounds - do you have some specific question about particular deployment problem ;) Otherwise it's likely to be closed as too philosophical, inciting too many discussions...

share|improve this answer
Thanks for your thoughtful response "Eyescream"... haha. – Bigtobydog Jan 29 at 20:52
Creating a developer sandbox would be perfect however this requirement does indeed require a new production instance. So if the best advice is to deploy incrementally and often, is there I way I can do this through an order of operations containing the fundamental components first followed by components that reference them? – Bigtobydog Jan 29 at 20:55
Start with @MikeChale's answer to salesforce.stackexchange.com/questions/7654/…. Disable "build automatically" in Eclipse. Start with deployment of objects (edit their XML to remove VF page action overrides if any, that's why you want to shut down autosave). Then try classes+triggers+pages+components+static res+layouts+workflows, should work. Redeploy objects with their overrides if you had to hack them out. Then whatever remains (email templates, reports, sharing rules,...)? – eyescream Jan 29 at 21:02
Thanks, I'll let you know how it goes. – Bigtobydog Jan 29 at 21:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.