Source of Truth in Salesforce DX and Managing the Declarative Changes

Salesforce DX offers the developers an option to custom code the apps locally and then first deploy it to Sandbox Org or Production Org from the command line interface. Bust as any expert developer may think, no development process is complete without a source of truth.

It is okay to make any changes in the IDE of your choice, but what will happen when multiple developers work on the same file simultaneously? What may happen if someone makes a change in the code and want to revert later? So, if there is no single source to track and manage the changes, the development process will result in utter confusion and delays.

Adding to it, even though custom Apex code is crucial to any Salesforce environment, someone who has already tried Salesforce may know that most of the customizations and functionality are outside the Apex classes. The major strength of Salesforce is primarily about the customization features offered with simple point-and-click tools, so it is necessary to track the changes to these components as like tracking codes.

Previously, all such tasks are managed with the Change Sets, which was the Salesforce to move any metadata changes across the orgs. Change Sets need a developer or an admin to track all the files manually to keep track of the processes, flows, fields, objects, etc., to track the changes. They had to select each of these components to deploy it to the other related environments further. Flosum.com points out that this approach is not only tedious but also prone to errors as no single environment is a guaranteed source of truth.

Salesforce DX solution

Taking up the above-mentioned matter seriously, Salesforce DX now enable the developers to create a temporary and personal org where they can try to changes in isolation to be pulled into another local environment, and then try to deploy it to the Sandbox and Production orgs. The feature is available as DevHub got enabled at Performance, Enterprise, or Unlimited Edition org.

You can consider Scratch Org as a private playground for development where the developers can write code and customize the configurations without the concern that their work may interfere with the changes anyone else made and vice versa. The JSON definition file for Scratch org can be easily customized with many configurations and preferences. It will allow for quick setup or an org which approximates the Production Org’s shape.

In fact, the Scratch Orgs are owned simply by the one who creates it, which are simply meant to be created and destroyed based on the need. Salesforce gives a maximum lifespan to Scratch Orgs of only 30 days, which prevents the app developers from working consistently stale environment. Even though the Scratch Orgs are independently owned, the base definition file may be managed at the repository where all developers can work in an identically shaped environment.

The solution of Scratch Orgs from Salesforce DX offers a new dimension to the application development. It not only allows the developers to write the code in an IDE and push it to the real ground for testing but also enables the option to capture all the configuration changes done through the Salesforce UI. The declarative changes can be easily tracked in the source control, which was merely impossible before.