If you are a CIO, CMO, or CTO and your company uses Salesforce CRM (or looking to implement it as part of your Digital Transformation  project), or you are a Delivery Manager responsible for multiple Salesforce projects - you might be wondering what the SFDX fuss is all about. Here's a primer that will give you a bird's-eye view of a modern DevOps toolkit on the Salesforce platform.

Let's start with the basics.

What is SFDX?

Salesforce Developer Experience (SFDX) is modern software development on the lightning platform. This definition implies that SFDX is a new way of developing software on the Salesforce platform, which will eventually replace the old way of developing software. And you'd be right in thinking that. Let's do a quick recap of how admins and devs developed and deployed before SFDX was conceived.

Note: This article does not cover managed package development (including the new second-generation managed packages i.e. 2GP)

DEVELOP :: Pre-SFDX

1. You'd (ideally) create one or more sandboxes for Dev, QA, UAT/pre-prod environments

2. You'd develop in dev, test in QA and get business sign-off in UAT

3. If you have developers (who know what they're doing) they'd use a version control system to track changes

This leads us nicely to DEPLOY :: Pre-SFDX

You would use one of the following tools to move metadata

1. Use an IDE ( like Eclipse or IntelliJ) - uses the force.com migration tool behind the scenes

2. Change Sets - a declarative way of deploying changes between orgs. Not recommended because it is difficult to track deployments and is error prone for large deployments. The only good thing about it is the cute deployment fish caused due to a bug in the front-end javascript.

3. Force.com migration tool (aka Ant Migration tool) - Java/ant based command line utility for moving metadata between a local directory and a Salesforce org. It is a wrapper around the Metadata API used to retrieve, deploy, create, update, or delete customisations (i.e. metadata) for your org. You'd use the ant tool to create custom scripts that automate most aspects of your deployment.

4. You'd also use the Ant migration tool to write bash scripts along with version control hooks to create a Continuous Integration pipeline

The key concept to understand here is that the development and deployment revolved around the idea that the ORG was the source of truth and not your version controlled source code.

SFDX was invented to create a source code driven development model as opposed to the "legacy" org based development model.

As such, it introduced a new set of tools and paradigm to support this approach.

SFDX  - a new way to DevOps

The tools that you need to be aware of in this  brave new world of SFDX devops are:

SALESFORCE CLI

I cannot improve on the official definition, so here it is

Salesforce CLI is a powerful command line interface that simplifies development and build automation when working with your salesforce org.

It is a swiss-army knife of salesforce development tools - a full fledged REST client that comes packaged with standard commands but also has a plugin generator for developers to build their own custom plugins.

As the name implies, it is a command line tool and as such requires someone who is comfortable using the command line (the awesome admins will need to up their game). But it is also its strength because the command line is a versatile and multifaceted tool.

Some of things you  can do with the CLI are:

1. Create / delete  /  login / logout  Org(s)

2. Deploy / push / retrieve / pull metadata to/from Salesforce

3. Create / update / delete metadata

4. Run tests

5. Manage packages

But it can do more, you can create your own custom plugin to build whatever takes your fancy using javascript/typescript.

VS CODE (and salesforce extension pack)

Salesforce has officially abandoned Eclipse (good riddance) and has hitched it's development wagon to VSCode (a modern open-source IDE from Microsoft).

Using the Salesforce extension pack, you should be able to do everything that Salesforce CLI does; you can also run commands from the VSCode terminal.

PACKAGE DEVELOPMENT

The final piece of the puzzle that you need to understand is the new (unlocked) package development model. As we've mentioned before, SFDX shifts the dev model from org based to source code based, therefore a salesforce dx project now works with a new format called source format as opposed to the metadata format.

The new source format is what makes your source code the source of truth instead of the org.

Source format is optimised to work with version  control systems. It uses a different set of files and file extensions from what you’re accustomed when using Metadata API.

Before, all custom objects and object translations were stored in one large metadata file.

A Salesforce DX project stores custom objects and custom object translations in intuitive subdirectories. Source format makes it much easier to find what you want to change or update.

To support this development model, SFDX offers Unlocked  package which follows a source-driven development model. An  unlocked package is a set of independent metadata and configuration components that represents a feature or a user story. They are similar to a managed package (distributed via the AppExchange) but are suited for internal business apps.

So, how do you now develop and test your unlocked packages? This leads us nicely to....

SCRATCH ORGS

Once again, the official definition does a good job of summarising what it is:

The scratch org is a source-driven and disposable deployment of Salesforce code and metadata. A scratch org is fully configurable, allowing developers to emulate different Salesforce editions with different features and preferences. You can share the scratch org configuration file with other team members, so you all have the same basic org in which to do your development.

IMHO, this is what makes SFDX such a compelling proposition. You now have a disposable environment that is source-driven and contains only your modifications and changes that you can evolve and test in isolation.

The only downside of scratch orgs, afaik, is that installing and configuring large managed packages like vlocity or financial force can be a pain; or if you have dependencies between your work and another developers work.

So, here's the NEW develop and deploy model with SFDX:

1. Setup or initialise your git repo with source format metadata

2. Create one or more sandboxes for Dev, QA, UAT/pre-prod ( you still need to do this)

3. Work on the user-story using VSCode and salesforce CLI

4. Test your work by creating an unlocked package and deploying it to a scratch org

5. Commit the change to your repo

6. The commit hooks calls a bash script that will deploy the change to a target sandbox  or to Production

I hope you'd agree that this simplifies the development model A LOT.

TL;DR summary

Here are some of your key take-aways:

1. SFDX is a new and different way of building Salesforce apps

2. SFDX will require you to spend time, money and effort to either replace the existing CI/CD process, or build a new process that involves writing custom scripts or plugins to automate the creation of Scratch orgs, populating test data and deploying the new source format to various sandboxes. The ROI will be improved deployment frequency (with smaller packages), more granular control over deployment packages, and the inimitable ability to revert defects.

3. Switching to SFDX involves learning how to use the following:

   • Salesforce CLI and the (bazillion) commands that come with it. This has a steep learning curve

   • Understanding the new Source format and how to interoperate with the "legacy" metadata format

   • Exploiting the scratch orgs for dev and testing

   • Shifting your mindset from org driven to source code driven model. Easier said than done for veteran developers on the platform. This also means you must grok the nuances of Git commands.

   • Learning to use VS code properly