Understand Source-Driven Development

• 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.

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 Code Builder. You select which VCS you want to use. If using Code Builder, we offer several extensions to facilitate development and testing.

As your company grows, you can experience challenges around coordinating and testing changes across projects. 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.

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.

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 deploy 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.

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 deploy source changes to the scratch org, or retrieve changes to your local project, you can preview the changes you’ve made. That’s the power of the Salesforce CLI in action.

$ sf project deploy preview --target-org my-scratch
No conflicts found.
No files will be deleted.
Will Deploy [2] files.
Type         Fullname        Path
──────────── ─────────────── ──────────────────────────────────────────────────────────────────────────────
ApexClass    WidgetClass     force-app/main/default/classes/WidgetClass.cls-meta.xml
CustomObject WidgetObject__c force-app/main/default/objects/WidgetObject__c/WidgetObject__c.object-meta.xml
No files were ignored. Update your .forceignore file if you want to ignore certain files.

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.