Developers / DevOps

What is Salesforce DX? The Definitive Guide

By David Runciman

Salesforce Developer Experience (‘SFDX’ or just ‘DX’) is a set of tools designed to improve the traditional developer’s experience of building on the platform. 

Salesforce’s “clicks not code” philosophy revolutionized CRM customization and empowered a generation of admins and configurators to become no-code or low-code developers. But by 2018, it had become clear that pro-code developers were stretching the limits of a platform that hadn’t been designed with their workflows in mind. Salesforce DX was their answer to that problem.

What Are the Benefits of Salesforce DX?

DX isn’t just about developer tools. Salesforce’s overarching aim for DX was to support source-driven development, and this benefits everyone building on Salesforce. What’s more, it didn’t take long for Salesforce’s partners to build DX functionality into their DevOps solutions, making DX workflows accessible to no-code developers and admins. 

Today, you can spin up a new scratch org, create a new feature branch, make changes and deploy between those environments, pull in masked data from Production for testing, and merge to the main branch, all without touching the CLI. This means mixed teams of developers and admins can follow the same DevOps process, making the most of DX functionality, and using their preferred tools for development and releases.

Salesforce DX Tools and Features

Salesforce released a range of new and improved tools, APIs, and features as part of DX. These tools are all designed to work together and have the common aim of facilitating a package-based, source-driven development, and release process. But you can use some DX tools without needing to use them all. Your team’s workflow may or may not call for everything DX has to offer, and different members of your team will use the DX tools that make sense for their role.

The Salesforce CLI

The Salesforce command-line interface (CLI) superseded the Ant-based Force.com migration tool. It offers all the functionality of Ant and more, including commands for pushing and pulling metadata to and from orgs, converting metadata to SFDX format, and managing other DX features. If you’re a developer, you’ll want the Salesforce CLI bringing the power of DX to your fingertips.

READ MORE: What is the Salesforce CLI? (And How to Use It)

Integrated Development Environment (IDE)

Salesforce also released extensions for Visual Studio Code that make the lightweight, extensible code editor an ideal IDE for working with DX, and which effectively replaced the Eclipse-based Force.com IDE that has since been retired. Salesforce continues to iterate on IDE tooling; this year it released Code Builder, a web-based development environment.

READ MORE: Salesforce Code Builder – The Developer Productivity Tool

DevHub and Scratch Orgs

Scratch orgs were a DX innovation: temporary orgs that can be created as a fresh environment when wanting to start ‘from scratch’ (hence the name), then deleted, or allowed to expire. Scratch orgs exist for no longer than 30 days, but when spinning up a new scratch you can specify an even shorter lifespan, as well as the shape of the org and the features it has enabled. To create and manage scratch orgs, you need to enable a permanent org, usually Production, as a DevHub. Scratch orgs can be created from within the UI of a DevOps solution, or from the CLI.

READ MORE: Get Started With Salesforce Scratch Orgs

Second-Generation Packaging (2GP)

Packaging your metadata avoids having an unstructured org, which can be more difficult to manage and modify because there’s no separation of concerns. Before DX, Salesforce already offered a way for teams to package up metadata into logical units that could be installed in orgs, but DX brought second-generation packaging (2GP) with a whole raft of improvements over 1GP. 

The most important change is that 2GP makes version control the source of truth for packages’ metadata, rather than a packaging org. These packages are also referred to as unlocked packages. If your team is going down the packaging route, use unlocked packages so you can follow a best practice DevOps process with version control.

A New Salesforce DX Metadata Format

Salesforce DX also introduced an improved format for metadata. The key difference is that big, complicated metadata types such as custom objects and translations are broken down into more manageable subcomponents when you switch to DX format. For developers, this change makes files much easier to work with in your IDE. 

The new metadata format also benefits the whole team by making merge conflicts less likely. When developers and admins make changes that affect the same files, they tend to run into merge conflicts that Git doesn’t know how to resolve. Splitting apart the metadata into smaller, separate files means teammates are more often working in different files and will have fewer merge conflicts to resolve.

Salesforce’s Dependency API

Among the upgrades to Salesforce’s APIs, the Dependency API is yet another feature of DX that helps teams understand and handle the complexities of orgs with countless dependencies between metadata. The Dependency API remains in beta, but can be used to query which components reference other components and vice versa.

Salesforce DX and DevOps

Salesforce DX doesn’t offer everything needed for Salesforce DevOps. For a fully mature, robust DevOps process, Salesforce teams need tools for version control, continuous integration, test automation, and backups. But DX does make it much easier for Salesforce teams to adopt version control and a source-driven process, and so DX has contributed to the rise of Salesforce DevOps.

Version Control and Source-Driven Development

Adopting version control is an essential step towards DevOps maturity. Whether they’re working in separate developer orgs or the same sandbox, teammates will always tread on each other’s toes without version control; one person’s changes overwrite or break someone else’s changes, causing confusion and extra work. This is true for small teams and becomes a chronic problem for larger teams.

Version control is the solution to this problem, so developers expect to be able to use it for Salesforce development. But since Salesforce wasn’t built with source-driven workflows in mind, using version control wasn’t always plain sailing. With the release of DX, Salesforce threw its weight squarely behind version control, advocating source-driven development with the main branch of your Git repository as the source of truth, rather than your Production org.

READ MORE: A Guide to Git (and Version Control) for Salesforce Developers

Continuous Integration and Automated Workflows

Highly automated processes for testing, releases, and backups are the end goal for teams implementing DevOps. Once teams have fast, reliable deployments and have adopted version control, they can begin to introduce automation to their release pipeline. The move to CI/CD is much more likely to meet success with smaller, more frequent releases, and DX helps here by enabling you to keep changes limited to fewer files or particular packages.

READ MORE: Build Your Own CI/CD Pipeline in Salesforce (Using GitHub Actions)

An Example Salesforce DX Workflow

There’s no one workflow that suits every team, but the following example guides you through a typical workflow that uses the feature branch model. The deployments could be performed using the CLI, with automation handled by a toolchain of open-source software. Or the whole process can be managed using one DevOps solution.

  1. When beginning a new work item, first create a feature branch from the main branch of your Git repository.
  2. Spin up a scratch org using a definition file kept in your Git repo.
  3. Make changes in the scratch org or IDE, keeping the scratch org and branch in sync.
  4. Once the work item is ready for review, create a pull request and assign it to a teammate.
  5. After the review (and any changes requested) merge the branch into main. Then delete the branch.
  6. The work item is ready for UAT or QA! A continuous integration job can automatically deploy to your testing environments.
  7. Once testing is complete, release to Production!

Adopting Salesforce DX

There are plenty of options to explore when it comes to Salesforce DX, with freely available tools and features you could try out. Not every team chooses to use scratch orgs or second-generation packaging, but the SFDX metadata format and constantly improving tools for Salesforce developers have streamlined development in general and DevOps in particular. For more guidance on how and when to begin making the most of Salesforce DX, you can download Gearset’s free whitepaper, Adopting Salesforce DX.

The Author

David Runciman

Technical Author at Gearset, the leading DevOps solution for Salesforce.

Leave a Reply