SFDX & Source-Driven Development

0/2 in this phase0/41 across the roadmap

📖 Concept

Salesforce DX (SFDX) is the modern development lifecycle for Salesforce. It introduces source-driven development, scratch orgs, and CLI-based workflows that align with industry-standard DevOps practices.

Key SFDX concepts:

Source Format — Metadata stored as granular files in Git
- Classes, triggers, LWC components, custom objects as individual files
- Version-controlled in Git (not in an org)
- Enables code review, branching, merge workflows
Scratch Orgs — Disposable development environments
- Created from a definition file (project-scratch-def.json)
- Include only the features and settings you need
- Last up to 30 days (configurable)
- Each developer gets their own isolated environment
Dev Hub — The org that manages scratch orgs
- Controls scratch org limits and settings
- Required for scratch org creation
- Usually your production org or a dedicated org
Package Development — Modular deployment
- Unlocked Packages: for internal org development
- Managed Packages: for ISV distribution (AppExchange)
- Package versions are immutable and deployable
CLI Commands (essential):

sf org create scratch      — Create a scratch org
sf project deploy start    — Deploy source to an org
sf project retrieve start  — Retrieve metadata from org
sf apex run                — Execute anonymous Apex
sf data import tree        — Import test data
sf org open                — Open the org in browser
sf package create          — Create a package
sf package version create  — Create a package version

Project structure:

my-project/
├── sfdx-project.json        — Project configuration
├── config/
│   └── project-scratch-def.json — Scratch org definition
├── force-app/
│   └── main/
│       └── default/
│           ├── classes/       — Apex classes
│           ├── triggers/      — Apex triggers
│           ├── lwc/           — Lightning Web Components
│           ├── aura/          — Aura components
│           ├── objects/       — Custom objects & fields
│           ├── permissionsets/ — Permission sets
│           └── layouts/       — Page layouts
├── scripts/
│   └── apex/                  — Anonymous Apex scripts
└── data/                      — Test data (JSON)

💻 Code Example

codeTap to expand ⛶

1// SFDX Commands & Configuration
2
3// 1. sfdx-project.json — Project configuration
4{
5    "packageDirectories": [
6        {
7            "path": "force-app",
8            "default": true,
9            "package": "MyApp",
10            "versionName": "ver 1.0",
11            "versionNumber": "1.0.0.NEXT"
12        }
13    ],
14    "name": "my-salesforce-project",
15    "namespace": "",
16    "sfdcLoginUrl": "https://login.salesforce.com",
17    "sourceApiVersion": "59.0"
18}
19
20// 2. project-scratch-def.json — Scratch org definition
21{
22    "orgName": "My Dev Org",
23    "edition": "Developer",
24    "features": [
25        "EnableSetPasswordInApi",
26        "Communities",
27        "ServiceCloud",
28        "SalesCloud"
29    ],
30    "settings": {
31        "lightningExperienceSettings": {
32            "enableS1DesktopEnabled": true
33        },
34        "mobileSettings": {
35            "enableS1EncryptedStoragePref2": false
36        },
37        "securitySettings": {
38            "passwordPolicies": {
39                "enableSetPasswordInApi": true
40            }
41        }
42    }
43}
44
45// 3. Common SFDX workflow commands (bash)
46// # Authenticate to Dev Hub
47// sf org login web --set-default-dev-hub --alias DevHub
48//
49// # Create a scratch org
50// sf org create scratch \
51//   --definition-file config/project-scratch-def.json \
52//   --set-default \
53//   --alias my-dev-org \
54//   --duration-days 14
55//
56// # Push source to scratch org
57// sf project deploy start
58//
59// # Pull changes from scratch org
60// sf project retrieve start
61//
62// # Run all tests
63// sf apex run test --synchronous --code-coverage --result-format human
64//
65// # Open scratch org in browser
66// sf org open
67//
68// # Import test data
69// sf data import tree --files data/Account.json data/Contact.json
70//
71// # Execute anonymous Apex
72// sf apex run --file scripts/apex/init-data.apex
73//
74// # Create a package version
75// sf package version create \
76//   --package MyApp \
77//   --installation-key test1234 \
78//   --wait 20
79//
80// # Deploy to sandbox/production
81// sf project deploy start \
82//   --target-org ProductionOrg \
83//   --test-level RunSpecifiedTests \
84//   --tests MyTestClass
85//
86// # Validate deployment (dry run)
87// sf project deploy start \
88//   --target-org ProductionOrg \
89//   --dry-run \
90//   --test-level RunLocalTests
91
92// 4. Data import file format (Account.json for tree import)
93{
94    "records": [
95        {
96            "attributes": {
97                "type": "Account",
98                "referenceId": "AccRef1"
99            },
100            "Name": "Test Corp",
101            "Industry": "Technology",
102            "AnnualRevenue": 5000000
103        }
104    ]
105}

🏋️ Practice Exercise

SFDX Practice:

Set up a new SFDX project from scratch with proper folder structure
Create a scratch org definition file with specific features enabled
Build a complete development workflow: create scratch org → deploy → test → retrieve
Create test data files (JSON) and import them into a scratch org
Write an anonymous Apex script to initialize data in a new scratch org
Set up an Unlocked Package and create a package version
Deploy to a sandbox using the CLI with specific test level
Validate a deployment (dry run) against production
Set up a .forceignore file to exclude specific metadata from deployment
Document your team's branching strategy (Git) for Salesforce development

⚠️ Common Mistakes

Not using source control (Git) — every Salesforce project should be in Git. Org-based development without source control leads to lost changes and conflicts
Creating scratch orgs without proper definition files — missing features in the scratch org definition causes deployment failures that don't happen in sandbox
Not running tests before deployment — production deployments require 75% coverage. Always validate with --dry-run first
Deploying directly to production without a sandbox validation — always deploy to a full sandbox first, then promote to production
Committing sensitive data (credentials, API keys) to Git — use .gitignore and .forceignore. Store secrets in Named Credentials or environment variables

💼 Interview Questions

🎤 Mock Interview

Mock interview is powered by AI for SFDX & Source-Driven Development. Login to unlock this feature.

Was this topic helpful?

← PreviousShield Platform Encryption & Compliance Next →Deployment Strategies & Packaging