Change Management

It’s important to provide your team with a safe place to implement new features using sandboxes. They should learn to master change management with change sets and learn which other tools can be used to move organization configurations from one organization to another. It is equally important to learn how to pull and push data using the tools the organizations come with.

Once our organization is secure and being proactively monitored, we can move on with the change management of metadata and data by describing different sandbox types that we can use to implement and test our organization’s new features, different ways to move configurations between organizations, and finally, how to move data from organization to organization.

In this chapter, we’ll learn about the following topics:

• More about Salesforce sandbox types
• Using change sets to move changes from one sandbox to another
• Alternative tools to move changes
• Suggested tools for loading and pulling data from an organization

Testing using sandboxes

Although a popular meme featuring Chuck Norris states that Testing is for wimps, real men test in production, believe me when I say this is not a good philosophy!

The ability to develop and test in dedicated and safe environments is key to the success of your efforts, whether it’s a 1-year project or a 1-day highly intensive bugfix.

Sandboxes give us and our team the chance to work in an isolated place that mimics (more or less) production, where we can make all sorts of custom configurations and developments and test with production data or even train our users. Everything is done with the different kinds of sandboxes at our service.

Sandboxes can be created, deleted, cloned, and refreshed. Moreover, when a new Salesforce platform release is ready (this happens three times a year, with the winter, spring, and summer releases), sandboxes are the organizations where these major platform releases are first implemented by Salesforce before affecting production organizations, allowing us to test new features or make no regression tests. Depending on your organization instance (that is, the csXX in your sandbox’s URL, for instance, https://cs88.salesforce.com/) and depending on specific limit dates before each release, you can decide to refresh a given sandbox to see the new release as soon as possible or only when production has been upgraded.

When a sandbox is created, it inherits all the metadata configurations from production (or the other sandbox from which it was cloned) and, depending on its type, some, all, or none of the data of the source organization.

Sandbox organizations can only be created from the Setup | Environments | Sandboxes page from production. Here is an example:

We can have different kinds of sandboxes, all of which we’ll be describing shortly:

• Developer sandbox
• Developer Pro sandbox
• Partial Copy sandbox
• Full sandbox

We’ll also have a look at how we can put an architecture of diverse sandboxes together so that we can handle changes from one testing organization to the other until production.