Source-driven deployment with Salesforce CLI and packages
Convert metadata to source format, use .forceignore and source tracking with conflict resolution, choose test levels and per-class coverage, validate then quick deploy or dry-run, delete components with destructive manifests, shape scratch orgs, release unlocked packages, authorize CI with JWT, and pick DevOps Center over change sets.
Given a scenario, formulate the deployment process, supporting tools, and mechanisms for source-driven development.
~8 min read · 14 practice questions ·
What the exam expects
- Convert Metadata API files to source format, exclude files with
.forceignore, and resolve source-tracking conflicts. - Predict which tests run and which coverage rule applies for each test level, and plan validate plus quick deploy or a sandbox dry run.
- Delete components with destructive changes manifests and shape scratch orgs with a definition file.
- Release an unlocked package version, authorize an unattended pipeline with JWT, and recommend DevOps Center over change sets.
Key terms: source format (the decomposed DX file shape, versus Metadata API's metadata format); source tracking (the CLI's local record of changes between a project and a scratch org or sandbox); test level (which Apex tests a deployment runs); quick deploy (deploying a successful validation without rerunning tests); destructive changes manifest (a package.xml-shaped file listing components to delete).
This unit assumes the Platform Developer guide's Salesforce DX, the CLI and Developer Console and Sandboxes, change sets and deploying code.
Key facts
- Detail
sf project convert mdapi --root-dir
- Detail
.forceignore, same pattern rules as.gitignore
- Detail
- Scratch orgs by default; Developer and Developer Pro sandboxes once enabled
- Detail
deploy start --ignore-conflictson the merged component
- Detail
- Local tests when the package has Apex classes or triggers
- Detail
- 75% per deployed class and trigger
- Detail
- 10 days from when the validation started
- Detail
deploy start --dry-run --test-level RunLocalTests
- Detail
--post-destructive-changes
- Detail
- Validated, 75% coverage via
--code-coverage(not calculated for org-dependent packages)
Sources for this section (10)
- Convert Files in Metadata Format to Source Formatdeveloper.salesforce.com (opens in a new tab)
- How to Exclude Source When Syncingdeveloper.salesforce.com (opens in a new tab)
- Enable Source Tracking in Sandboxesdeveloper.salesforce.com (opens in a new tab)
- project deploy startdeveloper.salesforce.com (opens in a new tab)
- Resolve Conflicts Between Your Local Project and Orgdeveloper.salesforce.com (opens in a new tab)
- Running Tests in a Deploymentdeveloper.salesforce.com (opens in a new tab)
- Running a Subset of Tests in a Deploymentdeveloper.salesforce.com (opens in a new tab)
- project deploy quickdeveloper.salesforce.com (opens in a new tab)
- project deploy validatedeveloper.salesforce.com (opens in a new tab)
- Code Coverage for Unlocked Packagesdeveloper.salesforce.com (opens in a new tab)
- Why can't a flagless `sf project deploy start` check for conflicts against a Full sandbox?
- When does a production deployment run no tests by default?
- Why does `sf package version create` need `--code-coverage` before a production release?
- Which file keeps LWC `__tests__` folders out of deploys?
- What does DevOps Center (being renamed Lifecycle Center) add that change sets lack?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Platform Developer II pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 28 lessons of the Platform Developer II guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (14 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams