Take the 2-minute tour ×
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.

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
add comment

3 Answers 3

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 '13 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 '13 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 '13 at 21:02
    
Thanks, I'll let you know how it goes. –  Bigtobydog Jan 29 '13 at 21:21
add comment

Use the ant migration tool to get the code to the new env, then refresh force.com ide from the server, then you can use as normal. We never use force.com ide to populate new environments anymore, its too painful.

share|improve this answer
add comment

As was mentioned above, you would better have a developer sandbox or even full sandbox, so this task which you are doing could be performed automatically by standard "sandbox refresh" operation.

If you really need separate developer instance (which is not connected to the production), and you don't want to perform standard "sandbox refresh" operation, I would suggest to use ANT script (based on ANT migration tool).

So, first of all retrieve all objects from production by specifying in package.xml

<types>
    <members>*</members>
    <members>Account</members>
    <members>AccountContactRole</members>
    <members>Activity</members>
    <members>Asset</members>
    <members>Campaign</members>
    <members>CampaignMember</members>
    <members>Case</members>
    <members>CaseContactRole</members>
    <members>Contact</members>
    <members>ContentVersion</members>
    <members>Contract</members>
    <members>ContractContactRole</members>
    <members>Event</members>
    <members>Idea</members>
    <members>Lead</members>
    <members>Opportunity</members>
    <members>OpportunityContactRole</members>
    <members>OpportunityLineItem</members>
    <members>PartnerRole</members>
    <members>Product2</members>
    <members>Question</members>
    <members>Reply</members>
    <members>Site</members>
    <members>SocialPersona</members>
    <members>Solution</members>
    <members>Task</members>
    <members>User</members>
    <name>CustomObject</name>
</types>

Then deploy all retrieved objects to your developer account.

After this, retrieve all other stuff from production and deploy it to your developer instance.

I use ant tool when I want to migrate some functionality from production to my own custom developer account which is not connected to production and is not a sandbox.

Hope that helps.

share|improve this answer
add comment

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.