Salesforce DX, sandboxes and deployment

What you will build: a Salesforce DX project on your computer, a scratch org created from it, an Apex class deployed there with tests, and a plan for moving changes through sandboxes to production.

Prerequisites: a Developer Edition org, Visual Studio Code with the Salesforce Extension Pack, Git, and Node.js (needed by the CLI installer on some systems). Install the Salesforce CLI from the official download page, then check it with sf --version. You should know basic Apex and tests from earlier lessons.

In the early lessons you clicked in Setup and wrote code in the Developer Console. That works for learning. In a company, twenty people change the same org. Someone breaks a Flow, nobody knows who, and there is no way to go back. DevOps for Salesforce means three habits:

1. Source of truth in Git, not in an org. The code and configuration (called metadata) live in a repository with history. 2. Separate environments for building, testing and production. 3. Automated deployment and tests, so releases are repeatable and boring.

Sandboxes are created from a production org, so you will not have one in a free Developer Edition org. You can still create scratch orgs for free if you turn on Dev Hub in your Developer Edition org. The licence limits (how many sandboxes or scratch orgs, and their storage) depend on the edition, so check Salesforce Help for your org.

sf org login web --alias devhub --set-default-dev-hub
sf project generate --name brew-and-bean
cd brew-and-bean
git init

--set-default-dev-hub means later commands know which org creates scratch orgs.

The file config/project-scratch-def.json describes the scratch org. A small one is enough to start.

{
  "orgName": "Brew and Bean dev",
  "edition": "Developer",
  "features": [],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    }
  }
}

edition picks the licence level. features and settings switch on things your app needs, such as extra features or org preferences.

sf org create scratch --definition-file config/project-scratch-def.json --alias dev --set-default --duration-days 7
sf org open --target-org dev

The first command takes a minute or two. The second opens the new org in your browser. The org is empty: no data, no setup you made elsewhere.

Now add some code. The CLI can generate a class for you, which is a good habit because it also creates the required -meta.xml file.

sf apex generate class --name GreetingService --output-dir force-app/main/default/classes

This creates GreetingService.cls and GreetingService.cls-meta.xml.

Create a test class the same way, because production deployments need tests (see below).

sf project deploy start --target-org dev
sf apex run test --target-org dev --test-level RunLocalTests --result-format human --wait 10

The first command pushes your local metadata to the scratch org. The second runs all tests in the org (except those from installed packages) and waits up to 10 minutes.

Scratch orgs have source tracking: the CLI remembers what changed locally and in the org. That is why sf project deploy start with no extra options sends only your changes. If you change something in the org with clicks (say, you add a custom field in Setup), pull it back into your project with sf project retrieve start. The changed files then appear in force-app and you can commit them. Without source tracking, as in a Developer Edition org or production, you must say what to retrieve, with --source-dir or --metadata.

A common path is: feature branch in Git, then a scratch org or Developer sandbox to build, then a Pull Request, then a shared sandbox for integration testing and user testing (UAT), then production. Each step has a check, and nobody builds directly in production.

Before changing production, validate the deployment. A validation runs the whole deployment and tests but saves nothing. Production deployments must run tests and meet the code coverage rule: at least 75% of your Apex lines covered overall, and every trigger needs some coverage. Because of the rule, writing tests is part of being able to release at all.

# the manifest lists what to deploy, for example classes and triggers
sf project generate manifest --source-dir force-app --name manifest/package

# validate only: runs tests, saves nothing
sf project deploy start --manifest manifest/package.xml --target-org my-sandbox --dry-run --test-level RunLocalTests

# real deployment
sf project deploy start --manifest manifest/package.xml --target-org my-sandbox --test-level RunLocalTests

my-sandbox is a placeholder alias. Log in to a sandbox with sf org login web --alias my-sandbox --instance-url https://test.salesforce.com.

A small example of a CI check, written for GitHub Actions. It installs the CLI, logs in with a secret and validates the project on every Pull Request. Real setups store the login as a secret in the repository, never in the file. The details of getting the auth URL are in the Salesforce CLI documentation (look for the auth URL login flow with sf org login sfdx-url).

name: validate
on: pull_request
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install --global @salesforce/cli
      - run: echo "${{ secrets.SFDX_AUTH_URL }}" > auth.txt
      - run: sf org login sfdx-url --sfdx-url-file auth.txt --alias target
      - run: sf project deploy start --target-org target --dry-run --test-level RunLocalTests

Treat this as a sketch. Secrets, caching, deleting auth.txt and which org is validated need design for a real project.

I am a Salesforce developer in a team of [number] people. We have production, one Full sandbox and [other orgs]. Today we use [change sets / manual clicks / CLI]. Suggest a simple branching and deployment process with these environments, name the checks at each step, and list 5 things most likely to go wrong when we start. Keep it short and practical.

What to expect: Check that the plan never builds in production, validates before deploying and uses tests as a gate.