Develop on a Sandbox or Dev org?

Perhaps the single most important factor in Force. com development is whether you're developing software for a specific organization or trying to develop a package for general use that will be installed on multiple organizations.

The first place where this question comes into play is whether you should build on a sandbox or a development org.

A sandbox is the right choice if you're targeting a single organization. That's because the sandbox has a copy of the metadata for the production organization. It's configured the same way, and your application can be optimized and targeted specifically for that organization.

Developing on a sandbox does carry with it one huge risk, and that is that at any time a sandbox can be refreshed from the production org. That means that a system administrator can click a button, refresh the sandbox, and any changes that you've made on that sandbox to your code, to your metadata, to objects, fields definitions, any changes you've made will instantly vanish.

This, by the way, is one of the main reasons that most professional Apex developers choose an external IDE over the developer console because we've been burned by this in the past. When you use an IDE, you have that wonderful local copy of the metadata on your system, and you can recover your work after a sandbox refresh.

If you're doing general application development, a package that is intended to be released on the app exchange or to be used on multiple organizations, things are very different.

Do all of your development on one or more developer orgs. Only when you are satisfied with the code should you push it to the package release org.

Use an IDE or the Force. com migration tool to deploy code to numerous QA and test organizations.

Not only will you have other organizations that are used by QA personnel if you have them, but more important, you'll have other QA organizations that are configured differently. For example, on one QA org, you might enable the multi-currency feature so that you can test your application with that feature enabled. On another org, you might enable person accounts so you can test your application with that feature enabled.

Your main development org should always be configured for the minimal feature set that you wish to deploy against. But you still have to test your code for organizations that have additional Salesforce or Force. com features enabled.

So what is the best way to manage process when doing team development. There's not yet any real consensus answer to that question, but there are some common outlines. Except for small projects developing for specific orgs, you'll rarely see developers sharing a developer org.

They'll use separate sandboxes or developer orgs for development and testing their own changes. They will then deploy to a common sandbox or developer org for staging. Think of this as the official build system. It's common to deploy metadata to this org by way of a repository.

In other words, developers commit their copy of the metadata to a common repository, and tooling uses the migration tool to deploy from there to the common staging org and possibly one or more QA orgs. Nobody is allowed to make metadata changes on the staging org directly. They have to go through the repository.

From there, after testing is complete, metadata is deployed from the staging org, either to the production org in the case of specific org development, or the packaging org when creating a package for distribution.