Start tracking your progress
Trailhead Home
Trailhead Home

Test in the Integration Environment and Deploy Changes

Learning Objectives

After completing this unit, you’ll be able to:
  • Clone a change set.
  • Validate a change set.
  • Deploy a change set.

Head to the Finish Line

Now that development is done, it’s time for Calvin and Ella to verify that their changes work together and that they don’t break any existing Zephyrus customizations. After they are done with these tests, Calvin builds the final release artifact, a new outbound change set that contains all of their changes. They run a final sanity check with this new artifact to make sure they’ve captured all their changes. Finally, they plan and execute the deployment to production!

Deploy Changes to the Integration Environment

The Developer Pro sandbox now contains both inbound change sets. Calvin reviews the release tracking log to plan his deployment. If any manual deployment steps are required, he determines whether they need to occur before or after the deployment of the change sets.

His plan is to:

  1. Deploy his change set.
  2. Deploy Ella’s change set.
  3. Manually assign permission sets to users to allow access to the app.

Calvin deploys the change set containing his customizations to the Developer Pro sandbox in a single transaction.

  1. From Setup, enter Inbound Change Sets in the Quick Find box, then select Inbound Change Sets.
  2. In the Change Sets Awaiting Deployment list, click the name of the change set you want to deploy. Calvin chooses Language Training.
  3. Click Deploy.

If a deployment can’t complete successfully for any reason, the entire transaction is rolled back. If a deployment completes successfully, all changes are committed to your org and the deployment can’t be rolled back.

To finish the deployment, Calvin deploys Ella’s change set, then performs the manual migration steps required by his customizations.

Test with Other Change Sets

With everything in place, the team does extensive testing to make sure that both sets of changes work together and don’t break any existing functionality.

Of course, the team has to address any issues they find during testing. Calvin and Ella can make changes in the Developer Pro sandbox directly. However, the team’s process dictates that the Developer Pro sandbox is solely for integration and testing of multiple change sets, so Calvin and Ella decide to follow this process.

  1. Fix the changes in the Developer sandbox that contains the components to be changed.
  2. Create a new change set in that sandbox. This can be done by cloning the original change set or creating a new one.
  3. Refresh the Developer Pro sandbox, so that all the change set customizations are removed and it again matches production.
  4. Set up authorizations between the Developer sandboxes and the Developer Pro sandbox. (The original authorizations were removed when the sandbox was refreshed.)
  5. Follow the steps to deploy the changes from each Developer sandbox into the Developer Pro sandbox.
  6. Test the changes.

Prepare for Final Deployment

Calvin has just a few more things to do before he deploys the changes to production. Within the Developer Pro sandbox, he creates a new change set containing all the components found in the integrated change sets he and Ella tested. Then he deploys that change set to and does any manual steps in the Full sandbox, his user acceptance testing org.

The team performs one last round of tests to confirm the changes work as expected, and don’t break anything. Calvin recruits some users to try it out.

When everything works, Calvin prepares to roll out the new app.

  1. In Zephyrus’s production org, Calvin authorizes a deployment connection for the Developer Pro sandbox.
  2. He clones the change set he deployed to the Full sandbox org.
  3. He uploads the change set to his production org.
  4. He validates the change set in the production org.
  5. He determines a schedule for deployment when the production org usage is light.
  6. He announces the rollout on Chatter.

Clone an Outbound Change Set

After an outbound change set has been uploaded to another org, it can’t be uploaded to a different org. So Calvin now has an outbound change set in the Developer Pro sandbox that he has verified in the Full sandbox, but he can’t deploy it to production. To deploy the changes to production, he makes a clone of the verified change set.

  1. From Setup, enter Outbound Change Sets in the Quick Find box, then select Outbound Change Sets.
  2. Click the name of the change set you want to clone.
  3. Click Clone.

Validate the Inbound Change Set

Validation of a change set is a dry run of the deployment, showing the success or failure messages that occur with an actual deployment but not performing the actual work. If you’re planning a scheduled deployment and want to determine if the deployment can succeed in the time allotted, validate your change set. It makes things much more predictable.

Additionally, if the validation is successful, the change set might qualify for a quick deploy. Quick deploys work more quickly by not rerunning Apex tests during deployment.

Quick deployments are available for change sets and Metadata API components when the following requirements are met. That said, you don't need to perform a test deployment every time you deploy—this process takes time to complete, and the org is locked for the duration.

Warning

Warning

Validation locks the resources being deployed. You can still read and write data to the org, but you can’t make any setup changes that modify the metadata. Making changes to locked resources or items related to those resources can cause errors. Start a validation when things aren’t too busy, like during off-peak usage hours. Limit changes to your org until the validation process completes.

  • The components have been validated successfully for the target environment within the last 10 days.
  • As part of the validation, Apex tests in the target org have passed.
  • Code coverage requirements are met.
    • If all tests in the org or all local tests are run, overall code coverage is at least 75%, and Apex triggers have some coverage.
    • If specific tests are run with the Run specified tests test level, each class and trigger that was deployed is covered by at least 75% individually.

Calvin logs in to Zephyrus’s production org to perform the validation.

  1. From Setup, enter Inbound Change Sets in the Quick Find box, then select Inbound Change Sets.
  2. Click the name of a change set. Calvin clicks Language Training.
  3. Click Validate.
  4. After the validation process completes, click View Results. The validation of Calvin’s change set is successful.

If you receive error messages from your validation, resolve them before you deploy the change set. In change set development, the most common cause of errors is dependent components that aren’t included in the change set. For example, if Calvin’s change set did not include the Language Course Designer object referenced in the master-detail relationship on the Language Course object, deployment would fail.

Successful Rollout!

At the scheduled rollout time, Calvin deploys the change set and performs any manual changes. When the deployment is done, Calvin does a quick sanity check on the org. Then he announces the app is live in Chatter. Way to go, Calvin!

retargeting