Learn Salesforce DX and VS Code: The sf CLI, Scratch Orgs and Source-Driven Development

To learn Salesforce DX and VS Code, learn four things: how a Salesforce DX project stores metadata as source, how to authorise orgs and create scratch orgs with the sf CLI, how to deploy, retrieve and run tests from the command line, and how to set up VS Code with the Salesforce Extension Pack so the editor does that work for you. The two courses above cover the CLI workflow and CI/CD practices, then the editor setup and advanced settings, all done live on a real project.

What Salesforce DX is and why teams use it

Salesforce DX is the source-driven development model for Salesforce. Instead of treating an org as the source of truth and moving changes with change sets, you:

• Keep metadata in a Git repository, in the source format the CLI understands
• Develop in an isolated org, either a short-lived scratch org or a sandbox with source tracking
• Deploy with commands that can run identically on your laptop and in a CI pipeline
• Run tests automatically before anything reaches production

On real teams, that means code review on every change, repeatable deployments, and new developers who can create a working org from the repository in minutes rather than waiting for a sandbox refresh.

Prerequisites

• Basic Salesforce development. You should know what Apex classes, triggers and LWCs are. See Apex and LWC.
• Basic Git. Clone, branch, commit and push.
• Comfort with a terminal. You'll run commands, read their output and fix what they report.
• A Dev Hub if you want scratch orgs. You can enable it in a Developer Edition org.

What you'll be able to do afterwards

• Create a DX project and understand sfdx-project.json, .forceignore and the folder structure
• Authorise orgs, create scratch orgs from a definition file and open them
• Deploy and retrieve metadata, with source tracking showing what changed
• Run Apex tests with coverage from the CLI, and validate deployments before you release
• Set up VS Code with the Apex language server, Replay Debugger, SOQL tools, Prettier and ESLint
• Script a simple CI pipeline that validates every pull request

A hands-on example: a feature from scratch org to validated deployment

Here's the workflow I use for a small feature, with current sf commands.

# One-time: log in to your Dev Hub and make it the default
sf org login web --alias devhub --set-default-dev-hub

# Create a short-lived scratch org for this feature
sf org create scratch --definition-file config/project-scratch-def.json --alias feature-org --duration-days 7 --set-default

# Generate an Apex class and an LWC in the project
sf apex generate class --name AccountTriggerHandler --output-dir force-app/main/default/classes
sf lightning generate component --type lwc --name accountSummary --output-dir force-app/main/default/lwc

# Deploy your local changes to the scratch org and open it
sf project deploy start
sf org open

# Pull down changes you made in the org's Setup UI
sf project retrieve start

# Run local tests with coverage
sf apex run test --test-level RunLocalTests --code-coverage --result-format human --wait 10

# Validate against UAT without deploying
sf project deploy start --source-dir force-app --target-org uat --test-level RunLocalTests --dry-run

Why each step matters:

• Scratch orgs are disposable. If an experiment goes wrong, delete the org and create a new one from the same definition file. Your work lives in Git, not in the org.
• Source tracking means sf project deploy start and sf project retrieve start only move what changed, in both directions.
• Retrieve after clicking in Setup. Fields, layouts and permission sets you create in the UI aren't in your repository until you retrieve them.
• --dry-run validates a deployment, including tests, without changing the target org. Run it before every release.

If you're following an older blog post, translate the commands rather than copying them:

Setting up VS Code properly

The command line is the foundation, but you'll spend most of your day in the editor. The setup I recommend, and walk through in Mastering Visual Studio Code:

• Salesforce Extension Pack. Installs the Apex, LWC, SOQL, Visualforce and Replay Debugger extensions together. Most CLI commands are also available from the Command Palette, so you can deploy the file you're editing with one shortcut.
• A supported Java JDK for the Apex language server, configured in the Salesforce extension settings. Without it, Apex completion and go-to-definition don't work.
• Prettier with the Apex plugin, so formatting never shows up in code review again.
• ESLint with the Salesforce LWC rules, which catch common component mistakes as you type.
• The Apex Replay Debugger, which steps through a debug log as if it were a live debugging session. It's the fastest way to understand why a trigger did what it did.

Commit the shared settings, such as formatting rules and recommended extensions, to the repository so every developer on the team gets the same setup.

Common mistakes beginners make

1. Copying sfdx force: commands from old tutorials. Learn the sf equivalents. Run sf --help or sf <topic> --help when you're unsure.
2. Clicking in Setup and forgetting to retrieve. The change exists in the org but not in Git, so it never reaches production.
3. Committing secrets or auth files. Keep credentials out of the repository and use your CI system's secret store.
4. No .forceignore. Without it, you'll deploy and retrieve metadata you never meant to touch.
5. Deploying the whole force-app folder to production by habit. Know exactly what's in a release, and always validate first.
6. Skipping tests until deployment day. Run them locally on every change, so a production validation isn't the first time they run.
7. Fighting the editor. If code completion stops working, check the Apex language server's Java setup before anything else.

How DX and VS Code connect to the other topics

• Every coding topic, from Apex and Apex testing to LWC and integration, is easier with a proper local setup. Do this early, not last.
• The Salesforce developer roadmap puts tooling alongside your first Apex, because you'll use it every day.
• Teams standardising how new hires set up their tools can use these courses for onboarding. See Salesforce team training and onboarding.

Who should skip this

• Skip it if you're an admin who doesn't deploy code. Change sets or your team's release process may be all you need.
• Skip it if you already work daily with the sf CLI, scratch orgs and CI. The VS Code advanced-settings section may still save you time.
• Don't skip it if you develop in the Developer Console. It's fine for quick checks, but it won't scale to a team.

There are no refunds. The free Apex Triggers Framework 101 course shows the same teaching style if you want to try it first.