AllanOricil
commented
1 year ago Org Shape can be used to mitigate both problems: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_intro.htm
Closed AllanOricil closed 1 year ago
AllanOricil
commented
1 year ago Org Shape can be used to mitigate both problems: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_shape_intro.htm
Describe the solution you'd like
Developers spend quite some time finding the right combination of features and settings when creating scratch orgs. The workflow is:
developers, 1 - create an initial config file with features and settings that they think will work with their package/metadata 2 - try to deploy their metadata, but it does not work because some features/settings are not enabled. 3 - repeat 1 and 2 multiple times until they find the right scratch org config for their packages.
Repeating 1 and 2 takes time because: 1 - time is spent while reading through docs to find feature/setting to add on the scratch org config file 2 - time is spent while waiting for the scratch org creation to reach its end
I believe that there could exist a web app to guide developers while creating Scratch Orgs. Its UI could provide features that help choosing the right features and settings. This web app could also be added to VSCode as an extension. You could package this app, and then run it from VSCode using a webview.
There could also exist a set of scratch org recipes that this web app could list? For instance, there could exist a Scratch Org recipe to work with Salesforce functions, one to work with vlocity, and another to work with Experiences? Maybe there are scratch orgs configurations that are so common that it would be useful if they could be shared between companies, or teams within the same company. Maybe these scratch org recipes could even be turned into snapshots.
Other problems that increase time while creating scratch orgs:
Sometimes Metadata can be deployed with no problems, but the Scratch Org still requires some additional configuration. These extra configs can be done in the Scratch Org's Setup, but later the same changes must also be added to the scratch org's config file, which is just duplicate work. If the person does not know the name of the config he/she did in the setup, he/she has to spend additional time looking in the docs. Because it is a manual step, a configuration can end up being forgotten, which could lead to additional waste of time.
This problem could be solved if Scratch Org features and settings were tracked. If the state of a Scratch Org is saved somewhere, there could exist a command to enable developers to extract it and create their scratch org config file.
sfdx force:org:retrieve -a <org_id|org_alias> [-d <dir_and_file_name>]If sfdx creates this command, then you can also create a new command for VSCode.
Describe alternatives you've considered N/A
Additional context N/A