Understand Source-Driven Development
Learning Objectives
- Describe the purpose of a Salesforce DX project.
- Describe how the package development model helps you manage change tracking.
- Explain the role of scratch orgs in the development process.
Think Inside the Box
As we learned in the previous unit, you decide which tools to use. You can use your favorite text editor along with Salesforce CLI or Salesforce Extensions for VS Code. You select which VCS you want to use. If using Salesforce Extensions for VS Code, we offer several extensions to facilitate development and testing.
As your company grows, you can experience challenges around coordinating and testing changes across projects using change sets. Package development addresses these challenges directly. Your source is organized into packages based on a group of features or customizations you want to deliver together. The Salesforce DX project reflects this package-based approach to organizing your source.
What Is a Salesforce DX Project?
A Salesforce DX project is a local directory structure of your metadata in source format. It lets you develop and test with Salesforce DX tooling.
It contains configuration files for creating scratch orgs. It can contain data to be loaded into orgs for development or testing. It also contains tests that you rely on to validate your package.
When you use the CLI to create a new Salesforce DX project, it creates the project directory structure for you. When creating a project from scratch, many things are created for you. We create a base project configuration file. We create sample scratch definition files and directories for your tests and sample data sets. We also create a default “package” directory for your package source.
Remember, a package is a group of related code and customizations. You can test a package independently from other components in your org. You can release a package independently as well. The metadata components within a package can live in only one package at a time in the installed org.
At a minimum, the project manages the source for one package. That being said, if multiple packages get built and released together, you can organize these packages into a single DX project. Each of your packages aligns to a package directory defined in the project configuration file.
How Scratch Orgs Rock the Development Process
Scratch orgs, built from your source and metadata, make it easy for you to build your app consistently over and over again. You only work with the source and metadata for a specific project. There’s no need to copy over things you don’t need (and frankly, we don’t recommend it). And because scratch orgs are temporary Salesforce environments, you can quickly spin up a new scratch org for each package or development project.
Once your VCS is set up, and your source is organized into packages, you’re ready to start a new development project. Open up your favorite IDE or text editor, then add or modify your source code. When you’re ready to see your changes in an org, you can create a scratch org.
After you create a scratch org, you still have some setup tasks to complete. You push all source from the project to the scratch org, set up permissions, and create or load any test data that your package requires.
While the IDE or text editor is available for programmatic (code-based) development, you can use the scratch org for declarative (point-and-click) development. This process is similar to what you do in your sandbox or production org. What’s different in the source-driven model is that you synchronize any development you did in the scratch org with your local project. This synchronization lets you commit changes made in the Setup pages alongside changes made in your local IDE.
Before you commit to your version control system, be sure to run tests. You can either use the same scratch org to run tests, or spin up another specifically for testing before you commit your source. This same pattern of spinning up scratch orgs for testing is a key part of an automated continuous integration system.
Keep Your Project and Scratch Org in Sync
A key feature of Salesforce DX is that you can easily keep your project and scratch org in sync. So you can put away those sticky notes! You no longer have to jot down what you changed in your local file system, IDE, or editor, or what you changed in your org.
Salesforce DX tracks any change you make locally in the project and any changes you have made in your scratch org.
Before you push source changes to the scratch org, or pull changes to your local project, you can view a list changes you’ve made. That’s the power of the Salesforce CLI in action.
$ sfdx force:source:status STATE FULL NAME TYPE PROJECT PATH ───── ────────── ────────── ───────────────────────────────── Local Deleted MyClass ApexClass /MyClass.cls-meta.xml Local Deleted MyClass ApexClass /MyClass.cls.xml Local Add OtherClass ApexClass /OtherClass.cls-meta.xml Local Add OtherClass ApexClass /OtherClass.cls.xml Local Add Event QuickAction /Event.quickAction-meta.xml Remote Deleted TempClass ApexClass /TempClass.cls-meta.xml Remote Deleted TempClass ApexClass /TempClass.cls.xml Remote Changed (Conflict) NewClass ApexClass /NewClass.cls-meta.xml Remote Changed (Conflict) NewClass ApexClass /NewClass.cls.xml
Within a production org, source files can be enormous, with a footprint larger than Sasquatch’s. Think about all the custom objects, custom labels, and static resources that comprise an org, to name a few.
DX project format breaks down large source files to make them more digestible and easier to manage with a version control system. For example, Salesforce DX transforms custom objects and custom object translations into multiple files and directories. This source structure makes it much easier to find what you want to change or update. Smaller files in source control mean fewer merge conflicts during team development. Say bye-bye to messy merges!
Once you’re done developing, always commit your changes back into the VCS repo. Now you’re ready to test, build, and release with Salesforce DX.
