Plan for Changes to Your Org
- Identify which development environment to use in each ALM step when working in the change set development model.
- Create a new sandbox.
- Establish a method for tracking changes made in a release.
If you completed the Application Lifecycle and Development Models module (if you haven’t, we recommend working through it before you read this module), you’ve already met Calvin Green from Zephyrus Relocation Services. In this module, the team at Zephyrus uses declarative change set development to deliver one of their Salesforce customizations.
Zephyrus wants to offer language training services for clients moving internationally. The company’s Education team now includes language specialists who are developing a wide variety of course types. Some clients are beginning to learn a new language. Others just need a refresher course. Still others are looking to learn a specialized vocabulary, possibly for work. There are many factors to consider when recommending a language course to a client.
Calvin and his team decide to use change set development to add language course information to their org.
Write Down Your Release Plans
Calvin puts his release plans in writing so stakeholders know what’s going on, and so there’s less potential for confusion. He also finds that writing things down often brings hidden issues to light. Assignments, test plans, decisions, and milestones are easier to think about in concrete terms than in the abstract. And Calvin knows that nothing’s set in stone—he expects to revise the plan throughout the release as new information becomes available.
Prepare the Release Environments
- Develop and test steps: Each team member has their own Developer sandbox to create their assigned customization. Developer sandboxes contain no production data.
- Build release: Each team member migrates their customizations from their respective Developer sandboxes to a shared Developer Pro sandbox for integration. Developer Pro sandboxes don’t contain production data, but you can seed them with testing data.
- Test release: For user-acceptance testing, the team uses a Full sandbox to create a complete replica of production. A Full sandbox includes production data.
- Release: After the release is in production, the team can use the Full sandbox created in the last step to train users without exposing production data.
Create the Environments
Calvin creates two Developer sandboxes to get started: one for himself and one for his colleague, Ella. In these sandboxes, Calvin and Ella create and test their respective customizations. By creating one sandbox for each developer, Calvin keeps changes isolated until the team is ready to integrate them.
Sandboxes are available in Professional, Enterprise, Unlimited, and Performance editions. Calvin shows Ella how to create a sandbox.
- From Setup, enter Sandboxes in the Quick Find box, then select Sandboxes.
- Click New Sandbox.
- Enter a name and description for the sandbox.
- Select Developer for the type of sandbox.
- Click Start Copy.
Creating the copy can take a while, especially if your production org has a lot of data or customizations. Calvin gets a notification email when the new sandbox has finished copying.
Calvin does the same thing to create a Developer Pro sandbox for integration and a Full sandbox for user-acceptance testing and user training.
Establish Your Change-Tracking Method
When you’re using the change set development model, it’s important to track every change, especially changes that require manual migration. When you manually migrate a change, you take modifications from one environment and re-create them exactly in another environment. You have to manually migrate a change if the changed component isn’t supported in Metadata API yet.
How does Calvin know which components are supported in Metadata API? The Metadata Coverage report shows you which metadata types are supported in Metadata API and other metadata channels. This dynamically generated report is your best source for metadata coverage information. To access the Metadata Coverage report, go to https://developer.salesforce.com/docs/metadata-coverage.
Calvin tracks every change and enhancement requested by the Sales team. He uses a customized tool that allows developers to log each change they make. To be on the safe side, Calvin makes sure the tool has fields for essential information about every change in a release and for changes made directly in production.
- Who is assigned to make the change?
- Does this change require manual migration?
- Which component is impacted by this change?
- Which orgs currently have the change?
- When was the change made in each environment?
Why does Calvin track changes made in production when they’re not part of a release in development? It’s the only way he can be sure that the customizations deployed won’t overwrite or unexpectedly change the behavior of the production org.
Almost every change Calvin or Ella makes with the Salesforce user interface is logged in the setup audit trail. Calvin cross-checks the audit trail against a report in the team’s change-tracking tool to avoid missing any changes.
For more information on using the setup audit trail, see Monitor Setup Changes in Salesforce help.