DevOps / Developers

What is Salesforce DX and what does it mean for Admins?

By Alex Brausewetter

What is Salesforce DX?

Salesforce has been at the forefront of so many technological changes. Their innovation stance on the viability of Enterprise Cloud seems obvious now but it wasn’t when they first started. The company once again flexed its innovation muscles at Dreamforce ‘16 with the announcement of a developer experience they are calling Salesforce DX. Announced alongside other technology investments like the Einstein AI platform, DX is perhaps the most important change in the daily activity of Salesforce professionals and an exciting new way of thinking about Salesforce development.

DX promises a shift to modern life-cycle management tools for coding on the Force.com platform. According to the product page and announcements in previous keynotes, Salesforce DX is designed to help Salesforce developers “build together and deliver continuously.”

Over the past decade a lot has changed in the way teams deliver software. “Agile” has firmly supplanted “waterfall” as the de facto process in most companies. Salesforce DX recognizes and embraces this shift, by opening the platform up to integration with third party tools like  Git and Jenkins, similar to other modern development stacks.

Salesforce DX includes a “powerful command line interface and open APIs” which could allow developers to write their own scripts and automations, even if they aren’t deeply familiar with deployment and packaging.The new tooling will support more metadata types and offer a higher level interface, making deployment flows that currently need interaction with specific APIs more accessible to the community.
Salesforce DX adds a new class of orgs called Scratch Orgs, a lightweight environment for testing and development that can be launched on demand from the editor and command line. Different from traditional Sandboxes which mirror the metadata of their parent org, Scratch Orgs do not inherit any content and instead start up blank. An initial upload deploys metadata and data fixtures from files stored in source control before the org is ready to use. This descriptive mechanism guarantees that the new environment will be built from managed source code. Configurations that are not tracked in source control will not be present in a Scratch Org. With DX it will be possible to spin up clean environments in little to no time at all, so you can use a fresh Scratch Org for feature development, review or Continuous Integration with tools like Blue Canvas and Heroku Pipelines.

Version Control and “Source Driven Development”

Perhaps the biggest shift in the Salesforce DX workflow is the movement towards “source driven development”. Using a source control tool is common in just about every software development ecosystem. Traditionally, Salesforce has been the exception here. With DX, this will change and the source of truth will be source code rather than a Salesforce Org.
Source control (or version control) is a mechanism for keeping track of your code. It’s important for several reasons: it allows you to collaborate with colleagues without overwriting each other’s work, it serves as a backup in case you need to rollback to previous versions of your software, and it allows you to release your code safely. (It does a lot of other things too, but those are the basics.) Most developers today are moving towards Git to handle their version control for Salesforce.

What Does This Mean for Admins?

One of the best things about Salesforce is the “clicks not code” philosophy. It allows many different people to contribute to a Salesforce app with being a “coder”. Admins, product managers, business analysts, and many others can embed their knowledge into an app without being trained in computer science.

In the Force.com paradigm, declarative changes and code stand as equals. Most teams use declarative features like Workflow Rules alongside Apex Classes. Salesforce MVP Peter Knolle explains how DX may affect admins:

“If you accept the premise that all metadata changes are code changes and should follow all of the same processes as traditional code changes (i.e., Apex and VF) that Salesforce DX enables then there must be a way for admins to be involved. It all falls apart if admins make changes in production or make changes in a sandbox and deploy via change set and do not use version control.”

To get the most out of Salesforce DX, teams will need to begin to include declarative changes as well as code changes in a version control system. This means that changes made by admins will need to be included in version control for teams to experience the benefits of DX.
Setting up source control for Salesforce is a great way to prepare to leverage the awesome features that Salesforce DX will bring and the good news is you can start now.

The Author

Alex Brausewetter

Alex Brausewetter is a founder of Blue Canvas where he does coding, product design, and architecture.

Comments:

    RC
    February 21, 2017 2:25 pm
    Thanks for posting this. This is something that is sorely needed. I've been on projects using Git/Jenkins/etc, and also projects where it was a wild-west sort of affair, in terms of code deployment/respository. I'm excited to see how things go from here.
    bhanu
    November 27, 2017 1:57 pm
    Hi , It's awesome post which helps to learn about Salesforce CLI https://www.forcelearn.com/salesforcedx-installation-and-tutorial/ I have post those who faced issue while configuring salesforce CLI in their local org

Leave a Reply