Source-driven development is a way of working, not a single button. You set it up by creating a DX project, connecting it to version control, and enabling source-tracked environments. These steps describe the standard path using the Salesforce CLI.
- Create a DX project
Use the Salesforce CLI to generate a new project. This produces the standard directory layout and an sfdx-project.json file that declares your package directories and source API version. Commit this skeleton to Git as your starting point.
- Authorize a Dev Hub
Source-driven development uses scratch orgs, which are created from a Dev Hub. Enable Dev Hub in a production or Developer Edition org, then authorize it from the CLI so your project can request scratch orgs.
- Create a scratch org and push source
Spin up a scratch org from your project, then push your local source into it. Source tracking now records changes on both sides, so you can push local edits in and pull org edits back to keep the project and org in sync.
- Wire continuous integration
Add a CI job that, on each branch or pull request, creates a scratch org, deploys the source, and runs your Apex tests. Because the CLI scripts cleanly, this turns the repository into the gate that every change passes through.
Best for teams moving off change sets. Works with non-source-tracked sandboxes, Developer Edition orgs, or production, storing everything in source control while you retrieve and deploy directly.
Organizes source into packages and develops against source-tracked scratch orgs with CI/CD. Here the version control system is unambiguously the source of truth.
Available on scratch orgs and Developer or Developer Pro sandboxes. Not available on partial copy, full copy, or production orgs, which receive deployments instead.
- Change sets treat the production org as the source of truth. Source-driven development moves that authority to the repository, so retrain the team to commit changes rather than build directly in an org.
- Source tracking does not work on partial copy, full copy, or production orgs. Plan to author changes on scratch orgs or Developer sandboxes and deploy downstream.
- Scratch orgs are temporary and expire. Never store anything you cannot recreate from source, because the org is meant to be thrown away.