This article is based on excerpts from our whitepaper on Salesforce DX and is designed to be a high-level overview.
DX is helping modernize DevOps for Salesforce
The remit of DevOps in Salesforce is a little different to that in other platforms, comprising any part of the develop-release cycle that’s still manual, but can be automated. There are four main target areas for automation:
Releases, via continuous integration and repeatable deployments
Tracking org changes
Unit testing
Backup
How does Salesforce DX help here?
You’ll notice that DX doesn’t directly perform any of these tasks. Instead, DX provides some building blocks to help you put together these workflows yourself.
An automated release process, for example, might consist of the following:
A scheduling/automation server, such as TeamCity or Jenkins.
Your version control provider, such as GitHub, GitLab, or Bitbucket.
Your Salesforce environments — DE orgs, sandboxes, prod, and scratch orgs.
Tools like the Force.com migration tool or the DX CLI for talking to Salesforce’s APIs, alongside the git CLI to pull and push from your version control system.
A series of bespoke scripts that pull these disparate tools together, designed to perform deployment-related tasks like packaging and pushing metadata, or running unit tests.
You’ll notice it was possible to piece together a CI set-up pre-DX, but there are two major differences:
Scratch orgs make it much easier to start from source, because spinning up a scratch org and hydrating it from version control is much easier than bending an existing sandbox into shape.
The DX source format facilitated by the new CLI makes editing and deploying components of larger objects more straightforward.
Adopting Salesforce DX
So what does the journey from legacy release management to DX-based DevOps look like for teams looking to press forward with adoption?
A good starting point for adopting SFDX is to begin with version control.
Once your metadata is under version control, the next steps depend on your goals. Remember, DX is a toolkit, not an end in its own right. It’s designed to facilitate modern development and DevOps best practices — but what that looks like for you will vary from team to team, depending on the problems you’re currently facing, the composition of your team, and what you’re looking to achieve.
For example, you might be looking to work from version control so that you have a full audit history of changes to your orgs.
The tools you need will vary depending on your goals and your background. Here are some common goals, and sample tools you might want to adopt:
Adopting version control as the source of truth.
Adopting continuous integration.
Once you have source control in place, it unlocks whole new workflows that weren’t possible before. For example:
Using short-lived ephemeral orgs in the form of Scratch Orgs for rapid isolated change.
Employing Continuous Integration, where every change that members of your team make is verified and tested.
Easily auditing and understanding how items of configuration have changed over time.
Adopting Unlocked Packages, to have encapsulated artifacts that are moved around environments, avoiding the issues that the Happy Soup can bring.
Version control for the whole team is something that Gearset provides to our wide range of customers. Gearset integrates popular source control providers such as GitHub, Microsoft VSTS, BitBucket, and GitLab with Salesforce orgs. This makes it easy for everybody on the team to collaborate through the source control system in a clicks-not-codes manner, without needing to learn complicated CLI tooling, or even understand many of the overly complex concepts within popular source control systems like git.
If you're looking to integrate Salesforce DX into your DevOps process, version control and Gearset are great places to start.