This article is based on excerpts from our whitepaper on Salesforce DX.

What is Salesforce DX?

At its core, Salesforce DX is a philosophy, derived from software development best-practice from a variety of platforms that’s been coalescing over the past couple of decades, and applied to the Salesforce platform in a way that shifts the current development model. This new philosophy is simple: version control is the source of truth.

Key features of DX

Salesforce DX encompasses a wide range of new features and tools, the detail of which you can see in our upcoming whitepaper. For the purposes of this article, we'll do a brief overview.

Scratch orgs

Scratch orgs are ephemeral orgs. They can be configured in terms of edition, feature enablement and preferences and created with the Salesforce CLI. Once created, metadata and code can be pushed to them and pulled from them with another CLI call. They’re necessarily short-lived - they’ll be deleted after a maximum of 30 days, but their durations can be configured at creation.

Scratch orgs are designed to be short lived and used for day-to-day development. Their main purpose in a DX-based process is to replace dev sandboxes.

A new metadata format

To address some of the issues around the current metadata format used by the Ant migration tool, Salesforce DX uses a slightly modified folder structure that breaks up some of larger, more complex metadata items (for example custom objects and translations) into subcomponents. It also comes with the added benefit of loosening some of the restrictions on folder structure, allowing you to introduce subfolders to organise your apex classes into, for instance.

The Salesforce CLI

The Salesforce CLI is essentially an iteration on the Force.com migration tool. It incorporates everything that already existed in the current tools, plus a number of new commands for manipulating metadata into the new DX format.

Using the Salesforce CLI instead of the Force.com migration tool allows you to control the new SFDX-introduced features like scratch orgs and second-generation packaging.

Second-generation packaging

SFDX introduces a new packaging model. The crux of this model is that you’ll add features to orgs by installing packages rather than moving sets of metadata, and when building out new features or extending existing ones, you’ll convert these to versioned packages and deploy them to downstream environments.

Dev Hub orgs

Every scratch org needs a home, and that’s where dev hubs come in. A dev hub is just a standard (paid) org that can act as a container for scratch orgs. In order to create a scratch org, you’ll first need to convert one of your existing orgs to a dev hub, or sign up for a dev hub trial org. Once you have a dev hub org, you can use the SFDX to start spinning up scratch orgs with the Salesforce CLI, and you can view and manage any existing scratch orgs you’ve created via the dev hub org’s UI.

Did this answer your question?