Given a scenario, know how and when to use the Salesforce Developer tools such as Salesforce DX, Salesforce CLI, and Developer Console.

After studying this topic, you should be able to:

  • Describe what Salesforce DX is and its role in the Salesforce application lifecycle management
  • Describe the tools such as Salesforce CLI, Visual Studio Code, Developer Console and others
  • Determine when to use these developer tools

Table of Contents

  • Introduction
  • Salesforce DX
  • Salesforce CLI
  • Salesforce Extension Pack for VS Code
  • Developer Console
  • Workbench
  • Use Cases

Introduction

  • Section provides an overview of Salesforce DX, its key characteristics, and how to to develop applications on Lightning Platform with it
  • Salesforce Developer tools that Salesforce DX promotes include Salesforce CLI, Salesforce Extensions for VS Code
  • Other tools like Developer Console and Workbench are also discussed
  • Overview of Developer Tools
    • Setup Menu
      • Create and edit Apex classes, triggers, and Visualforce pages
      • Manage trace flags and view, download, or delete debug logs
      • Run Apex unit tests and check code coverage
      • Access and modify the schema, and create/refresh sandboxes
    • Developer Console
      • Write, execute and test Apex and Visualforce code
      • Execute SOQL and SOSL queries using Query Editor
      • Set and view checkpoints to identify sources of error
      • Utilize debug logs for debugging Apex code
    • Workbench
      • Query, insert, update and delete Salesforce data
      • Execute SOQL and SOSL queries for Salesforce data
      • Deploy metadata components using zip file
      • Test and troubleshoot Force.com APIs
    • Salesforce CLI
      • Synchronize source to and from scratch orgs
      • Create and manage orgs and import/export data
      • Create and execute tests and create/install packages
    • Salesforce Extensions Pack
      • Work on a Salesforce DX project using Visual Studio Code
      • Develop Apex/Visualforce projects or Lightning Components
      • Perform Salesforce CLI commands through the IDE
    • Visual Studio Code
      • Create and manage Salesforce development projects
      • Create and edit code using the code editor
      • Execute SOQL and anonymous Apex
      • Retrieve and deploy metadata components
    • Developer Edition Orgs
      • Allows use of the Lightning Platform and APIs
      • Can be integrate with other applications,
      • Can be used to develop new tools and applications
      • Provides access to many features available in Enterprise Edition
    • Scratch Orgs
      • Develop a new project or feature branch
      • Test a new feature or run automated testing
      • Perform development tasks directly in an org
    • Version Control System
      • Track code & metadata changes in a repository
      • Facilitate in managing package releases, updates or fixes
      • Enable developers to collaborate on team projects

Salesforce DX

  • Salesforce DX introduces a new way of developing and managing applications on the Lightning Platform throughout the entire life cycle of an application. Key characteristics:
    • Source-Driven: It promotes source-driven development, team collaboration, and custom app development agility in Salesforce
    • Developer Tools: Tools that developers are already familiar with such as ANT or third-party IDEs can be used in Salesforce DX
    • Source of Truth: Source code and metadata is stored outside the org and managed using a version control system such as GIT
    • Salesforce CLI: Salesforce command-line interface (CLI) is used for development, continuous integration, and delivery
    • Scratch Orgs: Scratch orgs are used for development and help facilitate automated testing and continuous integration
    • Code Editor: Enable any IDE or text editor to work with Salesforce CLI and version control system
    • Editor Plugin: Salesforce Extensions for VS Code is used for development and working with scratch orgs, Apex, Lightning components, and Visualforce
  • Salesforce DX and Packaging: Managed and unmanaged packages belong to first-generation packaging. Salesforce DX introduced second-generation packaging which offers a new approach to packaging and deploying applications
    • 1st-Gen Packaging (1GP): Managed packages and unmanaged packages are created and deployed from an org
    • 2nd-Gen Packaging (2GP): Managed 2G packages and unlocked packages are created and deployed from a local machine or repository
      • Note: Managed 2GPs are used for distributing apps on AppExchange. Unlocked packages provide more features compared to unmanaged packages such as version upgrades/downgrades, destructive changes, and more
  • Sample Application Development Flow in Salesforce DX
    • In source-driven development, the “source” of truth is the version control system
    • In this setup, packages are deployed from a code repository to the target orgs using Salesforce CLI

  • Environment Setup for Salesforce DX: following configurations are required:
    • Enable Dev Hub: Enable the Developer Hub in the org (requires Production or Developer Edition org) in order to track the number and status of scratch orgs
    • Add Users in Dev Hub: Create additional users in the Dev Hub org to allow members in a team to generate scratch orgs if required
    • Enable 2GP Packaging: Enable Second-Generation Packaging in the org to develop 2GP managed packages if required
    • Install Salesforce CLI: Salesforce CLI must be installed in the local development machine in order to create environments, synchronize code, and execute tests
  • Salesforce DX Project
    • Salesforce DX implements a new project structure to contain org metadata, templates, sample data, and tests
    • A Salesforce DX Project is a local directory structure of your metadata in source format
    • Project Files: Project files should be stored in a version control system and retrieved during development. They may also contain:
      • Configuration files for creating scratch orgs
      • Data to be loaded into orgs for development or testing
      • Tests that are created to validate a package
    • To set up a Salesforce DX project, either of the following can be performed:
      • Use the sample repository on GitHub: Clone the sample GitHub repo provided by Salesforce as a starting point
      • Create a Salesforce DX project from existing source: Start with an existing Salesforce app to create a Salesforce DX project and retrieve existing source code
      • Set up a fresh Salesforce DX project: Create an app on the Lightning Platform from scratch using a Salesforce DX project
  • Example Salesforce DX Project

  • What are Scratch Orgs: Scratch orgs are temporary configurable Salesforce environments that can be quickly generated using Salesforce CLI to be used as a personal development environment, or for the following use cases:
    • Starting a new project
    • Starting a new feature branch
    • Starting automated testing
    • Testing a new feature
    • Performing development tasks directly in an org
    • Starting from “scratch” with a fresh new org
  • Scratch Org Configuration: Salesforce DX enables developers to create an org with a specific edition and set of features that can be replicated by using scratch orgs
    • Edition/Features: Scratch orgs can be configured with different Salesforce editions and with just the features and preferences that are needed
    • Definition File: Scratch org configuration can be shared to allow developers replicate each other’s scratch orgs to ensure that a team is working on the “same” org
  • Scratch Orgs vs Sandbox Orgs: While source development use cases should be performed in scratch orgs, release and deployment testing should be performed sandbox orgs. Here are the other main differences:
    • Limited: Scratch orgs have limited storage size and (short) life span
    • Purpose: Scratch orgs are not designed to replace sand box orgs
    • Development: Scratch orgs are intended for developing customizations in modules or packages
    • Testing: Scratch orgs are designed for testing an individual module or package
    • Use Cases: Sandbox orgs are used for user acceptance testing, as a staging environment, and for continuous delivery testing

Salesforce CLI

  • What is Salesforce CLI?
    • Salesforce CLI is a command-line interface which can be used in every phase of the application development life-cycle. It is capable of the following:
      • Authorizing target orgs
      • Creating and managing Salesforce DX projects
      • Creating and deleting scratch orgs
      • Importing and exporting test data
      • Retrieving and deploying metadata
      • Running and automating unit tests
  • Salesforce CLI Capabilities: combines capabilities across several Salesforce APIs and tools and enables development tasks from all the important APIs available in one place:
    • Metadata API
    • Tooling API
    • Data (SOAP) API
    • Ant Migration Tool
  • Salesforce CLI Commands: Following lists some operations where Salesforce CLI can be used to perform them
    • Authorize a default Dev Hub org and assign an alias:
      • sfdx force:auth:web:login --setdefaultdevhubusername --setalias MyDevHub
    • Create a scratch org using a definition file, set the default username, and assign an alias:
      • sfdx force:org:create --setdefaultusername -f config/project-scratch-def.json --setalias my-scratch-org
    • Push source and tests, located in the force-app directory, to the scratch org:
      • sfdx force:source:push
    • Run Apex tests:
      • sfdx force:apex:test:run --resultformat human
    • Open the scratch org and view the pushed metadata:
      • sfdx force:org:open
    • Generate your project with a default manifest (package.xml) file:
      • force:project:create -n MyProject --manifest
    • Retrieve metadata in source format from an org:
      • sfdx force:source:retrieve --sourcepath {target filename}
    • Deploy metadata in source format to an org:
      • sfdx force:source:deploy --sourcepath {target filename}
    • Export org data into a set of JSON files:
      • sfdx force:data:tree:export --query "SELECT Id, Name FROM Property__c" --prefix export-demo --outputdir sfdx-out --plan
    • Track changes between local project and sandbox org:
      • sfdx force:source:status -u {username}
      • (Requires the “Enable Source Tracking in Developer and Developer Pro Sandboxes” setting in the production org)
  • Example Development Environment: following illustrates an example development environment using Salesforce DX:

Salesforce Extension Pack for VS Code

  • Visual Studio Code: Visual Studio Code (VS Code) is an integrated development environment (IDE) that can be used to build custom applications or features and deploy metadata to Salesforce orgs
    • Consists of features such as:
      • Code editor
      • Build automation tools
      • Debugger
      • Intelligent code completion
    • Components that Visual Studio Code can be used to create and edit:
      • Apex Classes and Triggers
      • Visualforce
      • Lightning Aura Components
      • Lightning Web Components
  • Visual Studio Code Interface:
    • A: Editor - code editor or main area for editing files and writing code
    • B: Side Bar - Contains different views like the Explorer to assist while working on a project
    • C: Status Bar - Shows information about the opened project and the files that are being edited
    • D: Activity Bar - Enables switching between views such as explorer, search, extensions, etc
    • E: Panels - Contains panels for output or debug information, errors, and warnings, or an integrated terminal

  • Salesforce Extension Pack: Salesforce Extension pack is built on top of Salesforce CLI and Visual Studio Code, transforming the editor into an IDE for Salesforce application development.
    • Salesforce Extension pack installs the following:
      • Salesforce CLI Integration: provides integration with Salesforce CLI to run commands from the editor
      • Apex: provides code-editing features for the Apex programming language
      • Apex Replay Debugger: provides replay of Apex execution from Apex Debug Log
      • Aura components: provides code-editing features for Aura components
      • Lightning Web Components: provides code-editing features for LWCs
      • Visualforce provides syntax highlighting for the Visualforce framework
  • Salesforce Extension pack includes tools used in developing and deploying applications on the Salesforce platform

  • Salesforce CLI commands can be executed using the integrated terminal or via point-and-click options available in the UI

  • Salesforce CLI commands can be executed from Visual Studio Code using the command palette

  • Salesforce CLI commands can also be executed by directly entering the commands on the command line interface that is available in the terminal panel

Developer Console

  • The Developer Console is a web-based IDE connected to one org and one-stop solution for a variety of development tasks:
    • Browser: The Developer Console is accessed via the browser and used to implement changes effective immediately and requires no software installation
    • Support: can be used to write Apex, SOQL/SOSL, Visualforce, and Aura components, it cannot be used to build Lightning web components
  • Developer Console can be used for:
    • Writing source code such as triggers, classes, Visualforce, and Aura components
    • Executing anonymous Apex code
    • Testing Apex code or building unit tests
    • Executing SOQL and SOSL queries
    • Debugging using the debug log
    • Setting and viewing checkpoints
    • Viewing objects and other resources
    • Writing and Editing Source Code
      • Classes & Triggers: Apex classes and triggers can be viewed, edited, or created in the Developer Console
      • Visualforce & Aura: It can also be used to write and test Visualforce applications or Aura components
      • Tabbed Files: The source code editor allows opening multiple files and use tabs to switch between the different files
      • Auto-complete: The source code editor includes an auto-complete feature for Apex and Visualforce code
    • Executing Anonymous code
      • Anonymous Window: The Open Execute Anonymous Window allows one to execute Apex code as a way to evaluate and generate debug logs that cover specific application logic
      • Open Log Checkbox: The Open Log option in the anonymous window can be selected so that the log automatically opens in the Log Inspector after code execution
      • Rerun Last Execution: The code that was last executed can be run again by clicking on the Execute Last menu option
  • Developer Console: The anonymous window can be opened from the Debug menu in Developer Console

  • Following shows sample anonymous code executed and having its log automatically displayed in the Execution Log panel

  • Anonymous Block Considerations
    • Classes & Interfaces: Classes and interfaces can be defined in an anonymous block
    • Methods & Exceptions: Methods and exceptions can be defined in an anonymous block
    • Static Keyword: But, an anonymous block cannot contain methods defined as static
    • Virtual By Default: A class or interface (custom type) defined in an anonymous block is considered virtual by default
    • User Context: Code always executes in the context of the current user and respects user permissions and sharing rules
    • Database Commit: Any record changes performed are committed to the database as long as no error was encountered. Otherwise, the changes are rolled back
    • Local Scope: Code executed in the anonymous block will always operate in the local scope
    • Temporary: Anonymous code is not saved in the org like Apex classes or triggers.
    • Use Cases: Anonymous code can be used for quickly running code snippets, evaluating code logic, or executing ad hoc scripts
    • Run Options: Anonymous code can also be run using Visual Studio Code via Salesforce CLI, SOAP API, or Tooling API (REST)
  • Developer Console: provides several tools and features for testing Apex code:
    • Unit Tests: Apex tests can be created and run to verify whether a particular piece of code is working
    • Test Suites: Test suites can be created using suite manager to run several tests together
    • Run All Tests: All tests can be run using the Run All option that is available in the Test menu
  • When running a test additional settings can be specified such as:
    • number of failures to allow and
    • skipping code coverage

  • Developer console can be used to write database queries and access results
    • SOQL and SOSL: can be edited and executed using the Query Editor in the Developer Console
    • Query Results: can be displayed in a grid which allows one to open, create, update and delete records

  • Checkpoints are set on specific lines of code to analyze code behavior or identify sources of errors in Apex code:
    • Object Snapshot: Checkpoints display a snapshot of the state of objects in memory at the time the checkpoint was reached
    • Checkpoint Tab: The Developer Console includes a checkpoint tab which displays a list of saved checkpoints
    • Inspect Behavior: Code can be inspected at a specific point to understand in detail how to improve it
    • Checkpoint Info: It will include the following information: Namespace, Class, Line and Time
  • Checkpoints tab displays the saved checkpoints and contains other information that are helpful for debugging code

  • Debug logs can be accessed in Developer Console
    • Logs Tab: The Logs tab in the Developer Console is used to open and inspect debug logs
    • Log Categories: The debug logs include database events, Apex processing, workflow, validation logic, and more
    • Event Details: Log inspector shows the source of an operation, what triggered the operation, and what occurred afterward
  • The Logs tab contains all the debug logs that are generated

Workbench

  • Workbench is a web-based application developed by Salesforce that can be used to access org metadata and data
    • Possible Operations:
      • Can query, insert, update and delete Salesforce data
      • Can be used to interact with the REST API
      • Can execute SOQL and SOSL queries
      • Can describe Salesforce metadata and data
      • Can deploy metadata components to an org using a zip file
      • Can be used to retrieve Salesforce metadata
      • Can test and troubleshoot Force.com APIs such as customizable SOAP headers
      • Can be used to perform the operations in sandbox or production environments
  • The following shows a SOQL query that is performed using Workbench. Query results are displayed below the query editor

  • The retrieve page in Workbench can be used to retrieve metadata or configuration data from Salesforce

  • Workbench can be used for querying Salesforce data on an authenticated org

Use Cases

Reference FoF Slides