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.

1 Answer 1


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.

  • 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. Jan 22, 2013 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. :) Jan 22, 2013 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. Jan 22, 2013 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'. Jan 22, 2013 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. Jan 22, 2013 at 16:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .