Salesforce DX is the newest buzzword (buzzphrase?) in the Salesforce ecosystem. By launching Salesforce DX, Salesforce now offers tools for individuals and teams to more easily integrate continuous development into their coding regimen. Salesforce is advocating version control as the “source of truth” for Salesforce code and metadata, not a sandbox or development org – or, dare I even say it, the company production org.

Many ISV developers might be scratching their heads and thinking, “But wait a minute, my company already practices continuous development. We have defined processes for syncing code changes and data to development and QA orgs, and we’ve been using source control for years! What benefit does Salesforce DX have for us? Why bother switching over our existing projects?”

While there are many resources on Salesforce DX out there, including a trail on Trailhead, it can still be daunting for an ISV developer to get started. We’re all busy with our own projects, so why fix something that’s not broken? Here are what I consider the top reasons why ISV developers should switch to Salesforce DX:

1. Easily spin-up scratch orgs for development and testing. Given the overhead to create a development org, many ISV developers are likely developing in a single org for each project per developer. Those orgs could be many years old and contain a lot of stale configuration and data.
2. Develop using the package’s namespace! Scratch orgs can be automatically created with a package’s namespace. Most namespace-related bugs aren’t discovered until after a beta or test package release since historically, developer orgs don’t have a namespace. With Salesforce DX and namespaced scratch orgs, developers and QA engineers can develop and test with confidence.
3. Automatically enable certain Salesforce features without filing a support case! A developer no longer needs to file a case to get features such as person accounts or multi-currency enabled – this is controlled by the scratch org definition file when the developer creates a new org.
4. Use Salesforce-supported tools. Salesforce is actively developing plugin extensions for Visual Studio Code, including Salesforce DX support. (Note: other IDEs have also introduced their own support for Salesforce DX – for example, I personally use the Illuminated Cloud plugin for the IntelliJ IDE.)
5. Organize all the metadata. Frustrated with having 200 classes all in the same folder? By using the new SFDX file structure, developers can group metadata into separate sub-folders that actually make sense.
6. Stop remembering passwords! Even if one decides to not use the Salesforce DX infrastructure, developers can still use the Salesforce Command Line Interface. The Salesforce CLI will allow anyone to login to previously authenticated orgs on their local machine without entering a password each time. Awesome!

Okay… how do I get started?!

First, make sure that you or someone with the correct administrator permissions has enabled the “Dev Hub” in the business org (this is likely your company’s production org), and that you have read over and familiarized yourself with the resources linked in the above few paragraphs. Additionally, register the package’s namespace in the Dev Hub org.

After the above steps are completed and you’re comfortable with the SFDX Trailhead and the CLI, it’s time to start converting the existing package.xml project to the new Salesforce DX format from the Metadata API format. This is the probably the most challenging and daunting piece of the puzzle. The Salesforce CLI makes this easy as there are commands to convert to the new format and vice-versa (force:mdapi:convert & force:source:convert).

Project conversion tip: Convert the package.xml project to the new format and, once successful, convert back to the package.xml project in a different directory. Use a diffing tool to compare the old package.xml project to the package.xml project that was just generated – in my experience, there should be very minor differences and if there are, they will likely be due to different API versioning. Diffing the generated package.xml project to the one that you’ve grown accustomed to working with over the past several years should give you the reassurance that Salesforce DX is correctly converting the project.

This is great, but I’m a visual learner – is there any video content on Salesforce DX?

Yes, there is! Consider watching the following Salesforce Play-by-Play on Pluralsight; the “Migrating Existing Metadata into Salesforce DX” module may be particularly helpful.

Play by Play: Strategies for Successful Salesforce DX Migration and Adoption

This video tutorial will guide you through broad strategies and step-by-step instructions for migrating metadata to an existing Salesforce DX project.

www.pluralsight.com

Salesforce DX is growing at a rapid pace. I’ve intentionally tried to keep this blog post succinct and link out to the official Salesforce websites where possible in order to direct readers to the most up-to-date content. If you have questions that weren’t answered by this post or the various links above, please feel free to reach out to me at any time on Twitter – @WatsonRobertB – or by leaving a comment below.

Happy SFDX’ing!
— Robert

List of Mentioned Salesforce DX Resources:

Salesforce DX
Get Started with Salesforce DX
Salesforce Command Line Interface
Salesforce CLI Command Reference
VS Code Salesforce Plugins