I’ve found a bunch of resources on how to setup and deploy/retrieve data to Salesforce Dx Scratch Orgs but only for extremely simple code bases.
Ideally, what I’d like to be able to do with Salesforce Dx is:
- Retreive all metadata (code and config) from my Production Org (all unmanaged package code/config).
- Create a new Salesforce Dx project and convert the Production Metadata to Dx project structure.
- Push the source to git.
- Push the newly converted production metadata to a scratch org.
- For each branch in git, do #3 and #4 to easily migrate branch code for testing to a scratch org.
My production code has a complex data model with over 4 dozen custom objects and complex code dependencies between apex classes, visual force pages, components, etc. For the life of me, I’m unable to get these code to push without encountering 1000s of errors.
My Questions are:
- Has anyone had success using this process to migrate complex production metadata to a scratch org?
- Winter 18′ has a pilot for migrating production shape to scratch orgs. There isn’t much documentation on this. Will this essentially copy all custom metadata to a scratch org?
There are different types of hurdles you will need to overcome to deploy to a scratch org. The same issues apply if you’re trying to deploy to a developer org (not developer sandbox), but scratch orgs allow you to overcome some of them.
From easiest to hardest:
- Org Edition and Features
- Org Settings
- Org-Specific Metadata
- Org-Specific Limits
- Known Issues
Some metadata can only be deployed to orgs with specific features enabled. For example, the
CurrencyIsoCode fields can only be deployed if the
MultiCurrency feature is enabled during scratch org creation.
You need to identify which features to enable in your scratch org definition file.
Some metadata can only be deployed to orgs when other metadata has specific values. For example,
Case.SourceId can only be deployed if the
IsLiveAgentEnabled setting is enabled.
These settings are stored as metadata so you can store them under version control. You can also deploy them to an org so you can adjust them while troubleshooting deployment errors. (Although some settings can’t be changed through the metadata API, or can’t be disabled once enabled.)
sfdx force:org:create supports setting some of the org settings so you can update your scratch org definition file once you figure out which settings you need enabled.
Some metadata can be tied to data in an org. You’ll want to try to break these dependencies by updating your metadata.
For example, Workflow alerts can reference Users. Since these Users won’t exist in the scratch org, you will probably want to update these to use Groups or Roles, which are stored as metadata, instead.
Custom Org Limits
You might have non-standard limits available in your production org such as an increased number of Sharing Rules allowed. This will have to be addressed through the new Org Shape functionality.
Known Issues and Bugs
There’s at least one known issue related to history tracking that will might prevent deploying the metadata from a large production org to a scratch org for the time being.
If you run into other errors, check the known issues and report them.