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.

Our Managed Package is quite large and we are looking to spin up a couple of new Developer Edition environments for our developers. I'm wondering how others are managing the initial metadata deployment from the publishing org to the development orgs. The initial deployment of the package assets is always the tricky part. What is the process and tools that others have used to do this kind of deployment.

share|improve this question
add comment

1 Answer

If you have reached this tipping point. IMHO it is best to consider moving to some kind of source control system to manage and track your application development amongst multiple developers. This typically requires broadly speaking the following.

  1. Extract. Using something like Eclipse or the Ant tools to extract your current packaging org contents (closing the door behind you asap to avoid further edits).
  2. Initial Source Control Upload and Developer Extract. Then uploading that into SVN, Git or something else of your choice. Make sure you retain the folder structure at some point in your chosen source control structure. This will make it easier for developers and testers to push the code into their developer orgs once they have checked it out.
  3. Build System Integration. Optionally. You might want to consider checking in your Ant script and hooking it up to a Hudson/Jenkins CI build that pushes to a designated 'build org' either on a scheduled or source control modification basis (true CI). This can also run your unit tests. *

    • As a further enhancement and well worth it if you hit package limitations for released components often. Is for it to also run a second deploy of the current source control contents into your packaging org utilising the 'checkonly' feature. This saves a lot of pain when you get further down the road and find one of your developers has made a change in an unmanaged developer org that is not supported in your packaging org.
  4. Packaging. Once you reach a point where your done with a stable build in source control and want to start to move towards a release. You would then use a simalar process as step 2 to push back into your packaging org. Upload and perform further regression testing etc on the resulting package.

More Thoughts This is definitely an area that could do with a solid bit of Wiki work on it, as it is coming up all to often and the above does have different technical options and gotchas depending on your development team skills (around dev infra scripts, tool, servers etc) and your own requirements. FinancialForce.com did present some tools and thoughts on this at last years Dreamforce, the results are available here. In the meantime I think we as a community should look to pull something together perhaps on the Force.com Developer Wiki?

Update: RE: Step 1. As your packaging org is a namespace enabled DE org, it is possible your Apex code, VF pages or other components have gained namespace prefixes. These will need to be swept out before you can start deployments into regular (unmanaged) DE orgs. The good news is, once you do this once, you don't have to repeat it (see also step 3 to keep things this way). And future deployments from source control be they to your developer DE orgs or ultimately to your packaging org will work just fine. There are some gotchas to watch out for in terms of namespaces, typically most of them are now mitigable by using the correct $ variables in the most sensitive places such as VF pages.

share|improve this answer
    
We have everything under version control using git/github. That's not the issue. The issue is taking a huge chunk of metadata from the publishing org and trying to deploy it to a fresh dev org. There are always errors and it's a lengthy process. Git doesn't help here. Ant was my preferred tool but simply grabbing all metadata and deploying to a blank org NEVER works. –  Kevin O'Hara Jan 22 '13 at 15:51
    
I see, why are you not deploying from the contents of your source control system? It sounds like your packaging org is still being used for active development? Once you do manage to get everything in source control and it deploys to both your unmanaged DE orgs and packaging org successfully. You can ensure things stay that way via the watchful eye of a CI build system. :) –  Andrew Fawcett Jan 22 '13 at 15:53
1  
No, there is never development done in the packaging org, ever. Trust me, I'd love to just clone our repo and deploy it all to a new org but the metadata api is too finicky. We are talking about a lot of metadata here. The metadata api barfs every time. Subtle differences in orgs throw everything off. Example: our publishing org was created when the Self-Service portal existed so there are SF fields for that in the objects that can't be removed. In newer orgs, Salesforce stripped SSP and the corresponding metadata. Causes fatal error. –  Kevin O'Hara Jan 22 '13 at 16:04
    
Oh dear that does sound like a terrible situation. Personally if it was me and I had a metadata deployment that was not giving me reasonable errors as to what to remove dependency wise, I would raise a case and have Salesforce support repo it and work on it until it does. Or at the very least give me some insight as to what internal messages are hidden behind the dreaded fatal errors from the metadata api. Failing that in the past I have used a layered incremental approach to debugging metadata deployments, deploying 'schema' components first before any 'code' components'. –  Andrew Fawcett Jan 22 '13 at 16:13
    
In addition, the metadata api seems to like large metadata pushes to be done in chunks...and order matters. It usually comes down to deploying using multiple pushes with a lot of trial and error. –  Kevin O'Hara Jan 22 '13 at 16:13
show 6 more comments

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.