Learn How to Test, Build, and Release

Learning Objectives

After completing this unit, you’ll be able to:

• Describe how scratch orgs support various types of testing.
  
• Describe the role of sandboxes in deployment.
  

Testing and Continuous Integration Using Scratch Orgs

How you test, build, and release with package development is a shift from the current application lifecycle.

If you’re currently using the change set development model, you move org changes (deltas) between development and test environments until those changes are released to your production org. At the end of the day, the “source of truth” is the production org. Even if you track changes externally in a version control system, you know with certainty that everything resides in your org.

But now you have options! In the package development model, the new and improved source of truth is your version control system. You use Salesforce DX projects to organize your source into package directories. Your end goal is to create packages using those directories that are versionable, easy to maintain, update, install, and upgrade.

You can use Salesforce CLI during the entire package development lifecycle.

When you’re ready to perform manual or exploratory testing of your development work, deploy your metadata into a separate scratch org designated for that purpose (1). You never retrieve anything from that org, as it’s only being used for testing or validation.

Continuous integration (CI) is about automating consistent test runs against every set of changes merged to your application (2). This important process ensures application quality before any corrupt change can get into your source repository.

Scratch orgs can be easily integrated into a CI process. The CLI can create scratch orgs, so scripting them into a CI flow is a piece of cake. You can populate the org with the appropriate version of the source repository and run tests on the specific change.

Unlike developer sandboxes, scratch orgs can be created throughout the day as opposed to a single refresh per day. You can delete a scratch org and create a new one quickly when the need arises. You can have multiple scratch orgs for different purposes. Scratch orgs give you a ton of flexibility with limited overhead.

When you’re ready for release testing or continuous delivery automation, you create a package version. Instead of using change sets to move changes between environments, you create and install package versions (3) in each testing environment. Once you complete testing, you install a package version in your production org.

Continuous Delivery Using a Sandbox

For continuous delivery, you want to start testing the same process that you use when you deploy to your production org. In this use case, you want to test with the package you created in the build phase, and install it in a sandbox, which is the best representation of the production org. In a sandbox, you can replicate and test the steps you use to release to the production org.

You Can Still Deploy Just a Set of Changes

Although package development is a great way to manage change in your happy soup of metadata, we still support the ability to pick and choose what you want to deploy outside of a package. Use the Salesforce CLI project deploy start command to handle build and deploy use cases.

After you’ve created and tested your app or customizations, you’re ready to create the deployment artifact. You can deploy all the source, and the deploy operation takes care of updating the files that have changed. As you iterate on your DX project, you can continue to deploy the changes to the org using Salesforce CLI for all release testing and continuous delivery use cases. You can try out the deployment process using the CLI in the App Development with Salesforce DX module.

Resources

• Developer Guide: Salesforce CLI Command Reference
• Developer Guide: Salesforce DX Developer Guide
• Trailhead: Unlocked Packages for Customers
• Video: Continuous Integration and Continuous Delivery with Salesforce DX