In force.com terminology, promoting changes from one organization to another is called migration. There are currently two methods for migrating changes between salesforce organizations. One method is to use Change Sets. This article will introduce you to Change sets and Sandboxes.
Change Sets are a mechanism for bundling up changes from one Salesforce organization to another. However, all of the Salesforce organizations must be related to one another. That is, Change Sets are limited to a Production organization and any sandboxes created from it. They cannot be used to deploy changes from a different Developer Organization.
Depending on the edition of Salesforce that you are using, Sandboxes may not be an option for you. At the time of this writing, the Enterprise Edition comes with one developer sandbox and the Unlimited Edition comes with 15 developer sandboxes, 5 configuration-only sandboxes and 1 full copy sandbox. If you are using the Professional or Group Editions, sandboxes are not available.
The only difference between a developer sandbox and a configuration-only sandbox is the amount of data that each can contain. A developer sandbox is limited to a total of 10 MB while a configuration only sandbox is limited to 500 MB of data. For the most part, data for standard objects and custom objects is not included, although there are a few exceptions such as price books and products. These sandboxes will also include reports, dashboards, apps as well as customizations found in the production organization at the time of creation or a refresh. Refreshing developer and configuration-only sandboxes can occur once per day.
A full copy sandbox is a duplicate of your entire production organization. Everything is copied over, making it ideal for pre-production testing before rolling out new functionality, whether that is a new package from the AppExchange or your own customizations. Because of potential for containing a large amount of data, Salesforce limits the ability to refresh a full copy sandbox to every 29 days.
Creating a sandbox does not automatically enable Change Sets to be moved from sandbox to sandbox. A Deployment Connection needs to be established between each organization. In addition, you must specify the direction in which Change Sets are allowed to flow, either Inbound or Outbound or both.
What have you noticed about working with Change Sets, Sandboxes and Deployment Connections?
Force.com: Improving Enterprise Development in the Cloud
Over the next couple of articles, I will share my thinking about what additional tools and capabilities are needed in order to meet the current standards found with Java and/or Microsoft.NET technologies for producing software for enterprises.
To be clear, when I speak of Enterprise Development I mean software development projects that are large enough that require coordinating the efforts of multiple developers over several weeks or longer periods of time. I am not speaking of development efforts that can be accomplished by a single developer in a relatively short period of time, because these types of projects do not necessarily require the practices and coordinations needed to deliver a successful outcome.
Another thing for both of us to remember is that the force.com platform is specifically different than traditional enterprise platforms in that there are new constraints that we are forced to accept if we want to “play” in their sandbox. That being said, there are already, existing and accepted fundamental practices that enterprise developers have been using for a long time simply because they help us take better care of our employers, customers and clients.
What practices and tools do you notice that are missing, weak, flawed or incomplete in Salesforce.com and/or Force.com?