As Salesforce Dx has a unique idea introduced in terms of the source of truth, likely through Production Org, there is no record left of why, when, who made the specific changes in the program. However, these are considered to be important for the developers in terms of source control. So, the absence of these makes it difficult to consider the traditional environment of the actual source of truth the same as of Git repository.
Challenges with Scratch Orgs and solutions
Even though Scratch Org eased development life cycle in Salesforce Dx ecosystem, as a new product in the market, it still has many drawbacks; however, with a huge scope of improvement. Let’s discuss a couple of such challenges developers face now with new Salesforce Dx in terms of Scratch Org with some solutions for those.
Mirroring the exact configuration
One major hurdle faced by developers in Scratch org during development is its incapability to create a replica with the same configurations of the actual DevHub. There are different specific settings which are defined in the definition file of Scratch Org, but it may be so difficult to figure it out as to what the exact settings you may need.
It can also be noted that many options in it are weakly documented, and many of them may not work as desired. More than this, there are also some settings which the definition files don’t account for. In the end, you may get something which may be somewhat similar, but not exactly the same.
As Flosum.com points out, these mismatches between destination and development environments may cause many issues while the changes get migrated from the Scratch Org further to the Sandbox. This makes it troublesome to manage the profiles with Salesforce Dx, further wanting the developers to do many updates manually to get the changes deployed to the fresh org.
- A quick solution introduced by Dx to handle these problems is Shapes, which will further provide the feature of mirroring the Production in Scratch Org. This feature; however, is still at the pilot phase, which may be maturing over time.
Limited merger capabilities
Another big limitation while breaking org to different artifacts is that DX doesn’t have the capability to merge. The typical recommendation for this issue is that the metadata and functionality of the org needed to be broken down to smaller pieces to be independently managed. Salesforce additionally recommends that the fields and custom objects must be used only in a single artifact and not sharing. If you tend to manage a field or object in two artifacts, only the most recent change will exist, which may cause overwriting others’ work.
- Salesforce has come up with solutions for this problem in its next-generation variant. This will help to create artifacts containing shared metadata, which may create dependencies for the others involved.
By introducing Scratch Orgs, Salesforce attained the ability to handle the changes in the same traditional environment for development, but the old concept of Change Sets is largely changed. The major difference is that the customizations need not have to be tracked manually anymore. Instead, the DX captures all the changes from the Scratch Orgs of the developers in source control.
