Salesforce Developer Deployment Sandboxes

salesforce-developer-deployment

https://trailhead.salesforce.com/alm_deployment/alm_sandbox - done reading
http://salesforce.vidyard.com/watch/ztQE-qJseZsWPUOYg7krfg - Release Management: Developing and Testing on Sandbox
https://www.youtube.com/watch?v=afK95S3UeyU - From Sandbox to Production: An Introduction to Salesforce Release Management
https://trailhead.salesforce.com/alm_deployment/alm_deploy

Sandboxes aren’t available in Developer Edition orgs. Sandboxes are available 
in some editions, including Professional, Enterprise, and Unlimited.

// Types of sandboxes:

There are four kinds of sandboxes:

1. Developer:  Developer sandboxes copy only the org’s configuration, no data. 
   You can create or load up to 200 MB of data, which is enough for many 
   development and testing tasks. You can refresh a Developer sandbox once per 
   day.

2. Developer Pro: A Developer Pro sandbox can store up to 1 GB of data (about 
   500,000 records). It’s otherwise similar to a Developer sandbox.

3. Partial Copy:  A Partial Copy is a Developer sandbox, plus a sampling of data 
   that you define in a sandbox template. You have limited control over the data 
   that is copied. You can choose the objects, but not the records to pull. The 
   sandbox can include up to 5 GB of data, which is about 2.5 million records, 
   with a maximum of 10,000 records per object. You can refresh a Partial Copy 
   sandbox every five days.

4. Full: A copy of your production organization and all its data. Because the 
   Full sandbox is an exact copy, the amount of data in the sandbox is the same 
   as your production org. You can refresh a Full sandbox every 29 days.

Full sandboxes are required only for performance and scalability testing, as 
well as for staging before final deployment. You might also need a Full sandbox 
to test triggers that make non-selective queries. For all other use cases, a 
partial copy of data is enough. For testing, it’s often better not to copy data 
at all, but rather load the same set of data every time. Data is time consuming 
to copy, and a large volume of data can take days to complete.

// Creating and Refreshing sandboxes:

Creating or refreshing a sandbox doesn’t happen via the Metadata API, so the 
components copied aren’t restricted to objects that have XML representations. 
Therefore, you get a true and complete copy of everything in the production org. 
After initial creation, you can refresh the sandbox, creating a new sandbox in 
place of the old one.

To create a sandbox:

1. Click on Setup
2. Click on Sandbox under the Deploy section in the left hand side
3. Click on Create Sandbox

You can supply data for testing in sandbox in several ways:

1. Use sandbox templates to provide real-world data that makes your testing 
   environment more closely resemble your production instance. Sandbox templates 
   are available only in a Partial Copy or Full sandbox.

2. Import external data into your sandbox to make repeatable testing easier 
   because the data set is static and can be relied on not to change.

Refresh your sandbox periodically to update it with data and metadata components 
from production. Refreshing sandboxes ensures that your sandbox doesn’t miss any 
changes that were deployed to production by another sandbox or manually 
introduced in production. When you refresh a sandbox, Salesforce rebuilds your 
environment and erases its old contents. The content in your new sandbox is 
replaced with a copy of the production org. Beware that it’s possible to 
overwrite all the development you’ve done in your sandbox. Therefore, it’s a 
good practice for each developer to have their own sandbox and make their own 
backups. Establish a process with the rest of the team for refreshing sandboxes.

How often you can refresh your sandbox depends on the sandbox type. 

// Copying Production Data with Sandbox Templates:

If you have a Partial Copy or Full sandbox, you can pick which standard and 
custom objects to copy over from production by using sandbox templates. Sandbox 
templates help you limit the size of your sandbox by limiting the data that is 
copied over. Generally, you need only a representative set of data for testing 
in sandbox, not all the data from production. Reducing the amount of data that 
is copied to sandbox can significantly reduce the sandbox copy time.

The sandbox template editor understands the object relationships defined in 
your org’s schema. Some objects are always included because they’re required in 
any org. As you select objects to copy, the editor ensures that the associated 
required objects are added.

To access sandbox templates:

1. From Setup, enter Sandboxes in the Quick Find box, select Sandboxes, then 
   click the Sandbox Templates tab.

2. Click New Sandbox Template or click Edit next to an existing template you 
   want to modify.

// Salesforce - Developer - Sandboxes - Importing Test Data:

You might think it’s more convenient to use a Partial Copy or Full sandbox, and 
simply avoid having to load data, but that’s not necessarily better than loading 
test data. Data on the production org changes all the time, so anything you’re 
repetitively testing can give you unexpected results. Static data provides 
consistency.

Generally, it’s better to load a small, representative set of test data into 
your Developer and Developer Pro sandboxes. When functionality changes 
unexpectedly, it’s easier to pinpoint where the problem occurred when the data 
is static. Developer and Developer Pro sandboxes also have a shorter refresh 
cycle.

Most people load data using CSV files and the data loader.

If you’re loading large sets of data, you can use the Force.com Bulk API. 
The Bulk API and supporting web interface allows you to upload and create 
import jobs, monitor and manage jobs, and receive notifications when the jobs 
complete. For more information, see Loading Large Data Sets with the Force.com 
Bulk API: https://developer.salesforce.com/page/
Loading_Large_Data_Sets_with_the_Force.com_Bulk_API

// Managing Sandbox Users and Logins

Anyone with a production login can log in to a sandbox. Although most users in 
the production org probably aren’t aware of the existence of a sandbox, you 
probably don’t want them poking around your development environment either. To 
manage access, you can deactivate production users in sandbox. That works out 
well, because the deactivated production users make room for developers, who 
usually don’t have a login to the production system, but need a login to 
sandbox. This user license trading is necessary, because you have a finite 
number of licenses.

The easiest way to give developers a login to sandbox is to create them as users 
in production, but don’t activate them until needed. After creating or 
refreshing a sandbox, deactivate production users who don’t need access and 
then activate the developer users. Just make sure that the user you deactivate 
in sandbox isn’t someone who logs in to that environment.

All licenses are copied from production to sandbox. If a new license is applied 
in production and you want to apply it to sandbox, you must refresh with the 
sync tool (see Match Production Licenses to Sandbox without a Refresh: 
http://releasenotes.docs.salesforce.com/en-us/summer14/
release-notes/rn_forcecom_sandbox_copy_licenses.htm).

When you create a sandbox, all email addresses, except the sandbox creator, are 
modified so that people don’t receive emails from sandbox testing. Note that 
email delivery defaults to off, so if you need to test automated emails from 
Apex or workflow rules, you must turn this setting on. Not only are emails not 
sent, but unit tests fail when Messaging.sendEmail throws exceptions.

// Use Profiles to Limit User Access

During a deployment window, you can use profiles to limit end-user access to the 
production organization.

1. Alert all active users about the maintenance window using the email wizard. 
   From Setup, enter Mass Email Users in the Quick Find box, then select Mass 
   Email Users.

2. Create a profile to lock users out during the maintenance window by editing 
   the login hours. Be sure that system administrators or integration users have 
   access if they need it.

3. Roll out objects, tabs, and apps to different user profiles if you want to 
   allow some users access for acceptance testing.

If your organization includes many profiles, use the following strategy for 
setting up a maintenance window:

1. Create a profile named Maintenance with all login hours locked out.

2. Use the Data Loader to extract and save a mapping of users and their user 
   profiles.

3. At the beginning of the maintenance window, use the Data Loader to change all 
   user profiles, except the administrator’s, to the Maintenance profile. It is 
   important to leave login access with the administrator. Otherwise, all users 
   could be locked out of the system indefinitely. If integrations are going to 
   run during the maintenance window, also don’t lock out the integration user.

4. At the end of the maintenance window, use the Data Loader to reload the 
   users with their original profiles.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License