Developer setup & VS Code

Professional Salesforce development happens on your local machine, not in the browser's Developer Console. The standard toolchain is Visual Studio Code with the official Salesforce Extension Pack, backed by the Salesforce CLI (the sf command). Getting this set up correctly is the first step that separates hobby tinkering from a repeatable, source-driven workflow.

Install three things: VS Code, the Salesforce Extension Pack from the VS Code marketplace (it bundles Apex language support, the Org Browser, and more), and the Salesforce CLI from the official installer. You also need a Java runtime, which the Apex language server depends on. Verify the CLI is working from a terminal:

# Confirm the CLI is installed
sf --version

# Create a new project scaffold
sf project generate --name myProject
cd myProject

# Authorise a dev org (opens a browser login)
sf org login web --alias devhub --set-default

# Pull metadata down from the org
sf project retrieve start --metadata ApexClass

A Salesforce project is just a folder of metadata files under force-app/main/default — classes, triggers, objects, LWC, and more — that you keep in source control with Git. This is the core shift from admin work: your org's configuration becomes text files you can diff, review, and deploy repeatably. You retrieve metadata from an org into the project and deploy project metadata to an org.

Two commands you will use constantly are sf project deploy start to push changes and sf project retrieve start to pull them. Within VS Code the extension pack surfaces these as palette commands and adds an Org Browser so you can retrieve individual components with a click.

As a first exercise, generate a project, authorise your Developer org, create a trivial Apex class, and deploy it. Confirm it appears in Setup. With a working local environment and source control, you are ready to understand what all this metadata actually is — the subject of the next lesson.