Salesforce DX allows you to tailor the scratch org configuration to ensure that the resulting org is of a specific org type (for example, Professional or Enterprise), as well as having various features enabled (for example, Chatter or Multi-Currency). This is intended to allow developers to develop and test an application in an environment as close as possible to that of the target customer.
Here is a reminder of what this might look like in a scratch org configuration file:
{
"orgName": "FormulaForce App Testing with Multi Currency",
"edition": "Enterprise",
"features": ["MultiCurrency"]
}
In addition to the configuration of the org type and features, there are two other considerations that impact how the code runs once it is in its packaged form. These are the namespace and ancestry configurations. Configuring these is critical to ensuring you avoid namespace-related bugs or changes that could break your API contract from previous package versions. Finding these at this stage avoids delays later in the development cycle, or even customer issues once the application reaches your customers' orgs.
As a reminder, the namespace configuration goes into the sfdx-project.json file and uses the namespace configuration. It mainly ensures that, if you are writing code that dynamically instantiates classes or components, it is namespace-aware. You can see an example of this in the following code:
{
"packageDirectories": [
{
"path": "force-app",
"default": true
}
],
"namespace": "fforce",
"sfdcLoginUrl": "https://login.salesforce.com",
"sourceApiVersion": "45.0"
}
Careful use of the ancestryId setting ensures that, if you are making changes in a scratch org, the platform has the ability to inform you of changes that would break the backward compatibility of your next release; for example, deleting a field or object or changing the method signature of an Apex class method marked as global. Finding this out during development is much less stressful than doing so further down the road! The following sample shows how the ancestorId setting can be used:
{
"packageDirectories": [
{
"path": "force-app",
"package": "FormulaForce App",
"versionName": "ver 0.1",
"versionNumber": "0.1.0.NEXT",
"ancestorId": "05i6A000000XZLyQAO",
"default": true
}
],
"namespace": "fforce",
"sfdcLoginUrl": "https://login.salesforce.com",
"sourceApiVersion": "45.0",
"packageAliases": {
"FormulaForce App": "0Ho6A000000CaVxSAK",
"FormulaForce [email protected]": "04t6A0000038K3GQAU"
}
}
The preceding JSON configuration shows how the ancestorId configuration can be used.
That being said, it can be worth considering the creation of a beta package from a stable build of your code at various intervals throughout your release development cycles. This grants you additional sanity and smoke testing ahead of your final upload process. The uploading and installation of packages can be automated via the Tooling and Metadata APIs.
In this chapter, we are going to create a Git-based source control repository using a free GitHub service. This chapter's sample code will be uploaded into that so we can explore working with source control to allow the tracking and audibility of changes in a more robust way than is permitted by simply storing your source files on your disk. We will then use this repository to populate new scratch orgs, make some changes, and commit those changes back to the repository. This is known as the developer workflow.