October 5, 2016

Salesforce DX

I don't usually write posts from Dreamforce and generally wait until I get home, but this year something has caught my eye on day one, and that thing is Salesforce DX (Developer eXperience). So while I wait for @MoysieK to return to our Airbnb apartment and let me through the door I thought I'd spread the word so that others didn't miss out.

The Gist

Basically the idea behind Salesforce DX is to bring the platform more inline with what developers know and expect, and the biggest key to that is summed up nicely by a line I've seen in more than one deck today:

"version control will be the source of truth"

This is a radical departure from the current model where the source of truth is an org, and presently orgs are such sources in many different parts of the process. For example an individual developer currently has a battle on her hands managing an org vs. a git repository: if you change you branch in git to one that doesn't have a particular class, you're still stuck with that class in your org. For developers of managed packages the packaging org is the source of truth, it's the one org your package is forever tied to and you really want to keep it clean.

On top of the core developer improvements are a host of packaging improvements to go along with them, and while those updates appear to be father down the road they do seem to address pretty much every problem I've ever encountered with managed packages.

Some of the Proposed Features

Nothing is set in stone yet, and it's clearly early days, but these are some of the features that are likely to be headed our way:

  • Version control will be the source of truth, and the environment will be source control agnostic—you don't have to use git
  • Developers will be able to spin up 'scratch orgs' to quickly test a branch/feature in a fresh environment, configured as required (i.e. edition, feature enablement without contacting support!)
  • Creation of scratch orgs, creation & installation of packages etc. will be all available via a command line tool
  • Said command line tool will use a public API, meaning IDE support (think Eclipse plugin 2.0)
  • Both the CLI and API interfaces mean that full CI with automated creation of testing environments etc. will be a reality
  • Developers will be able to create multiple packages that use the same namespace, avoiding the need for global interfaces that are then locked down due to being customer-visible
  • Managed packages will support 'modules' as a way of organising and splitting up code within a package; I'm yet to discover whether this functionality will be extended to environments outside of managed packages

Here's To the Future

This functionality isn't going to suddenly appear next week, some of it won't be released until well into 2017, and other parts until the year after that. It genuinely appears that Salesforce are both listening to, and acting on, the biggest pain points raised by the community, and I'm confident that these changes will make many a developer much, much happier.