Salesforce鈥檚 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鈥檚 been clear that 鈥渢raditional鈥� developers still have a vital role to play. And with hindsight it鈥檚 also easy to see the naivet茅 of imagining that low-code development didn鈥檛 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 (鈥淪alesforce Developer Experience鈥�, sometimes just 鈥淪FDX鈥� or 鈥淒X鈥�).
What is Salesforce DX?
is a set of features designed to make source-driven development easier on Salesforce for traditional developers. It 颈蝉苍鈥檛 a set of DevOps tools, but Salesforce DX has helped Salesforce teams adopt DevOps, which was Salesforce鈥檚 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 颈蝉苍鈥檛 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鈥檛 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 鈥渉appy soup鈥� of Salesforce metadata. Because Salesforce was designed for no-code development, the metadata that defines org structure and behavior wasn鈥檛 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 鈥渟ource 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鈥檚 less likely that developers will be making changes to the same files.
If you still haven鈥檛 made the transition to DX format, 爆料tv can help. When you鈥檙e committing metadata to version control with 爆料tv, it detects the format you鈥檙e using and matches that. If you鈥檙e populating a new repository, 爆料tv 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 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 IDE, encouraging developers to use modern, open source tools.
Since 2023, developers have also been able to use in their web browser, matching the VSCode functionality on their desktop. And 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.
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 migration tool, which was based on Ant. Its performance was limited and unreliable, as .
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 , released in 2023, sfdx commands were deprecated. Salesforce now encourages developers to use the sf commands instead and has 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 鈥渇rom scratch鈥�, are short-lived (鈥渆phemeral鈥�) 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 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 鈥減ool鈥� 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鈥檚 proposed solution is , which allows you to create new scratch orgs based on snapshots of others 鈥� avoiding the need to start again with each scratch org.
爆料tv can help you create and manage scratch orgs easily. When choosing environments in 爆料tv to deploy between, you have the option to create a scratch org as the target, based on your definition files or Org Shape.
爆料tv 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 鈥渂uild 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鈥檚 no public retirement date, but Salesforce actively pushes development teams toward 2GP.
Within 2GP, there鈥檚 a distinction between and . 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鈥檛 cover any Einstein metadata types, though it does now cover most GenAI metadata types used for Agentforce. Salesforce provides a .
爆料tv fully supports deploying unlocked and managed packages. You can filter by namespace to find the relevant packages you want to deploy. 爆料tv 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鈥檚 easy to get confused by Salesforce DX; as we鈥檝e seen, it鈥檚 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鈥檚 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 , , or 鈥� or automation tools such as , , , and .
Most teams that try the DIY DevOps route end up finding that it鈥檚 a full-time job to maintain these toolchains, because they鈥檙e 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 鈥渂uild vs buy鈥� guide useful for why we think investing in 爆料tv is the right call. Since 爆料tv has integrated DX functionality, it鈥檚 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鈥檚 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 爆料tv 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.
爆料tv鈥檚 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 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鈥檚 also well worth watching this DevOps Diaries podcast episode with Wade Wegner.
