We might get more questions about Salesforce DX than any other topic. Earlier this month, Salesforce put out an excellent blog series about DX which is worth reading in full. It answers a lot of questions and poses back some really good questions to Salesforce development teams.
At Blue Canvas, we manage hundreds of millions of lines of Salesforce code every day and are in constant contact with hundreds of Salesforce development teams. We wanted to provide our own perspective on perhaps the most important question raised in this blog series: Is Salesforce DX right for your team?
Salesforce DX is a Series of Tools Not a Product
Salesforce DX is one of the most exciting things to happen to Salesforce developers in a long time. It’s really well thought out and it brings a lot of great tooling to the ecosystem.
However, one of the confusing things about DX is that it’s not a product. As the post notes, Salesforce DX is a set of tools, not “a magic bullet that will fix every challenge your team has with organizing change and managing releases”.
Salesforce is known for producing amazing products that work out of the box. There are also thousands of well designed apps in the AppExchange that work out of the box. And Salesforce is known for its clicks not code philosophy. Confusingly, Salesforce DX is different. Instead of a product that “just works” like Salesforce itself, it’s a series of tools that you can use to build a custom development pipeline via the command line.
DX will no doubt continue to evolve over time and it will become more friendly in the future we presume. The goal of this post is to help you decide whether this is something you want to invest in today, or in six months or sometime next year.
Questions to See if You Are Ready
The first question to answer is this: are you interested in building a Salesforce development pipeline from scratch via a command line interface (CLI)? As the post notes:
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.
Salesforce DX gives you a new sense of freedom and responsibility with respect to setting up your Salesforce team. Here are some other good litmus tests for determining if your team is ready for Salesforce DX:
Try This Trailhead Tutorial
With this simple Salesforce DX Trailhead tutorial, you can pretty quickly discover if DX is something you are going to want to work with today. It gives you a flavor for how source driven development, scratch orgs and the Salesforce CLI all work together. (You can also check out this Blue Canvas blog post that shows how to use Salesforce DX with Visual Studio Code). How does it feel? Does it feel intuitive? Do you feel confident moving forward?
How many lines of code do you have? How old is your app?
Another key consideration is the state and age of your Salesforce implementation. Are you starting a greenfield project? If so, it’s probably a great time to invest in DX. This gets you on the future path that Salesforce is promoting right away. But if you have a legacy app, you’ll have to consider a more involved migration path. Think about how long that might take and if it’s the right time to approach that. Keep in mind that DX introduces a new directory structure and a call to move from a monolithic code base to something more modularized. Teams with lots of lines of code and legacy apps may prefer to wait a bit before migrating to DX.
How do you feel about the command line?
Salesforce DX is not available through a point and click interface. It’s all command line based. For some teams, working at the command line is their natural habitat, for others its’ slightly more intimidating. Think about your and your team’s comfort with the command line. Maybe you want to dive in now or maybe you’ll want to wait.
Do you have source control in place?
One of the key components of DX is source driven development. Are you using source control today? Are you a Git or SVN master? Or is your team still mostly making changes with change sets and keeping track of things in an ad hoc fashion. Before you can truly leverage DX you should be familiar with source control. (We recommend Git for Salesforce.)
Starting Simply with Salesforce DX
If you don’t feel like your team is ready for Salesforce DX, you can still dip your toes in the DX waters without diving in. Here are some simple things to get ready for DX and to capture many of the benefits of DX without going all in.
Get Source Control in Place
Source driven development makes Salesforce development much more pleasant, faster and less error prone with or without DX. To get started, you should put your Salesforce code and declarative work into a source control system. You can use generic tools like GitHub, Gitlab or Bitbucket or you can use a Salesforce specific source control tool like Blue Canvas. With Blue Canvas you can have basic source control up and running in 10 minutes with no need to train your team to use a new process. It will even capture declarative and point and click changes into your version control automatically.
Sign Up for a DevHub to Create Scratch Orgs
Scratch orgs are one of our favorite new features in DX. They provide the ability to quickly spin up scratch orgs. The Trailhead we mention above is a great starting place. You can also use Blue Canvas with scratch orgs. We allow you to spin up scratch orgs using our point and click interface rather than the command line. We can even normalize deployments between scratch orgs and your traditional sandboxes, allowing you to use DX without completely overhauling your Salesforce release process.
To join the Blue Canvas DX beta, please email email@example.com.