Salesforce’s early success was driven by empowering low-code developers to build and customize the CRM platform. That original vision for click-based development still lives strong: just look at tools like Agent Builder, Flow Builder and Experience Builder.
But ever since Salesforce released Apex as its programming language in 2006, it’s been clear that “traditional” developers still have a vital role to play. And with hindsight it’s also easy to see the naiveté of imagining that low-code development didn’t need the DevOps practices that have been embraced by the wider engineering world.
In the mid-2010s, third-party Salesforce DevOps solutions began to appear, accelerating awareness and adoption of DevOps practices in the ecosystem. Salesforce itself responded in 2018 with Salesforce DX (“Salesforce Developer Experience”, sometimes just “SFDX” or “DX”).
What is Salesforce DX?
Salesforce DX is a set of features designed to make source-driven development easier on Salesforce for traditional developers. It isn’t a set of DevOps tools, but Salesforce DX has helped Salesforce teams adopt DevOps, which was Salesforce’s intention.
Why does Salesforce DX still matter?
Salesforce now has a native low-code offering for DevOps, as it released DevOps Center in 2022. But DX still matters. Salesforce DX isn’t a direct alternative to DevOps tools, but mostly complementary. Some of its features (e.g. scratch orgs) can be used alongside or even within DevOps solutions; other features (e.g. DX format) have been leveraged by other DevOps solutions to be more effective for users.
Is Salesforce DX free?
Yes — all of the Salesforce DX tools covered in the rest of this article are completely free to use. In the past, Salesforce advocated for application lifecycle management (ALM) using org-to-org deployments. But Salesforce now promotes DevOps best practices, including version control and CI/CD, and so it doesn’t currently charge for DX or DevOps Center.
Salesforce DX: tools and features
DX format: a better metadata structure
Before DX, one of the most significant challenges for developers was the relatively unstructured “happy soup” of Salesforce metadata. Because Salesforce was designed for no-code development, the metadata that defines org structure and behavior wasn’t designed to be read by developers or managed in version control (Git). Developers would find themselves routinely working with enormous XML files for many metadata types.
The new DX format (or “source format”), now available as an alternative to the original Metadata API format, is a significant improvement. It breaks down larger components into more manageable subcomponents, and allows for an orderly folder structure — much easier for developers to read and work with. Breaking down large files into multiple, smaller files also significantly reduces the likelihood of merge conflicts in version control, as it’s less likely that developers will be making changes to the same files.
If you still haven’t made the transition to DX format, Gearset can help. When you’re committing metadata to version control with Gearset, it detects the format you’re using and matches that. If you’re populating a new repository, Gearset will write the metadata in DX format by default.
Integrated development environments (IDEs) for developing Salesforce
Salesforce has continually improved its no-code development tooling. Creating Flows, Agents, Digital Experiences and more is a great experience. Ultimately though, traditional developers want to work in an integrated development environment (IDE) and have the same great experience.
Before DX, developers had been able to use the Force.com IDE based on Eclipse. As part of DX, Salesforce initially released extensions for Visual Studio Code (VSCode), which was fast becoming the most popular IDE among developers. A year later, Salesforce retired the Force.com IDE, encouraging developers to use modern, open source tools.
Since 2023, developers have also been able to use Code Builder in their web browser, matching the VSCode functionality on their desktop. And Agentforce for Developers is now bringing the power of LLMs to coding for Salesforce. Developers can use natural language prompts to generate code, as well as getting suggested auto-completions and improvement for code.
Source tracking your changes in Salesforce orgs
For many low-code Salesforce teams, having a version control system (VCS) is still a relatively new concept and Git workflows can seem daunting. But version control is a fundamental part of how developers work. The vast majority of development teams take for granted that Git is tracking all the changes they make to code, before committing those changes to their feature branch and opening a pull request.
Source tracking in Salesforce brings that same value to everyone in Salesforce, including no-code developers. Once switched on, it keeps track of new, changed and deleted items in the Salesforce org, removing the need to track all of these manually. It can be enabled across your environments from your Dev Hub.
SFDX and the Salesforce command line interface (Salesforce CLI)
Before DX, developers wanting to use a command-line interface (CLI) for Salesforce deployments were able to use the Force.com migration tool, which was based on Ant. Its performance was limited and unreliable, as Salesforce itself documented.
As part of DX, Salesforce released the Salesforce CLI, which brought a significantly improved experience for pushing and pulling metadata between Salesforce orgs and version control. It also includes many other commands to manage other DX features, such as converting metadata to SFDX format.
Originally, the Salesforce CLI used sfdx commands. But with v2 of the Salesforce CLI, released in 2023, sfdx commands were deprecated. Salesforce now encourages developers to use the sf commands instead and has produced a guide to help manage the transition. The sf commands are simpler and more intuitive than the older equivalents. For example, sfdx force:apex:test:run is replaced with sf apex test run. And sfdx force:source:deploy --checkonly --testlevel NoTestRun becomes sf project deploy validate.
Scratch orgs and their use cases
Scratch orgs, so called because they can easily be created “from scratch”, are short-lived (“ephemeral”) orgs. Rather than needing to maintain a long-lived sandbox org for every development task, Salesforce developers can spin up scratch orgs quickly for building and testing in a clean org. You can choose how long each scratch org should exist — up to a maximum of 30 days.
To use scratch orgs, you need to designate a permanent org as a Developer Hub (Dev Hub); usually this will be the production org. You can use definition files to determine the shape of a scratch org and which features it has enabled. Or you can use the Org Shape feature to base the scratch org on the source org.
Teams with fast-paced development cycles tend to find creating scratch orgs takes more time than they can afford. One workaround is to “pool” scratch orgs: maintaining a supply of several scratch orgs that are available to use, so that developers can grab one as needed and streamline the process. Salesforce’s proposed solution is Scratch Org Snapshots, which allows you to create new scratch orgs based on snapshots of others — avoiding the need to start again with each scratch org.
Gearset can help you create and manage scratch orgs easily. When choosing environments in Gearset to deploy between, you have the option to create a scratch org as the target, based on your definition files or Org Shape.
Gearset can also create scratch orgs automatically for you as part of a CI/CD process. You can configure a continuous integration (CI) job to create a scratch org and deploy metadata to it — or validate against it. This saves you the manual effort and waiting time for scratch org creation.
Second-generation packaging (2GP) for modular development
The Salesforce metadata that represents features and customizations easily becomes one extremely complex model, with countless dependencies between metadata items. An unstructured org is harder to understand and develop without running into issues.
Packaging up metadata is a way to achieve a more modular design for logical units of functionality in Salesforce, with separation of concerns between different features. Package-based development is an especially popular approach with ISVs and consultants, who can “build once, deploy anywhere” when it comes to fairly self-contained apps.
Before DX, developers were able to package metadata using a packaging org; this is now known as first-generation packaging (1GP). The most significant limitation of 1GP is that each package and version requires a unique org, resulting in teams maintaining numerous orgs. DX introduced second-generation packaging (2GP), in which version control is the source of truth — not a packaging org. This transition was a key part of the switch to source-driven development. 1GP is still available and there’s no public retirement date, but Salesforce actively pushes development teams toward 2GP.
Within 2GP, there’s a distinction between managed packages and unlocked packages. 2GP managed packages are recommended for AppExchange partners, as the apps continue to be managed by the provider. Unlocked packages are recommended for in-house development teams and systems integrators, as the applications are managed by the customer.
Neither 1GP nor 2GP packaging covers all of the metadata types covered by the Metadata API. For example, 2GP currently doesn’t cover any Einstein metadata types, though it does now cover most GenAI metadata types used for Agentforce. Salesforce provides a full breakdown of metadata types and coverage.
Gearset fully supports deploying unlocked and managed packages. You can filter by namespace to find the relevant packages you want to deploy. Gearset will compare your metadata between the source and target environments, and show you all differences. You can deploy new packages which will be installed in the target org, or deploy updates to the latest version.
Salesforce DX and DevOps on the Salesforce platform
It’s easy to get confused by Salesforce DX; as we’ve seen, it’s a diverse set of tools and features. But at its core, Salesforce DX was designed to facilitate the workflows used by developers. Many DX features are designed to make Salesforce play nicely with version control. Ultimately, that’s about making it easier to apply DevOps practices to Salesforce, achieving more frequent releases and improving resilience with the VCS as the source of truth instead of the production org.
Teams trying to build their own CI/CD pipeline for Salesforce will generally rely on scripting with Salesforce DX commands, alongside either generic pipeline tooling such as Azure DevOps, Bitbucket Pipelines, GitHub Actions or GitLab CI/CD — or automation tools such as Jenkins, CircleCI, TeamCity, Bamboo and Travis CI.
Most teams that try the DIY DevOps route end up finding that it’s a full-time job to maintain these toolchains, because they’re always more brittle than expected, and Salesforce upgrades need to be planned for multiple times a year. If your team is working through this dilemma, you may find our “build vs buy” guide useful for why we think investing in Gearset is the right call. Since Gearset has integrated DX functionality, it’s not a case of deciding between DX and a DevOps platform.
Salesforce DX tools for everyone (not just developers)
Salesforce DX has been part of the transformation in the Salesforce world from org-to-org deployments to true DevOps practices with version control and CI/CD. And it’s great that DX has ultimately benefited everyone building on the Salesforce platform, not just developers.
Some DX features, like the newer metadata format, are now just baked into development on Salesforce. And DevOps platforms like Gearset put DX tools into the hands of no-code developers as well, with an intuitive clicks-based UI. Admins can use source tracking, spin up scratch orgs, commit to version control easily and trigger builds, all without needing to touch the Salesforce CLI.
Gearset’s DevOps platform brings DX to your whole team. It also provides all the solutions you need to build a modern DevOps process for Salesforce, including smart deployment workflows, automated testing, CI/CD pipelines, backups, observability and more. Try the full platform today on a free 30-day trial or get in touch to arrange a personalized demo for your team.
For the behind-the-scenes story of how Salesforce DX was created, it’s also well worth watching this DevOps Diaries podcast episode with Wade Wegner.
