Introducing Salesforce DX

Throughout this book, we will be using the Salesforce DX tools. Salesforce provides tools for developers to perform many development and time-saving tasks, such as creating developer environments (known as scratch orgs), creating projects, synchronizing code with source control, creating and managing packages, and much more. In fact, it optimizes and helps you automate the entire application life cycle (ALM) process for your application and package. Throughout this book, you will learn key aspects of this process, starting in this chapter.

We will dive straight into using Salesforce’s command line interface (CLI) along with an integrated development environment (IDE), Microsoft Visual Studio Code (VSCode), for which Salesforce has also created many useful extensions. At the time of publication, Salesforce announced a beta release of Code Builder, which allows you to use Salesforce DX via VSCode from your browser without requiring any location installation, which not only speeds up getting started but also avoids hitting any corporate workstation restrictions you might encounter. You do not need to be an expert in Salesforce DX to complete this book but I do recommend you take the time to complete the basic Trailhead trails, Build Apps Together with Package Development: https://trailhead.salesforce.com/en/content/learn/trails/sfdx_get_started.

Salesforce DX brings with it the second generation of packaging technology for ISVs as well as Enterprise customers building on the Salesforce Platform; this is known as “2GP” for short. Previous editions of this book used the first generation technology (1GP). If you were to compare the experience between the two technologies, you would see that the package creation process using 2GP is now fully automated through the CLI and requires no UI interaction. This is also very advantageous in respect of building further automation around your release pipeline, which will be covered in Chapter 14, Source Control and Continuous Integration. This book focuses on creating new second-generation managed and second-generation unlocked packages. It does not focus on migrating between 1GP and 2GP for existing managed packages.

You can read more about 1GP and 2GP managed packages at https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_build_and_release_your_app.htm.

You can read more about 2GP unlocked packages at https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_intro.htm.

Introducing the new Salesforce Task Driven CLI

Back in 2017, Salesforce introduced its first CLI tool and the commands were executed with sfdx. Since then the Salesforce portfolio of products has grown, and so Salesforce has started a journey to unify all of its developer tools under one experience. The first part of this is a new sf CLI that provides an easy-to-navigate task-driven naming convention with an improved interactive and defaulting experience that requires less memorization of parameters. New platform features such as Salesforce Functions (covered later) are adopting this approach immediately, so related commands are only available through this new sf CLI. This book will thus use a mixture of these new commands and existing ones. Some commands have been re-envisioned in this new CLI, such as creating orgs and deploying to them.

You do not need to do anything to install this new sf CLI experience, as it is bundled with the main sfdx CLI install, and existing sfdx CLI commands, including many used in this book, will all still work fine. Just make sure, as always, you are running the latest CLI by performing the command sfdx –update. These new CLI commands are accessible from a new sf executable, and at the time of writing only cover a subset of the functionality of the sfdx executable – but in the future, will continue to extend to cover those from other Salesforce products. For now, you can use both sets of commands together.

Below you can see the navigation panel for the CLI documentation; you can immediately see the difference in how commands are structured by task versus feature. On the left is the new sf command’s top-level structure, and on the right, the existing sfdx structure:

Figure 1.1: Side-by-side comparison of sf and sfdx structure

In Figure 1.1 you can see the organization of the new sf commands is oriented around the tasks developers perform, while sfdx commands are organized by features. For example, all commands to manage and interact with environments (such as your Salesforce orgs) are under the env namespace, and ways to deploy to environments are under the deploy namespace.