To get the maximum benefit out of sfpowerscripts, you need a good understanding of GIT, Salesforce DX and packaging in general. Here are some links to get you started
Package-based development is the preferred workflow of [email protected], where scratch orgs are used as a development environment, CI environment for validating changes, and internally by Salesforce to create unlocked packages. To enable these use cases, Dev Hub (Setup -> Dev Hub -> Enable Dev Hub) and Unlocked Packages (Setup -> Dev Hub -> Enable Unlocked Packages and Second-Generation Managed Packages ) must be enabled in the production environment.
It is best practice to have a service user execute tasks in the CICD, rather than using a personal user account. The service user should be created as a System Administrator, so that it has permission to manage scratch orgs and unlocked packages. A group email address may be assigned to the service user, if controlled by multiple people in a team.
The preferred method of authenticating to Dev Hub for the CI service user is through SFDX Auth URL. This method of authentication is essential when creating scratch org pools.
To retrieve the SFDX Auth URL:
Login to Dev Hub with the CI service user, using web auth:
sfdx force:auth:web:login -r <your-domain-url>
force:org:display command with the
sfdx force:org:display -u CIServiceUser –verbose –json
Copy the value of the SFDX Auth URL field into CICD secrets
For more information on SFDX Auth URL, visit the Salesforce documentation.
The scratch org pooling feature and ability to skip repeated deployments of the same package version, are dependent on the additional metadata contained in prerequisite packages. The packages have been created on an Accenture org and their Subscriber Package Version Id’s are publicly available; however, you may wish to create the packages on your own Dev Hub, from the source code.
SfpowerscriptsArtifact__c custom setting that has records of the sfpowerscripts artifacts that have been installed in the org. Allows for optimised deployments by only deploying artifacts that are not already on the org.
scratch org pooling (org-dependent)
Adds additional fields to the ScratchOrgInfo object to allow for the creation of scratch org pools. Utilised by the
sfdx sfpowerscripts:orchestrator:prepare command to create CI scratch orgs.
Create a new project from the prerequisite package's directory
Authenticate to Dev Hub in your terminal
sfdx force:auth:web:login -r https://login.salesforce.com -a myDevHub
Create the package in Dev Hub
sfdx force:package:create -n packageName -r path/to/package -t Unlocked -v myDevHub
The package name and path are defined in the sfdx-project.json. Running this command will add the package 0H ID as a package alias to the sfdx-project.json.
Note: The scratch-org pool package must be created as an org-dependent package by passing the additional flag
Create a new version of the package in Dev Hub
sfdx force:package:version:create -p packageAlias -f config/project-scratch-def.json -v myDevHub -w 60 -x -c
This command will create a subscriber package version Id in the Dev Hub, which can be used to install the package in orgs on the release train.
Promote the package version in Dev Hub
sfdx force:package:version:promote -p 04t** -v myDevHub
Install the package in orgs on the release train
sfdx force:package:install -p subscriberPackageVersionId -u myOrg -w 60
Note: The scratch-org pool package should only be installed in production and not in sandboxes
Push the changes to the sfdx-project.json, to your hosted git repository
For developers to access scratch orgs created by the CI service user, for their local development, a sharing setting needs to be created on the ScratchOrgInfo object. The sharing setting should grant read/write access to the ScratchOrgInfo records owned by a public group consisting of the CI service user and a public group consisting of the developer users.
Create two public groups
CI Users (Admin users/ CI users who creates scratch orgs in pool)
Developers (developers who are allowed to fetch scratch orgs from pool),
Then create a sharing rule that grant read/write access to the ScratchOrgInfos records owned by the CI Users to Developers
The developers must also have object-level and FLS permissions on the ScratchOrgInfo object. One way to achieve this is to assign a permission set that has Read, Create, Edit and Delete access on ScratchOrgInfos, as well as Read and Edit access to the custom fields used for scratch org pooling:
sfdx-cli : sfpowerscripts is a SFDX CLI extension. Hence require the latest version of sfdx-cli installed in your CI/CD agents
$ npm i sfdx-cli --global
sfpowerkit : sfdx plugin that has variety of helper commands, sfpowerscripts uses sfpowerkit for various functionality such as reconciling profiles.
$ echo'y' | sfdx plugins:install sfpowerkit
sfdmu : sfdx plugin that helps in data migration between orgs or between source to orgs. sfpowerscripts utilizes sfdmu for data package
$ echo'y' | sfdx plugins:install sfdmu
sfpowerscripts: Install the sfpowerscripts sfdx-cli plugin from npm
$ echo'y' | sfdx plugins:install @dxatscale/sfpowerscripts
Alternatively, you could use our docker image and we highly recommend to utilize it.
sfpowerscripts is designed to work with asynchronous pipelines, where CI and CD is separated into two distinct pipelines. This means an artifact repository/registry such as Azure Artifacts, Jfrog Artifactory is essential to store the built artifacts
Metrics should be a key part of your DevOps process. It is through these metrics, one can drive continuous improvement of your delivery process. Almost all commands in sfpowerscripts, is instrumented with StatsD. sfpowerscripts also feature native integration to DataDog, NewRelic and also generates log based metrics which can be integrated to any monitoring service to build dashboards
You will need a StatsD server reachable from your CI/CD agent to report the metrics. Read more on supported metrics and dashboards here.