Salesforce DX Quick Take

Salesforce DX was announced at Dreamforce 2016 as a new way to manage and develop Salesforce apps.  It is a new and much improved Salesforce Developer Experience.  The rest of this article consists of my thoughts on platform development in the past, the future with Salesforce DX, and some of my hopes for Salesforce DX based on my experiences and what I saw at Dreamforce.

The Past

To be frank, trying to apply best practices and processes of traditional software development on the Salesforce platform has always taken a substantial amount of effort to set up.  Even after that initial investment of setting up a process and figuring out how to shoehorn in things like distributed development, version control, branching, merging, and CI, it has always been much more complicated to develop with than other tech stacks. Developers are used to working on tech stacks such as Java/Spring, .NET, node.js, that have had all of that figured out for a long time.

The Future

Salesforce DX is the solution to those problems. It will standardize a set of tools, APIs, and best practices for development on the Salesforce platform. The goal, as I see it, is to make it inexcusable to not use best practices we software developers have been using on other tech stacks for years. This will have a positive side effect of attracting and keeping other talented developers on the platform.

A New Command Line Interface

The new command line interface adds additional commands via the Heroku CLI (a.k.a. Heroku Toolbelt). This is core to the development experience. It is used by the IDE. It can be added into any other automated processes such as continuous integration, automated build scripts, or deployments. I believe a solid command line is core to everything. Give the developers a rich and complete set of basic commands and they’ll use them and come up with new, better, unexpected ways as well.

Of the existing functionality (i.e., have been able to do for a while by a different means), I am particularly interested in the data loading. One of the best practices is to check in DML which can be used to share solid test data. I see this overlooked with Salesforce all of the time, perhaps because it can be a bit more difficult to automate with the data loader.

My Hopes

  • It will be easier to incorporate test data into development processes
  • Other devs will add in commands that they’ve been using in their own orgs
  • Other devs will improve the existing commands
  • The CLI will be extendable, but grow only as needed

Scratch Orgs

This was the most intriguing concept I wanted to learn about. Some shops/teams/projects do not follow basic best practices of software development. How often does everyone develop in the same sandbox with no sort of version control? If it were a Java/Spring project it would be equivalent to all developers writing their Java code directly on the shared test server and performing their DDL directly on the shared test DB. Even when developers each have their own org, their org can quickly become inconsistent with version control when they switch active branches.

Enter Scratch Orgs. They will allow you to quickly spin up new orgs via a command and JSON configuration (This is also good for easily spinning up an org for a feature test such as multi-currency). With scratch orgs, I see a natural fit to a feature branch workflow. Branch for your feature. Spin up a Scratch Org. Deploy to it. Develop in it. Finish. Delete the Branch. Delete the Scratch Org. The CLI has commands for managing the scratch org, so it can be automated.

My Hopes

  • It will be easy to create Scratch Orgs that are identical or similar enough to production (export config?)
  • Scratch Orgs will be able to be created very quickly and built to (compiled) very quickly.
  • Developers will be able to use the interactive debugger in Scratch Orgs for free.
  • JavaScript development will be quick and easy.
  • There will not be a need for any more manual changes such as Flow deployments. The Scratch Org will be spun up and ready to go with zero need for manual changes, once data is automatically loaded.

Developer Tools

The IDE has been updated to include many new enhancements. The CLI will be central and able to be run from the IDE. The App Builder will be able to be used directly from the IDE (looks like it opens in a web tab of sorts). The metadata will be sync’d up with the org automatically. It looks like there is some code completion as well. Since it runs in Eclipse as a plug-in, direct integration with a version control system can be done.

My Hopes

  • Code completion works on all things
  • Real-time syntax checking
  • Transparent or very simple syncing between the local file system and the org
  • That there is good code navigation, e.g., click to go to declaration, find references to, etc.
  • Refactoring Support will at least support the Java refactoring functions in Eclipse
  • All of the functions will be available via the API
  • All of the functionality in Eclipse could be implemented by other IDEs (should be able to as IDE is open source)
  • Static code analysis will be supported (BTW, a new Apex compiler is coming!)

Reimagined Packaging

The idea of this is that somehow developers will be able to organize their code and orgs better through new packaging features.

One of the biggest pain points in Salesforce development is its lack of code organization through namespaces or Java-like packages. There is one large src/classes directory that has all of the classes in an org. Another pain point is that there are no well-maintained popular open source libraries, which is largely true (I know about fflib, which is great, but there’s more than that needed). Each org needs to create its own Math/String/Lang/Etc utils classes, its own zip, own csv parser (my co-worker pointed that one out), its own dynamic soql utilities class, etc. In other languages this stuff exists and every org doesn’t reinvent the wheel, they just use their package manager (mvn, npm, etc.) to get what they need.

The fact that this packaging problem will be addressed is huge and I am hopeful it will solve all the packaging related issues.

My Hopes

  • It will facilitate more open source libraries.
  • It will lead to a better way to organize code.
  • Dependencies will be handled well
  • Rollback or version switching will be implemented
  • Salesforce will release some of their own common code such as utils classes as part of packages and lead the support of them
  • All of it will be available via an API

Source Control and Team Development

Changes are being made to make it easier to use version control and efficiently develop with teams of developers.

Traditionally Difficult Files

It has been very difficult to support concurrent development, especially more than one project at a time, when profiles are being modified. Different orgs have different configurations, were created at different times, or have other aspects that cause profiles to end up not working (e.g., a privilege exists in one org but not another — compile failure). Additionally, profiles only populate with a subset of all of the metadata that they could have, because they are dependent on whatever other components are requested with them.

Destructive Changes

Scratch orgs start from scratch, so don’t need to worry about destructive changes, but production doesn’t start from scratch and larger development efforts may have a more than a few destructive changes. If we are building from source at a point in time, my hope is that destructive changes can be added in some way that works well.


I’ve left this for last, but it might be the most important, because everyone must follow the process for it to work. How will admins fit in to source control and continuous integration processes? It is part of a developer’s skill set to use version control tools like Git or SVN and set up CI tools like Bamboo or Jenkins. 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.  Because it is so easy to make declarative changes, however this is implemented it must be done in a way that makes it simple for admins.

My Hopes

  • It will be simple for admins to make changes that conform to the Salesforce DX processes
  • Managing profiles will be transparent or very simple
  • All changes will be available via the API, so that no manual changes will need to be done during a deployment
  • Destructive changes will be handled elegantly.


The product marketing site and the developer site have roughly the same information. There is a form that you can fill out to be “the first to learn more about Salesforce DX”.

Developers have been waiting for something like the Salesforce DX for a while and so far it looks like it is going to be great. Salesforce DX will enable all developers to easily change how they work on Salesforce platform for the better.

12 thoughts on “Salesforce DX Quick Take

  1. Hi Peter,

    thanks for this great article.

    I agree with you. We have been waiting fot this Salesforce DX for a while :-).

    Have you seen or heard of beta / release dates?


      1. I went to a good session on packaging and a lot of those updates aren’t going to be around until 2017 and even 2018.

        As for the CLI and scratch orgs etc., I did hear that Summer 2017 they may be around as a beta feature.

  2. Great post!

    Just to add, I also hope salesforce DX also helps us manage many Metadata as data problem we have with config for many appexchange or custom built applications


  3. If my source is not aware of an Admins new validation quickfix, my code is doomed to fail at deployment. I ağree Admins have been left too conveniently out of the picture mostly. My hope is that Admin & Dev will blend into designer. All designers ideally adhere to the same testing and lifecycle best practices. But that will take some time. Until then my biggest worry next to deployments are declarative pieces of functionality without easy way to test them as thoroughly as apex.

    1. Hey Christian. I agree. I think that will be the most interesting part. If you take the stance that all changes to metadata are development changes then the declarative changes should go through the same process, including the version control part. My experience has been that it is possible to implement something where admins make no changes in production, but make their changes through sandboxes and deploy to production right now, with a lot of discipline. I think that having them learn git branching and merging of metadata XML is unreasonable (honestly, it is a pain for developers and error prone — profiles, for example).

      It’s great that tools are being built and stuff is being done and its going to be a great improvement to quality and efficiency in general, I think. Something that is easy for admins or something else that addresses the general issue with them will have to come out at some point.

  4. Hey Peter,

    What are the top automated software testing tools for Salesforce/APEX? Any thoughts on Tricentis?


Leave a Reply

Your email address will not be published. Required fields are marked *