📢 Attention Salesforce Certified Trailblazers! Maintain your credentials and link your Trailhead and Webassessor accounts by April 19th. Learn more.
close

Learn How to Test, Build, and Release with Salesforce DX

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 life cycle.

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 the Salesforce CLI during the entire package development life cycle.

Show the package development model: first stage is Code using scratch orgs; second stage is Continuous Integration using scratch orgs; third stage is Continuous Delivery using developer and partial sandboxes; the fourth stage is release using full sandboxes and ultimately the production org.

When you’re ready to perform manual or exploratory testing of your development work, push your metadata into a separate scratch org designated for that purpose (1). You never pull 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 Convert to Metadata Format to Build

Although package development is a great way to manage change in your happy soup of metadata, we still support the build and deploy process that parallels the current change set method. The Metadata API mdapi:convert and mdapi:deploy commands continue to handle build and deploy use cases.

At the start of a project, you can retrieve metadata source from an org and convert it to source format, then store it in a VCS. Once you’ve created and tested your app or customizations, you’re ready to create the deployment artifact. You can convert from source format back to metadata format, and then all your source is ready to deploy to a scratch org. You can deploy all the source, and the deploy operation takes care of updating the files that have changed. You can omit certain files from the deployment, and construct exactly what to deploy by modifying the package.xml file created during the convert process.

And the convert and deploy cycle continues. As you iterate on your DX project, you continue to convert source to metadata format for all release testing and continuous delivery use cases. Then, you can deploy it to the org using the Salesforce CLI. You can try out the deployment process using the CLI in the App Development with Salesforce DX module.

retargeting