SFDX - an exec summary
SFDX - an exec summary
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
You'd (ideally) create one or more sandboxes for Dev, QA, UAT/pre-prod environments
You'd develop in dev, test in QA and get business sign-off in UAT
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
Use an IDE ( like Eclipse or IntelliJ) - uses the force.com migration tool behind the scenes
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.
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.
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:
Create / delete / login / logout Org(s)
Deploy / push / retrieve / pull metadata to/from Salesforce
Create / update / delete metadata
Run tests
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:
Setup or initialise your git repo with source format metadata
Create one or more sandboxes for Dev, QA, UAT/pre-prod ( you still need to do this)
Work on the user-story using VSCode and salesforce CLI
Test your work by creating an unlocked package and deploying it to a scratch org
Commit the change to your repo
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:
SFDX is a new and different way of building Salesforce apps
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.
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