Welcome to Developing and Testing on Sandbox, the next in the Release Management: From Sandbox
to Production series.
These videos explain the basics of managing the development and release of customizations
on the Force.com platform.
A sandbox lets you create a copy of your organization in a separate environment, where you can develop
and test customizations, without compromising the data and applications in your Salesforce
production organization.
Sandbox environments are almost identical to your Salesforce production organization,
and contain the same configuration information or metadata such as workflows, custom objects
and fields, and so on.
Depending on the type of sandbox you use, it may also include a copy of the data from
your production organization.
Because a sandbox is completely isolated from your production organization, you can safely
develop and test features, and train new users, with minimal risk to the data and day-to-day
activities of your production users.
However, not all customizations require a sandbox for example, if you're the sole administrator
for your organization, responsible for developing simple enhancements such as reports and list
views, you can quickly make these changes on production with minimal risk to your core
business operations.
When deciding whether to use a separate development environment, you need to weigh the complexity
it adds to your release management process against the peace of mind it brings.
For more complex features, such as workflow rules, custom objects, or Visualforce pages,
it pays to isolate development and testing in a sandbox environment.
Sandboxes are also a great way to protect your organization's data if you're working
with third-party contractors, such as IT consultants.
Salesforce provides several types of sandbox that offer different capabilities depending
on your needs.
Each edition has different sandboxes available, and you can buy more as you grow.
You can purchase multiple licenses for each sandbox type.
Sandbox licenses are hierarchical, so for example, if you have a Developer Pro Sandbox
license, you can create a Developer and a Developer Pro sandbox.
Let's take a look at AW Computing, who just bought Salesforce Enterprise Edition.
Cynthia and Aaron form the small IT team, and Aaron is the administrator.
As a sales organization, they track standard contacts, account, and orders. But they also
need a customized warehouse application to track company merchandise.
This high-risk customization is best suited to development on sandbox, so let's log in
to the production organization as Aaron to create a new sandbox.
From Setup, we can use Search to go to Sandboxes.
As you can see, each Enterprise Edition includes one Developer Sandbox.
Click New Sandbox, and enter the name and a description.
Let's call it AW test.
Use a name that describes the general use case of the sandbox and keep it short - for
example, QA or Training.
Salesforce appends the name to usernames and email addresses in the sandbox, so names with
fewer characters make sandbox logins easier to type.
Click Create.
The creation process may take some time. You'll be notified by email a soon as it completes.
During the creation process, try to limit changes in your production organization.
Now let's log in to the sandbox as Cynthia, the developer.
Users can log in to a sandbox at test.salesforce.com by appending the sandbox name to their Salesforce
usernames.
So here we enter cynthia@awcomputing.com and append the name of the sandbox .dev in this
case.
The sandbox environment is very similar to the production organization, but notice the
black sandbox label in the top right-hand corner.
Cynthia and Aaron can develop the Visualforce page, Apex controller, and customer schema
object needed to create the customized order workflow application.
Having finished development, Cynthia and Aaron now begin functional testing of the new features
on the development environment.
Remember: Always test and validate customizations in
your development environment before you upload and deploy to your production organization.
When you use a single development environment for development and testing, you should stop
development to test, and only resume development after you deploy the changes.
If you're developing Apex, you must meet code coverage requirements.
After functional testing is completed, pass new features to your business users to validate
that everything works as expected a process known as "user acceptance testing".
With testing completed, it's now time for Aaron to move the updates to the production
organization using change sets, which we'll cover in the next video.
For more information on the topic of release management, watch the rest of this video series.
You can also search for these guides in the Help and Training portal.
Thanks for using Salesforce!