Increase Productivity with Integrated Tools

Learning Objectives

After completing this unit, you’ll be able to:

Describe the ways in which the Salesforce Command Line Interface (CLI) can enhance productivity.
Describe the role of version control systems, scratch orgs, and sandbox orgs in the package development model.
Identify when it’s appropriate to use scratch orgs vs. sandboxes.

Existing Tools, New Tools, Your Tools

We acknowledge that there’s a lot of innovative open-source software out there. And so one of our guiding principles is to support open standards regarding development tools. We want to provide an infrastructure that enables you to use the tool chain you’re familiar with. And we want to provide a suggested set of tools that you can use if you don’t have anything already in use.

Salesforce Command Line Interface

One tool we provide is the flexible and powerful Salesforce Command Line Interface (CLI). You can use the CLI to manage the package development process from the command line.

Salesforce CLI combines many of the capabilities from across several Salesforce APIs, such as Metadata API, the Tooling API, and the Data (SOAP) API. With the new and improved CLI, all your development tasks from all the important APIs are available in one place. You can script everything from the creation of orgs to the import and export of data–everything required to manage the full development lifecycle. Think about all the cool scripts you can create to make repetitive development tasks easier!

And it does the dishes, too! (No, not really, but wouldn’t that be great?)

computer screens with CLI commands

Salesforce CLI is an equal-opportunity productivity enhancer:

Developers can use it to manage their DX projects, create scratch orgs, deploy and retrieve metadata to and from a scratch org, and run unit tests.
DevOps can use it as part of build automation scripts: to create and access environments, to deploy source, to install packages, and to run tests.

Code Builder

With Code Builder, you get a powerful integrated development environment that’s created especially for Salesforce development. The included extensions provide:

Functionality to interact with the Salesforce CLI
Functionality to create projects for your package development
Access to the Apex Language Server for syntax highlighting and code completion
Support for Lightning component bundles
Support for Apex and replay debuggers
Generative AI to write, test, debug, and refactor code

It’s also pre-integrated with Git but can work with other version control systems.

Prefer to work in a local development environment, such as Visual Studio Code? No problem, Salesforce provides the same extensions for VS Code as well.

Version Control System

A VCS is the heart of source-driven development. You need a VCS to manage and version your source to take full advantage of what the new tools and package development offer.

So if you’re not currently using a VCS, how do you begin this journey?

You are probably just starting out with packaging as well. So let’s discuss the base case. Start out by planning to create just one package to get an understanding of the process. You have one DX project for the development of that package with a corresponding VCS repository for that package project. Soon, you’ll become more comfortable with the package development lifecycle and DX project structure. Then, you can consider new ways of designing your package projects and organizing them across one or more VCS repositories.

Scratch Orgs

Designed to be ephemeral and easily recreated, scratch orgs are dedicated and configurable Salesforce environments that you can quickly spin up for many different purposes.

Are you tired of other kids playing in your sandbox? No more sand in your eyes when you use scratch orgs as part of the development and testing process. Scratch orgs can be your own personal development environment, or you can create headless scratch orgs for automated tests. You can spin up a new scratch org when you want to:

Start a new project.
Start a new feature branch.
Test a new feature.
Start automated testing.
Perform development tasks directly in an org.
Start from “scratch” with a fresh new org.

You can configure the scratch org with different Salesforce editions and with just the features and preferences you want. And you can share the scratch org configuration file with other team members. That way, you all have the same basic org in which to do your development.

So, Just What Is the Difference Between a Scratch Org and a Sandbox?

Now that you understand the use cases for scratch orgs, let’s step back for a minute and discuss what scratch orgs aren’t.

Scratch orgs don’t have the capacity to contain the entire happy soup of metadata contained in your production org. Also, they weren’t meant to replace sandboxes either. When you begin to analyze what pieces of metadata you want to deploy to a scratch org, ask yourself if all that source is required for your specific project.

For example:

Are all the customizations related to a single application or the extension of CRM?
Do the customizations represent lots of different apps or projects?

If you answered “yes” to the second question, think about how you can break those bits into packages. You would create a separate scratch org to test each of these individual modules. At some point later in the development lifecycle, you’d deploy the separate packages to a sandbox for final testing and staging.

Sandboxes Still Play an Important Role

As much as we think scratch orgs are going to rock your world and increase your productivity, sandboxes are still an important part of the package development lifecycle. You’ll still use them as targets/destinations for testing the installation of the package version you created. Once installed, you continue to use them for user acceptance testing, as a staging environment, and for continuous delivery testing.

Align source development use cases to your scratch orgs, and align release and deployment testing to your sandboxes.

도움말 검색

더 알아보기