This is the first installment in a five-part series, looking at the changes and opportunities Salesforce DX offers app developers today. Over the course of this series, we’ll talk about:

The content in this series is a collaboration between the Salesforce DX and Salesforce Evangelism teams.

What is Salesforce DX?

Succeeding with Salesforce DX begins with understanding what it is and what it is not. The term Salesforce DX encompasses both a set of tools and new features that affect the app development lifecycle. Ultimately, Salesforce DX is an opportunity to shift how you manage the source of truth and app development lifecycle for your org.

Codey celebrating with a CLI in background

But Salesforce DX isn’t a magic bullet that will fix every challenge your team has with organizing change and managing releases. In their current form, the tools related to Salesforce DX will be most accessible and useful for members of your team that can work with command line interfaces (CLIs) or integrated development environments (IDEs). Additionally, adopting Salesforce DX isn’t an all-or-nothing process. Because Salesforce DX is both a new set of tools and new features, your team might find some of the tools and features useful right now, and want to wait to investigate others.

Why adopt Salesforce DX?

In a traditional Salesforce development lifecycle, app builders use sandboxes to create and test changes. The source of truth is a moving target. Often, for teams in the middle of a project, the ‘source of truth’ might really be whichever environment contains the latest, stable build of their project about to be pushed into the next higher environment. For another team of developers, their source of truth may or may not be in the same sandbox(es). We could also think about this way of building and releasing changes as ‘org based’ development, because the source of truth is a Salesforce org.

With Salesforce DX, you can change the way your team defines their source of truth. Instead of piecing together the state of various environments to get the latest versions of code or metadata, your team can get the latest versions from a centralized source control system, like Git or Subversion. This style of managing development artifacts (i.e. code and other customizations) is called source driven development. Shifting to source driven development won’t eliminate conflicts in code or metadata, or change the need to communicate clearly across teams. But it does put the burden of organizing, managing and resolving changes into source control systems, which are built to do this efficiently. Source driven development can also give you and your team greater visibility (and audit history) into the changes made to your org—whether in code or configuration—and better ways to undo changes that have negative impacts.

In addition to supporting source driven development, Salesforce DX has features to help you shift to a new way of managing releases and the changes you make to your org. This new method of organizing your metadata and deploying changes, in Beta for Spring ’18, is called unlocked packages. Unlocked packages are intended to provide a repeatable, scriptable and trackable vehicle for introducing and managing change in your orgs. We’ll talk about this a bit more in our next post. Meanwhile, you can also watch a great overview with Dileep Burki, from the Salesforce DX team, as a part of the Spring ’18 Release Readiness Webinar.

Another benefit of Salesforce DX lies within the tools. Within the Developer Evangelism team, using the tools of Salesforce DX has allowed us to work together on building applications and iterating on our ideas faster than ever before.

List view of Developer Evangelist scratch orgs with chart
For me, adopting source driven development has helped relieve some of the difficulty around managing applications, multiple environments and versioning. Prior to Salesforce DX, if I wanted to share a particular application with others, one of the fastest ways to do this was to create an unmanaged package. But this also meant I needed to keep track of the login to that org if I wanted to ever work with that package again, and also remember what package went with that org. Second, if I iterated on my application in another org, pulling those changes back into my original packaging org was tough. Often, I had to rely on manual replication. And because a Salesforce org was my source of truth, sorting out where I made which changes and what the ‘final’ version of a feature should be was difficult.

But since I’ve started incorporating Salesforce DX into my routines, even when I need to create an unmanaged package to share something, I also convert that same package into a Salesforce DX project and store it in source control. If I want to make changes, I can quickly spin up a temporary environment (called a scratch org, more on that in our next post), make my updates, sync my changes back to source control, spin up another scratch org, push my updated source to the new org and test out my changes. If I’ve made an error in my updates, correcting and testing multiple versions of an app takes minutes, not hours or days.
Screenshot of Github repo for a Salesforce DX project
In order to take advantage of the tools of Salesforce DX and the shift to source driven development or package development, you’ll need to first decide how Salesforce DX, in its current form, could help your team, and then get your team ready to adopt.

Decide if Salesforce DX is right for your team (right now)

The path to adoption for Salesforce DX will look different for different teams. The skillsets within your team, the tools your team is already using, and existing company policies will all impact the choices you make. One team could decide to use the tools related to Salesforce DX to better connect developers to existing release management systems, and wait to investigate the features around package development. Another team might decide to add the functionality of scratch orgs into their development processes, and work on a long-term plan for adopting source driven development before exploring more parts of Salesforce DX.

As mentioned before, the tools related to Salesforce DX aren’t accessible through a point-and-click interface. The places you can use these tools are within a CLI or within an IDE like Visual Studio Code. If your team isn’t comfortable working in these ways, you may need to do some skill building in these areas in order to feel comfortable exploring Salesforce DX. The Lightning Component Skills & Tools module on Trailhead has more resources if you’re curious about IDEs. And Peter Chittum’s ‘Don’t Fear the Command Line‘ session from Dreamforce ’17 is a great way to start diving into CLI skills.

If you’re thinking about how Salesforce DX can help you with source driven development, it’s important to understand it’s more than just learning how to check your changes into a tool like Git or Subversion. It’s also how you organize and manage the various stages of app development for your Salesforce org, and the teams involved in app development. If your team is already using a source control tool, the features offered by Salesforce DX to better connect your development teams with your source control systems are definitely worth exploring now.

Astro and Codey working with package distribution
But if you aren’t using source control, then think about how your team handles the stages of app development. Who does this work for your org? What tools do they use? Would they be comfortable working in a CLI/IDE? How do you sort out conflicts between teams? Would the people who do the work of resolving conflicts feel comfortable working in a system like Git? Would it be possible to give them the support they might need to learn a new system?

What’s next and what to do now

The next post in this series will take a closer look at possible paths to adoption. We’ll also touch on some key tools and functions, how to actually configure your org to start using Salesforce DX, and where Salesforce DX can fit into the application development lifecycle.

In the meantime, now is a great time to head over to Trailhead and complete the modules and projects related to source control and Salesforce DX. They will help guide you through installing the tools related to Salesforce DX, and how start thinking about it in relation to your applications:

You should also be sure to register for the upcoming Ask Me Anything (AMA) with the Salesforce DX Product Management team, coming up on February 27! And if you’re looking to get more hands on with Salesforce DX at TrailheaDX, check out the Emerging Tech for Developers Bootcamp.

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS