Salesforce scratch orgs have two glaring deficiencies for any use case which requires data.

• Scratch orgs do not contain any customizations used by the associated production org. They are plain vanilla.
• Scratch orgs do not contain almost no data.  It is pretty hard to test most development work without data!

This post describes how to automate the process of applying customizations and loading test data into a scratch org. In a real sense, we explain how to a Salesforce migration everyday in a completely automated process.  This is exactly what we do to create test scratch orgs for our continuous build/test processes in Jenkins.

Note: This post is a the last post in the following series:

• Introduction: How to Weaponize Scratch and Developer Orgs
• How to Create and Refresh Scratch Orgs using Automation

If you want to populate a scratch org with customizations and data then a source for this data is needed. Here is what we did:

• Hire an intern to create a rich set of data in a Salesforce developer sandbox. A developer sandbox is  good location because it will contain the meta data customizations from your production org.
• Backup the developer sandbox to a database to have  permanent copy that can be used to populate scratch orgs.

In particular, we did the following (for one of our test data sets).

• We hired an intern, Noah, for the summer and had him build a rich data set based on professional sports teams.
• We migrated a large number of custom objects we use for testing our products  into Noah’s sandbox.
• We created a backup of Noah’s sandbox into a PostgreSQL database using the product CopyStorm.  We used PostgreSQL because:
  • • We wanted a source of truth that individual developers and our continuous build system could share.

  We want developers to be able to create their own scratch private weaponized scratch orgs using the same automation as our continuous build system.

At the end of the process, we had several key artifacts:

• a PostgreSQL database which contained our test data and metadata
• a Salesforce sandbox we could enhance with more data and easily push to the PostgreSQL database.
• a script which could be schedule to regularly backup our test data to PostgreSQL.

If it is important to keep your test datasets under revision control, a good choice for a backup is a H2 Database. A H2 database has the nice property that it is stored as regular file which can be copied to move it to another system. No DBA is required.

In this step we enhanced our Apache/Ant script which creates a scratch org to also restore metadata and data to a scratch org.

Technically what we did was:

• Use the product CopyStorm/Restore to describe both the metadata and the data to restore.
• Invoke CopyStorm/Restore from an Apache/Ant script to restore metadata and data.
• Told Jenkins to run our automation every day.

Click on the CopyStorm logo below this text to launch a video demonstrating how we created a CopyStorm/Restore configuration file describing the metadata and data to restore.  Please be kind — this is a developer produced video.

After we created a Copystorm/Restore configuration file then we extended our Apache/Ant script to run CopyStorm/Restore automatically.

• We consulted the command line reference for CopyStorm/Restore.
• We updated our Apache/Ant script to run CopyStorm/Restore.

The entire automated scratch org build script follows. The new build targets are:

• installSchema — this pushes metadata to the scratch org.
• populateSchema — this pushes connected data to the scratch org

If you read the entire series of blog post on this topic you should be well equipped to weaponize your own scratch orgs and start using every last one of them. If you would like our test set of professional sports teams, drop us an email and we will be happy to give it to you.