Salesforce CLI and Salesforce DX

Salesforce CLI and Salesforce DX: A Comprehensive Guide for Platform Developer 1 Exam

Introduction

Salesforce CLI (Command Line Interface) and Salesforce DX (Developer Experience) represent a fundamental shift in how developers build, test, and deploy applications on the Salesforce platform. For the Platform Developer 1 exam, understanding these tools is essential, as they form the backbone of modern Salesforce development workflows. This guide covers everything you need to know about Salesforce CLI and DX, from core concepts to exam-specific strategies.

Why Salesforce CLI and DX Are Important

Before Salesforce DX, development on the platform was primarily org-centric. Developers worked directly in production or sandbox orgs, made changes using the Setup UI or the Force.com IDE, and deployments were handled via change sets or the Metadata API. This approach had several limitations:

- Lack of source control integration: It was difficult to maintain a single source of truth for code and metadata.
- Collaboration challenges: Multiple developers working in the same org could overwrite each other's changes.
- Limited automation: CI/CD (Continuous Integration/Continuous Deployment) pipelines were hard to implement.
- Environment management: Spinning up new development environments was time-consuming and expensive.

Salesforce DX addresses all these issues by introducing a source-driven development model that aligns Salesforce development with modern software development practices. Salesforce CLI is the primary tool that developers use to interact with the DX ecosystem.

What Is Salesforce DX?

Salesforce DX is a set of tools, features, and practices that enable modern, collaborative, and agile development on the Salesforce platform. Key components include:

1. Salesforce CLI (sf/sfdx): A powerful command-line tool for creating, building, testing, and deploying Salesforce applications.
2. Scratch Orgs: Temporary, configurable, and disposable Salesforce environments used for development and testing.
3. Dev Hub: A production org or business org that manages scratch org creation and namespace registries.
4. Source Format: A decomposed, more granular file format for metadata that is easier to manage in version control systems.
5. Salesforce DX Project: A local directory structure that organizes your source code, configuration, and metadata.
6. Second-Generation Packaging (2GP): A modern approach to packaging that supports modular development.

What Is Salesforce CLI?

Salesforce CLI is the command-line interface that developers use to perform virtually all DX-related operations. It can be used to:

- Authorize and manage orgs (scratch orgs, sandboxes, production orgs)
- Create and configure scratch orgs
- Push and pull source code between your local project and orgs
- Deploy and retrieve metadata
- Run Apex tests
- Execute anonymous Apex
- Generate and work with DX projects
- Install and manage packages
- Open orgs in a browser
- Perform data operations (import, export, query)

The CLI was originally accessed using the sfdx command prefix but has been consolidated under the sf command prefix in newer versions. For the exam, be familiar with both.

How Salesforce DX Works: The Development Lifecycle

Understanding the DX development lifecycle is critical for the exam. Here is the typical workflow:

Step 1: Set Up the Dev Hub
A Dev Hub must be enabled in a production org or a business org. The Dev Hub is the central org that governs scratch org creation. You authorize the Dev Hub using the CLI:

sf org login web --set-default-dev-hub --alias MyDevHub

This opens a browser for OAuth-based authentication.

Step 2: Create a Salesforce DX Project
A DX project is created locally using:

sf project generate --name MyProject

This creates a project directory with the following key files and folders:

- sfdx-project.json: The project configuration file. It defines the source directories (packageDirectories), API version, namespace, and other settings. This file is critical for the exam.
- force-app/main/default/: The default directory for your source code and metadata.
- config/: Contains scratch org definition files.

Step 3: Create a Scratch Org Definition File
The scratch org definition file (often called project-scratch-def.json) specifies the shape and features of the scratch org. It can define:

- Edition: Developer, Enterprise, etc.
- Features: Such as Communities, ServiceCloud, etc.
- Org Preferences/Settings: Such as enabling specific platform features.
- Country and Language

Example:
{
  "orgName": "My Scratch Org",
  "edition": "Developer",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    }
  }
}

Step 4: Create a Scratch Org
Using the CLI:

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

Key points about scratch orgs:
- They are temporary (maximum duration of 30 days).
- They are fully configurable based on the definition file.
- They are created from the Dev Hub.
- Each Dev Hub has limits on the number of active scratch orgs.
- They are ideal for isolated feature development and testing.

Step 5: Push Source to the Scratch Org
In the source-driven model, you develop locally and push changes to the scratch org:

sf project deploy start (or the legacy sfdx force:source:push)

The CLI tracks changes locally and only pushes what has changed (delta deployment).

Step 6: Develop and Make Changes
You can develop using your preferred IDE (VS Code with Salesforce Extensions is the recommended setup). Changes can be made locally or in the scratch org.

Step 7: Pull Changes from the Scratch Org
If changes were made directly in the scratch org (e.g., declarative changes via the UI), pull them back to your local project:

sf project retrieve start (or the legacy sfdx force:source:pull)

Step 8: Run Tests
Run Apex tests using the CLI:

sf apex run test --code-coverage --result-format human

Step 9: Commit to Version Control
Because the source is local, you can use Git or any version control system to commit changes, create branches, and collaborate with team members.

Step 10: Deploy to Other Orgs
When ready, deploy your source to a sandbox, packaging org, or production org. You can use:

sf project deploy start --target-org ProductionOrg

Or use the Metadata API format deployment for non-scratch org targets.

Key Concepts for the Exam

1. Source Tracking
Salesforce CLI provides automatic source tracking between your local project and scratch orgs (and also sandboxes with source tracking enabled). This means the CLI knows which files have changed locally and in the org, enabling efficient push/pull operations. Source tracking is only available with scratch orgs and source-tracking-enabled sandboxes, NOT with production orgs or traditional sandboxes.

2. sfdx-project.json
This is the most important configuration file in a DX project. Key properties include:
- packageDirectories: An array defining where source code lives. At least one directory must be specified, and one must be marked as the default.
- namespace: The namespace for your project (if applicable).
- sfdcLoginUrl: The default login URL.
- sourceApiVersion: The API version used for source operations.

3. Scratch Orgs vs. Sandboxes
Understanding the difference is crucial:
- Scratch Orgs: Temporary (up to 30 days), source-driven, created from a definition file, managed by the Dev Hub, no data from production, fully configurable shape.
- Sandboxes: Longer-lived, can contain data from production (Full and Partial Copy), created from production org, used for testing, staging, and UAT.

4. Org Authorization
The CLI supports multiple authorization methods:
- Web-based (OAuth): sf org login web — opens a browser for interactive login.
- JWT-based: sf org login jwt — uses a connected app and certificates for headless/automated authentication (ideal for CI/CD).
- SFDX Auth URL: Using a stored auth URL for automated scenarios.

5. Aliases and Default Orgs
You can set aliases for orgs and designate default orgs:
- Default Dev Hub: Used for scratch org creation.
- Default Target Org: Used for push, pull, deploy, and retrieve operations.

6. Metadata API vs. Source Format
- Metadata API (mdapi) format: The traditional format with package.xml manifest files. Metadata is stored as monolithic XML files.
- Source format: The DX format where metadata is decomposed into smaller, more manageable files. For example, a custom object's fields, record types, and layouts are stored as separate files rather than one large XML file.

You can convert between formats using CLI commands:
- sf project convert mdapi (convert from mdapi to source format)
- sf project convert source (convert from source to mdapi format)

7. Package Development with DX
Salesforce DX supports second-generation packages (2GP), which are created and managed via the CLI. This is different from first-generation packages (1GP) managed through the Salesforce UI. Key CLI commands include creating package versions and installing packages.

8. Data Operations
Salesforce CLI can import and export data using:
- sf data import tree — imports data from JSON files
- sf data export tree — exports data to JSON files
- sf data query — runs SOQL queries

9. Anonymous Apex Execution
sf apex run --file script.apex — executes anonymous Apex code, useful for testing and data manipulation.

10. VS Code and Salesforce Extensions
While the exam focuses on the CLI, know that Visual Studio Code with the Salesforce Extension Pack is the recommended IDE. It provides integrated access to CLI commands, IntelliSense for Apex and Lightning, and a rich development experience.

Common CLI Commands to Know

Here is a reference of important CLI commands (using the newer sf syntax):

- sf org login web — Authorize an org via browser
- sf org login jwt — Authorize an org using JWT flow
- sf org create scratch — Create a scratch org
- sf org delete scratch — Delete a scratch org
- sf org open — Open an org in the browser
- sf org list — List all authorized orgs
- sf project generate — Create a new DX project
- sf project deploy start — Deploy source to an org
- sf project retrieve start — Retrieve source from an org
- sf apex run test — Run Apex tests
- sf apex run — Execute anonymous Apex
- sf data query — Execute a SOQL query
- sf data import tree — Import data
- sf org list limits — View org limits

Exam Tips: Answering Questions on Salesforce CLI and Salesforce DX

1. Know the purpose of the sfdx-project.json file: Expect questions about what this file defines. Remember it specifies package directories, source API version, namespace, and login URL. It does NOT contain org credentials or scratch org definitions.

2. Understand scratch org characteristics: Questions may ask about the maximum duration (30 days), the fact that they are disposable, that they are created from a definition file, and that they are managed by the Dev Hub. They do NOT copy data from production.

3. Distinguish between push/pull and deploy/retrieve: Push and pull are used with source-tracked orgs (scratch orgs and source-tracking sandboxes) and leverage automatic change tracking. Deploy and retrieve can be used with any org and require explicit specification of what to deploy or retrieve (using a manifest, source path, or metadata components).

4. Remember the role of the Dev Hub: The Dev Hub must be enabled in a production org or business org. It governs scratch org limits and manages namespace registries. Without a Dev Hub, you cannot create scratch orgs.

5. Know the authorization methods: Web-based OAuth is for interactive use, JWT is for CI/CD automation. If a question mentions automated deployments or continuous integration, JWT-based auth is the answer.

6. Source format vs. Metadata API format: If a question asks about working with version control or collaboration, source format is preferred because it decomposes metadata into smaller files, making merge conflicts easier to resolve.

7. Be cautious with command syntax: The exam may not test exact command syntax extensively, but understanding what each command does is important. Focus on the purpose and use case of commands rather than memorizing exact flags.

8. CI/CD scenarios: If questions describe automated build and deployment scenarios, the answer likely involves Salesforce CLI with JWT authentication, scratch orgs for testing, and automated Apex test execution.

9. Watch for distractor answers involving change sets: While change sets are still valid, questions about DX workflows will not use change sets. DX uses CLI-based deployments.

10. Project structure matters: Know that the default directory structure includes force-app/main/default/ and that the sfdx-project.json must reference all package directories. Questions about where to place source code will reference this structure.

11. Scratch org definition file is separate from sfdx-project.json: These are different files with different purposes. The scratch org definition file defines the org shape and features; sfdx-project.json defines the project structure and configuration.

12. Elimination strategy: When in doubt, eliminate answers that reference older tooling (Force.com IDE, change sets, ANT Migration Tool) when the question specifically asks about DX or modern development workflows. Conversely, if the question is about traditional deployments, DX-specific answers may not apply.

13. Second-generation packages: While not heavily tested, know that 2GP packages are developed and versioned using the CLI and are associated with a Dev Hub. They support unlocked packages (for internal use) and managed packages (for ISVs).

14. Test execution: The CLI can run specific test classes, test suites, or all tests. For deployment to production, 75% code coverage is still required, regardless of whether you use CLI or another deployment method.

15. Practice with real commands: While not a substitute for understanding concepts, hands-on experience with Salesforce CLI will reinforce your knowledge and help you answer scenario-based questions more confidently.

Summary

Salesforce CLI and DX represent the modern approach to Salesforce development. For the Platform Developer 1 exam, focus on understanding the source-driven development model, the role of scratch orgs and the Dev Hub, the project structure and key configuration files, and the difference between source-tracked operations (push/pull) and traditional deployment operations (deploy/retrieve). Combined with knowledge of authorization methods and CI/CD best practices, you will be well-prepared to answer any exam questions on this topic.