Deploying source for a Managed Package to new development environments

Question

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.

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.