We are currently in the process of moving from using Welkin Suite and Classic to SalesforceDX/VS Code/Scratch-Orgs. Is there a standardized approach or automated process for making a Scratch-Org look exactly like your Production Environment (Metadata/Packages/etc.)? Without this ability, how are we supposed to move to SalesforceDX? Is there any rationale for going SalesforceDX using Sandboxes skipping Scratch-Orgs entirely?
Add a comment
|
1 Answer
Is there a standardized approach or automated process for making a Scratch-Org look exactly like your Production Environment (Metadata/Packages/etc.)?
force:org:shape and force:org:snapshot are in pilot, so eventually there will be automated support. However, this does not help you right now if you're not already in the pilot programs. This means you'd have to do so manually.
Without this ability, how are we supposed to move to SalesforceDX?
For most cases, simply retrieving the metadata from production or a sandbox is the starting point. You don't need to move to DX "all at once." It's a migration process that may take time, and is probably best done in small pieces as you move forward. You can even do this as you're developing, which is what we're doing internally.
In our case, we have 10,000+ metadata artifacts in a single repo. We're using a partner product that allows us to diff and migrate changes between any two orgs and/or the repo. I'm actually creating the first set of Unlocked packages that we'll be using to eventually manage our metadata in DX, but it only includes about 20% of our base metadata at this point.
Is there any rationale for going SalesforceDX using Sandboxes skipping Scratch-Orgs entirely?
Sandboxes are perfectly acceptable. The downside to sandboxes is that they persist indefinitely. This means that it is harder to keep sandboxes up to date and/or delay commits until you feel the code is in a particular state. Having orgs that must be regularly refreshed prevents this sort of problem.
However, DX deployments are generally faster than Metadata-based deployments, and DX allows metadata packaging ("unlocked packages"), which has the ability to be upgraded, like managed packages, and can also delete metadata that is removed from such a package, and build dependencies on packages, such that you can install only core component packages when you don't need an entire deployment.
