Sandboxes

Up to this point, this chapter has been focusing on the mechanism for moving Force Platform components from a development environment to a production environment. Using two environments for development and deployment is not only a good practice, but a requirement for Apex code, which cannot be authored in a production environment.

You have probably been using a free Developer Edition organization for the examples in this book. For more details on the various license types, please refer to the salesforce.com company website www.salesforce.com.

The scenario also gets more complex if you are creating additional applications or customizations for existing organizations. A Developer Edition organization, such as the one you have been using, is great if you are developing a new application that doesn’t depend on customizations you may already have made to your production organization.

If, however, your project is to extend or further customize your existing environment, or to build a new application that intersects your existing setup in significant ways, you’ll probably want to develop and test in environments containing your current production configuration. You’ll also want these environments to reflect the Salesforce edition and licenses you have purchased, any applications you have installed from Salesforce and AppExchange partners, and other features you may have enabled or disabled.

A Force Platform Sandbox is a copy of your production organization that may be used for development, test, and training purposes. You can create a sandbox with a push of a button—just like using Force Platform itself, there is no special hardware or software to purchase and configure.

There are three kinds of Sandboxes:

• A Full Sandbox is a copy of all configuration and data from your production organization.

• A Configuration-only Sandbox is a copy of the entire metadata configuration, but not the data. This sandbox will contain the definition of all custom fields, objects, workflows, Apex code, Visualforce, and so on, but won’t contain any of the records your production users have entered. You can load data into a configuration only sandbox, but there is a limit as to the number of records which can be held in this type of sandbox.

• A Developer Sandbox is just like a Configuration-only Sandbox, except the data storage limit is smaller—about 5000 records.

All Sandboxes are a copy of a production organization, and are created simply with a push of a button. Different types of organization licenses come with different sandbox allowances. You should consult the license information area at www.salesforce.com for complete details on sandbox allowances. Since a Developer Edition organization is not a production environment, you cannot create a sandbox from this type of organization.

Tip

All production usernames will be modified as they are copied to the sandbox, by appending the sandbox name. This is convenient, because if you want to log into your ‘Dev’ sandbox, your username is just your usual username with ‘.dev’ appended. This makes it easy to remember your username for the separate organizations you may have access to.

A sandbox can be refreshed, erasing the sandbox configuration and contents and replacing it with a new copy, once 30 days have elapsed from the previous copy.

Sandbox Comparisons

The different types of Force Platform sandboxes are best suited for different purposes.

• Developer Sandbox

  The Developer Sandbox is usually the best environment for project development. Developer Sandboxes are intended to be readily available, so everyone on your team can have one or two to themselves.

  The storage limit of a Developer Sandbox should be ample for typical development tasks. Most of the time, while actually coding, a developer needs only a tiny amount of sample data to test their work, so the limit of 5,000 records for the Developer Sandbox is usually adequate. Small amounts of data can be loaded by hand through the web interface, but larger quantities of data can be loaded using the Force Platform Data Loader.

  The data limitation of a Developer Sandbox is, in some scenarios, an advantage. In some companies, development staff may have limited access, and possibly no access at all, to the production organization due to sensitivity of the data being stored. Development usually requires full admin rights, including Modify All Data and Modify Setup rights. In such cases, a production admin can provide a developer with full access to a Developer or Configuration-Only Sandbox without exposing sensitive data to an unauthorized individual.

• Configuration-only Sandbox

  Because the production data aren’t copied to a Configuration-only Sandbox, this sandbox is created or refreshed much more quickly than a full-copy and can provide an empty slate appropriate for some uses. With room to load test data into the Configuration-only Sandbox, corresponding to approximately 250,000 records, you can do more accurate production-level testing than with the Developer Sandbox.

  The Configuration-only Sandbox is very suitable for creating a test environment, in conjunction with a standard load of test data. You can use all the components from your production organization and simply reload the data with Data Loader when you want to begin a new round of testing. Although you can only refresh the sandbox itself every 30 days, you can reset the data as much as you need.

• Full Sandbox

  A Full Sandbox is an exact copy of an organization, including all the data stored within. Based on the amount of data in your production organization, creating or refreshing a Full Sandbox can take some time.

  But a Full Sandbox is sometimes required, based on company and compliance requirements. Some industries or customers have specific requirements for deployment processes to ensure consistent, accurate results in their applications. Sometimes this is the result of legislation, such as Sarbanes-Oxley or HIPPA. Sometimes they determine financial performance from reports in the application, and securities regulators monitor the accuracy of their published figures.

  A Full Sandbox can address these issues and provide a staging platform for your applications that can also be used for user acceptance testing with a full production load. There is a 30-day refresh limit on full sandboxes, but this limitation can be easily integrated into a full testing cycle. You can simply refresh a Full Sandbox as part of your monthly or quarterly testing cycle.

  Caution

  You cannot use a Sandbox as the originator of a managed package. Managed packages must have a specific originating organization. When a Full Sandbox is refreshed, the action essentially eliminates the previous version of the sandbox, which means the managed package will now be, in effect, orphaned.