100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

The Apex Development Environment

A tour of the tools used to write, test, and deploy Apex code, from VS Code and Salesforce CLI to Developer Console, sandboxes, and scratch orgs.

FoundationsBeginner8 min readJul 10, 2026
Analogies

The Apex Development Environment

Modern Apex development is built around Visual Studio Code with the Salesforce Extension Pack, paired with Salesforce CLI (the 'sf' command), which together provide syntax highlighting, IntelliSense, org browsing, and source deployment. The older Developer Console, accessible from Setup, still remains useful for quick ad hoc debugging and running one-off Apex, even though it's no longer the primary tool for serious ongoing development.

🏏

Cricket analogy: Like a modern player relying on video analysis software and a dedicated throwdown coach (VS Code plus CLI) for serious technique work, while a quick nets session (Developer Console) still helps for a fast warm-up before play.

Setting Up VS Code and Salesforce CLI

Getting set up involves installing Salesforce CLI and the VS Code Salesforce Extension Pack, authenticating an org with sf org login web, scaffolding a source-driven project with sf project generate, and then using sf project deploy start and sf project retrieve start to push and pull metadata between your local files and the org.

🏏

Cricket analogy: Like packing your kit bag and registering with the board before a tour - getting authenticated onto an org and having the right extensions installed before you're allowed onto the ground to actually work.

Developer Console and Anonymous Apex

The Developer Console's 'Execute Anonymous' window (Debug menu) lets you run a snippet of Apex immediately without deploying it as a permanent class, which is ideal for quick experiments, one-off data fixes, or checking a query's results. Pairing this with System.debug() statements and the debug log viewer is one of the fastest ways to trace what your code is actually doing at runtime.

🏏

Cricket analogy: Like a batter taking a few throwdowns in the indoor nets right before the match to test timing, without it counting as an official innings on the scorecard.

Sandboxes, Scratch Orgs and Deployment

Sandboxes are isolated, persistent copies of an org used for safe development and testing without touching live data, while scratch orgs are ephemeral, source-driven orgs whose features and settings are defined in a scratch-org-def.json file - ideal for short-lived feature branches and CI/CD pipelines. In both cases, all Apex source lives in version control (git) and is deployed through a controlled pipeline rather than edited directly in a live org.

🏏

Cricket analogy: Like practicing a brand-new shot in the nets before ever attempting it in a live international match, so an early mistake doesn't cost real runs on the scoreboard.

bash
sf org login web --alias myDevOrg
sf project generate --name my-apex-project
sf project deploy start --source-dir force-app
sf apex run test --test-level RunLocalTests

Salesforce CLI (sf, the successor to sfdx) is the standard tool for authenticating orgs, retrieving and deploying metadata, and running Apex tests from the command line or from CI pipelines such as GitHub Actions.

Never develop directly in a Production org. Always work in a Developer Sandbox or Scratch Org, track every change in version control, and deploy through a validated pipeline - editing Production directly bypasses testing and can break live business processes for real users.

  • Developer Console remains handy for quick 'Execute Anonymous' runs and debug logs, but isn't used for serious ongoing development.
  • VS Code with the Salesforce Extension Pack, paired with Salesforce CLI (sf), is the standard modern toolchain.
  • sf org login web authenticates a CLI session against a Salesforce org via browser-based OAuth.
  • Scratch orgs are ephemeral, source-driven orgs defined by a scratch-org-def.json file, ideal for CI/CD pipelines.
  • Sandboxes provide isolated, persistent copies of an org for safe development and testing.
  • Never develop directly in Production; always use a sandbox or scratch org with source control.
  • sf project deploy start and sf apex run test push and validate metadata from the command line.

Practice what you learned

Was this page helpful?

Topics covered

#Programming#ApexSalesforceStudyNotes#TheApexDevelopmentEnvironment#Apex#Development#Environment#Setting#StudyNotes#SkillVeris#ExamPrep