Increase Productivity with Integrated Tools
- 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.
But we also 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.
The CLI combines many of the capabilities from across several Salesforce APIs, such as Metadata API, the Tooling API, and the Data (SOAP) API. It also supports the functionality of the Ant Migration Tool, which allows for scripting of metadata tasks. 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 life cycle. 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?)
The Salesforce CLI is an equal-opportunity productivity enhancer:
- Developers can use it to manage their DX projects, create scratch orgs, push and pull 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.
With Salesforce Extensions for VS (Visual Studio) Code, you get a powerful integrated development environment that’s created especially for custom development on Lightning Platform. These 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 Visualforce pages and components
- Support for interactive and replay debuggers
It’s also pre-integrated with Git but can work with other version control systems.
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 life cycle and DX project structure. Then, you can consider new ways of designing your package projects and organizing them across one or more VCS repositories.
Designed to be ephemeral and easily recreated, scratch orgs are the right stuff. They 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 push to a scratch org, ask yourself if all that source is required for your specific project.
- 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 life cycle, you’d deploy the separate packages to a sandbox for final testing and staging.
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 life cycle. 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.