Where should the development be done? 1. Directly on PDE (Managed Package) 2. It should be done in Dev ORG and only after tested, do the deploying in PDE.
We have a team of 4 developers working on the same project. What are the best practices for development? 1. All programmers work on the same Dev ORG with Force.IDE. 2. Each programmer has a Dev ORG. At the end joins all the code in another Dev ORG.
Here is what worked best for me in past few projects (App Exchange apps)
Orgs
Initially have these two orgs:
Dev Org ( Type = Partner Dev Edition) : Used for actual developement.
Packaging Org ( Type = Partner Dev Edition): Used for uploading the managed released package to app exchange with a unique namespace prefix.
Dev org will be used by any number of developers working on the project. I don't suggest using different orgs for each developer, as merging back everything and making sure no one kills other is very tough and time wastage.
Once you feel something is stable and ready for QA/Testing teams to verify, then their could be a couple of approaches
Approach 1
Register a namespace prefix and upload a managed beta package from Dev Org, and give it to testing team. I am suggesting using managed beta because:
Testing team now can spawn new Orgs of required type from Partner Portal account, for ex. if you are targeting PE orgs, testers can spawn a PE org and install/test package out there.
Approach 2
Some guys don't like to pollute the Dev org with namespace prefixes, so for those cases you can push the code via Eclipse or Force.com migration tool (ANT) to another temporary Partner Development org, just to release the package for testing.
Rest of the stuff remains same as Approach 1
Approach 3
Push the code changes to Packaging org, and spawn a managed beta package for testers. Rest of the steps reamin the same as Approach 1.
FINAL RELEASE
In any of the above approach, Once the testing is done and you are ready for show time you can upload the package as managed released from the packaging org. Please note this will lock down metadata components included in the package, so take good care before taking this step.
Working with upgrades
Lets say you released version 1 of your app using any of the approaches indicated above. Your developers might have started development on phase 2 requirements in Dev org to release version 2 in few months. You will realize the benefit of having packaging org, if some bugs came out in version 1 of app, and that needs to be fixed asap. It might be possible that your Dev org code base has changed and is not ready for packaging, because of many unstable version 2 changes. Here one can make use of packaging org to fix the bugs in version 1 code base, and replicate the same with required code changes in Dev Org. So this way you can freely fix the version 1 bugs and release upgrades to your customers, and in the mean while the version 2 development will not be hampered.
seems too much text above, HTH :) !
Each developer should have their own developer org - this avoids contention between developers, in terms of overlapping changes to the same assets, introducing instability which affects your colleagues, and API usage (when using remote tools: Eclipse, ANT etc).
Use a source control system. Each developer checks in their changes as developed and tested in their org, and any merging / refreshing is done by the developer. Having multiple developers working on a project means that code has to be merged at some point. This can be done by collaborating in a shared developer org, but it is much better done by using a source control system designed for this purpose, providing you with a full, annotated history of the changes.
Each QA engineer can also then pull a version from source control into a QA (testing) org. Test results can be logged against a source label.
Have a separate packaging process working directly from source control.
