This article is based on excerpts from our whitepaper on 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.

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

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 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.

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 with which to organize your apex classes, for example.

The Salesforce CLI is essentially an iteration of 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, such as scratch orgs and second-generation packaging.

SFDX introduces a new packaging model. The essence 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.

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 either convert one of your existing orgs to a dev hub or else 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 through the dev hub org’s UI.
​
You can read how Salesforce DX is helping the DevOps process here.