This article is based on excerpts from our whitepaper on Salesforce DX and is designed to be a high level overview.

DX is helping modernise DevOps for Salesforce

The remit of DevOps in Salesforce is a little different to in other platforms, and boils down to any part of the develop-release cycle that’s still manual, but can be automated. There are four main areas as targets 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, like TeamCity or Jenkins
  • Your version control provider, like 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 for pulling and pushing 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, and 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 start with version control. 

Once your metadata is under version control, the next steps really 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 based 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 source of truth
  • Adopting continuous integration

Once you have source control in place, it unlocks whole new workflows that weren’t possible before:

  • Using short-lived ephemeral orgs in the form of Scratch Orgs for really rapid isolated change
  • Continuous Integration where every change anyone in your team makes is verified and tested
  • Easily audit and understand how pieces of configuration have changed over time
  • Adopting Unlocked Packages to have encapsulated artefacts that are moved around environments and avoid 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 and 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 a great place to start.

Did this answer your question?