Salesforce DX provides development teams with an integrated, end-to-end lifecycle for high-performance agile development – designed to be open and flexible so you can build together with tools you love. The project was announced at Dreamforce 2016 and since then there has been a lot of interest across the entire Salesforce developer community. A few weeks ago, the Salesforce Developer Relations team got our first access to the internal developer preview – and I have to say it’s blowing my mind.

A Shift in (Salesforce) Developer Mentality

Typically in Salesforce, everything you build revolves around your org. Whether you’re working in a production org with dependent sandboxes or in a developer edition, the canonical source of truth is hosted in your Salesforce environment.

This is different from workflows you may be familiar with if you develop on other platforms, where your source of truth is often a version control system, and modern software development tools have made automated testing and delivery a commodity.

Given these expectations as a developer, I feel like I’m waking up in a place that is both familiar and strange all at once. So what’s Salesforce DX and how does it change the work of a Salesforce developer?

The Tools

With Salesforce DX, you’ll continue working with a number of familiar tools, but you get access to a whole lot more. For me, the most significant new features that underlay the developer workflow are new APIs, the environment hub, scratch orgs, and a powerful new command line interface. Let’s go over these quickly:

Environment Hub

The Environment Hub is a new feature that you will see in an org when Salesforce DX has been enabled. It is similar to the list of Sandboxes in Setup that you are likely familiar with already. The difference is Environment Hub allows you to track all of the orgs you use. When Environment Hub is enabled in an org, it establishes that org as a central management point for other orgs. Users in that org can be granted permissions to create, delete, and manage orgs. Licenses for development, and testing orgs are linked to Environment Hub.

Speaking of orgs, that brings us to another new feature.

Scratch Orgs

I have at least 100 Developer Editions – possibly more. I don’t even know what they were all for, but I needed them once…a long time ago. So I keep them around. Scratch Orgs represent a significant change in how we think of our developer and test environments. They are quick to provision, accessible primarily by a single user (developer, test engineer or admin), and both temporary and easy to destroy. Scratch orgs are created using a straightforward JSON descriptor file that can be kept and maintained in source control.

New APIs and new Salesforce CLI

While all the APIs you know and love continue to be available, we’ve created new APIs to help you work with the Environment Hub and Scratch Orgs and to make it easy to integrate these new features into your workflows.

Wrapping these new and existing APIs is a new command-line interface that represents a significant enhancement to the Salesforce developer lifecycle. Whether you want to work directly in a terminal, create scripted deployments, or use it as the foundation for building all-new tools, the CLI gives a single interface to access many different APIs in a simple declarative way.

And More…

There are new development pipeline and continuous delivery tools that we’re building as part of Salesforce DX leveraging existing Heroku tooling. We have a next generation of the Force.com IDE. We’re also working on making the process of syncing local source to org source more straightforward. We’ll wait to go into details about those in a future post. But if you want a sneak peak, I put some video links at the end of this post.

Get Into the Salesforce DX Flow

The new workflow I’ve begun to work with in Salesforce DX goes as follows:

Clone a source repository

Here, I clone a repo where from a source project and checkout a new branch.

Sign Into Environment Hub

Now that I’ve got source code to work with, I need an org. Environment Hub is what gives me permissions to manage orgs, so I’m going to connect my local workspace to Environment Hub.

This command launches an OAuth flow where I sign into an the Environment Hub org. Again, I won’t be doing work here, but it provides me with powerful capabilities to manage all of my orgs in one place!

Provision a Workspace Org

This next step is similar to checking out the latest source from a version control system in traditional team development. Before I can start working on my code, I need to build my developer environment. Of course in our world, the org is the runtime, but let’s dive right in!

First I generate a scratch org. To tell Salesforce DX what I want that org to look like (for example, edition, configuration parameters, and other items) recall we use a JSON file to specify those configurations.

I now have a repo full of metadata, code, and test/seed data – but my org is still empty. Let’s finish setting up the org so it’s ready to work with. The next steps we will perform are as follows:

1. Push my local source code to the scratch org
2. Assign my user in the scratch org with permissions to see the existing app
3. Import my test/seed data

Did you notice the step above where I added the permission set? As I mentioned, we need to assign the permission set to my user in the scratch org so I can see the newly loaded application. Then, I’ll load my test data and open up the org in my browser. We’ll perform all three of these steps via the command line:

And finally, using the command line, I can actually launch the org without having to manually supply a username and password.

Build My Feature

At this point, I would set about working on my code changes. For instance, I might use an IDE to make a change to some Apex code or to a Lightning Component. In my case, I modified a Lightning Component.

It’s worth pointing out one important detail here. I didn’t have to tell Salesforce DX what has changed…it already knew. Likewise, if I change something in the org such as a new object or field, I simply have to do heroku force:src:pull, and that new metadata will be added to the local workspace. This is thanks to new architectural features that allows an org to track changes. To learn more about these changes, check out the on-demand Deep Dive into the New Salesforce Development Experience (DX) Architecture session from Dreamforce.

Wrapping Things Up

Now that I’ve provisioned and configured my org, loaded all of the data and pushed my changes, it’s time to test my feature to make sure it works. If it does, I take care of any VCS housekeeping like commits, pushes, or pull requests and I’m done.

Success! So now that I'm done, what good is it keeping this org around? Why not delete it?

Meet Your Org, The Runtime Environment

This is Salesforce. What you build runs on our servers. But with scratch orgs the environment feel much more like a temporary runtime environment. Working on a feature with Salesforce DX feels a lot more like working in other development frameworks. It is a firm step away from a single environment that is the nexus around which all work must revolve.  

And it is this reduction in the importance of the org that is blowing my mind.

After my initial experimentation with the Salesforce DX developer preview, I am more excited than ever to explore new ways to use the new developer workflow. I also think it will bring about a fundamental shift in thinking on the part of our many developers and admins who have come to expect the production org as the source of truth. 

Hopefully this little taste has you excited. But you might also feel a bit daunted if you aren’t used to working with the command line, or are not a coder. I wouldn’t worry too much. For now the focus of Salesforce DX is on building a foundation for good project lifecycle management. But eventually, this will serve as a base for even better point-and-click tools that give our admins and declarative developers a frictionless and intuitive process as well.

So much more to see in Salesforce DX…

I feel I’m just scratching the surface as I get to know the new Salesforce developer experience. The Developer Relations team will do our best to share more sneak peeks as we get more time with Salesforce DX.

Can’t wait to try it yourself? I bet…I couldn’t either. For now, if you want to find out more, I would suggest one of the excellent Salesforce DX videos that came out of Dreamforce 16. To help people find them, I made a YouTube playlist.

Or you could take a look at these three videos from that playlist individually:

• Building Force.com Apps from Source with John Vogt
• Deep Dive into the New Salesforce DX Architecture with Jim Wunderlich and Mike Miller
• Peek Under the Hood of the New Apex Compiler with Josh Kaplan

Stay tuned for more soon!