In their raw form we find Scratch and Developer sandbox orgs of limited value.
- Developer sandboxes may be cheap to create but the cost of populating them with a rich set of data is high.
- Scratch orgs are worse than developer orgs — by default they are missing both data and custom configuration changes.
In our world, we have learned how to weaponize scratch and developer orgs and use them extensively. A Salesforce test org is weaponized if:
- The org can be created on demand.
- The org can be created entirely using automation.
- The org contains custom configurations (custom objects, code, permissions, etc.) unique to a specific problem.
- The org can be handed out like free candy to individual developers and/or automated processes.
This post is the first in series about weaponizing scratch orgs and will provide enough detail for you to do the same for your company.
Let’s look at how we do this for scratch org in Capstorm’s continuous build/test system.
Weaponize Scratch Orgs in Continuous Build/Test Systems.
We use Jenkins and have automated the process for weaponizing scratch orgs for unit and integration testings. On a daily basis, Jenkins job does the following (for many different scratch orgs):
- Check to see if a scratch org is missing or has expired (they expire every seven days)
- If a scratch org needs to be refreshed:
- Use sfdx to rebuild that scratch org.
- Use CopyStorm/Restore to upgrade the scratch org with our customizations (basically metadata deploys).
- Use CopyStorm/Restore to populate the scratch org with a rich set of data.
Basically, we have automated the process of a Salesforce migration. Would you like to know the details? Open the next post.