If you’re currently using MavensMate or Eclipse within Salesforce, transitioning to the Salesforce Developer Experience (SFDX) should be a priority for you. In the last year and a half, Salesforce has stopped supporting a number of development environments like these. This post discusses the benefits of switching to Salesforce Developer Experience (SFDX), and how to make the transition seamlessly.
Why Switch to Salesforce Developer Experience (SFDX)?
Today, MavensMate is no longer being actively developed or supported. Without regular updates, MavensMate is less secure and slower every day. Comparably, the Salesforce DX command line (SFDX) is updated with each Salesforce release so new features are introduced regularly, it’s faster, and it’s scriptable.
Transitioning from a Graphical User Interface (GUI) application over to a Command Line Interface (CLI), like any transition, can take some getting used to. However, there are lots of benefits to transitioning, including, scratch orgs and the potential to automate time-consuming tasks using the command line. Also, features like Integrated Development Environment (IDEs) such as VSCode with the Salesforce supported extensions and IntelliJ IDE with the illuminated cloud plugin make interacting with the SFDX commands a lot easier. While SFDX has quite a few flashy features (for example Replay Debugger) this post will focus on the benefits of the new command line and working in scratch orgs.
Automation with SFDX
One of the main benefits of switching to SFDX is the potential to automate repetitive tasks by leveraging scripts. If you’re not familiar with the command line, it is a full set of instructions that can be put in any order. The command line allows your team to create Bash scripts (Linux/Mac) or Batch Scripts (Windows) to automate repetitive tasks. This holds tremendous potential for time-savings for your organization. When approaching new technology, think about the output controls you or your team have access to and how those can be leveraged to automate or refine Salesforce work. Here are some of the powerful commands that can be used directly through the command line:
- Export (SOQL) / Import (CSV) data
- Bulk API Delete/Upserts
- Full CRUD on individual records
- Run Anonymous Apex and Apex Tests
- Deploy/Retrieve/List Metadata with Metadata API
- List and Open in a browser a connected Salesforce instance
- Create/Delete scratch orgs
- Create/Version/Install packages
- Create/Display Users and Assign permission sets to them
- Convert between SFDX Component Structure and Metadata API Structure
All these commands can return JSON responses which can then be parsed with other command line tools like Jq. A quick search on SFDX script examples will return a lot of great ideas around automatically creating scratch orgs and how to push in metadata in a single step (we talk more about this below).
Here are three examples of how to leverage the power of SFDX (remember you can query and run any Apex scripts):
- If you have multiple Salesforce orgs for your company and you need to search through all of them to see how many contain a certain contact. Here’s what the Bash script would look like:
$arrayOfOrgUserNames
$contactEmail
for i in ${ArrayOfOrgUserNames[@]}
do
sfdx force:data:soql:query -q “Select id,email,name where email = $ContactEmail” -u $i –json > $i.txt
done
- If you need to deactivate a user safely in Salesforce, your team can write a script that goes through all the steps.
- If you need to refactor all of a given type of metadata to add/remove a naming convention, you can pull all that metadata with the Metadata API/Source Commands then use SED (Linux command tool) with regex to make changes. Then, you can use Metadata API /Source commands to delete the old metadata and push the new.
Scratch Orgs
The second major benefit that comes with leveraging SFDX is being able to use scratch orgs, which are essentially blank mini developer orgs. In a sandbox, all your org’s metadata is included. In comparison, when using scratch orgs, you only push in the metadata that you need; which is more efficient.
The SFDX development practice revolves around breaking down your org into like components and building out packages to bundle these (more on packages here). However, if you aren’t using packaged code you can also leverage the Salesforce Metadata API from the SFDX command line. Take the existing package.xml you’ve been building for your deployments and use it to deploy to your fresh scratch org. As we mentioned above, this can all be done in a single script. Which means, creating a scratch org, pushing in metadata from production (or elsewhere) and even opening up the org in your browser, can be one single step.
Have you ever made a mistake in your sandbox and had to do a complete refresh? Scratch orgs are quick and easy to spin up meaning, if mistakes are made, the scratch org can be deleted and a new one spun up immediately.
This is one of my favorite blog posts on scratch orgs as it walks through how to create a new scratch org, install a needed package, and push your metadata into that scratch org.
How to Automate Deployment Documentation
If you’ve ever worked on a large multi-person and/or multi-company Salesforce project, most likely you have worked on a spreadsheet like the one below:
This is often required to communicate to your team what changes you’ve made associated to a particular user story so that when a user story goes from an “In Development” to “Development Complete” stage, the person in charge of the deployment can move that metadata to a QA environment. Scratch orgs automatically track all metadata changes so your team doesn’t have to. Transitioning to SFDX saves your team time as these spreadsheets are no longer necessary when leveraging scratch orgs.
How to Transition to SFDX
This won’t come as a surprise to many of you reading this, but if you are looking to transition to SFDX the best place to start is Trailhead. Complete the Build Apps Together with Package Development to learn how to use the command line and general SFDX best practices.
Once you have completed those trails and have a decent understanding of how to use the CLI, try using only the CLI and a scratch org for your next development requirement. Writing code in a blank org often forces you to write more module code which can find a use case to more than one problem. For example, if you’re a Salesforce Partner, your team may find several clients who could benefit from one package your team creates.
Wrap Up
We hope this post provided actionable insight on how and why to switch to SFDX. If you have any questions about how to transition or tips for getting your team to transition, reach out today!
Lastly, if you enjoyed this post, you may also like these Salesforce reads:
