.ultrageek. Computers, Music, and Thoughts

13Jan/200

SFDX Command Process Quick Reference

There are some great resources for Salesforce DX but it can be confusing knowing which commands align with the functionality you're trying to execute. Below are some commands and examples of a basic workflow for setting up DX, pulling data from a sandbox using a change set instead of creating a package.xml, and then pushing it to a scratch org. This workflow assumes you have a developer org and have enabled it for scratch orgs.

The more you work with this the easier it gets. I would also recommend creating alias's for common commands like listing scratch orgs, creating scratch orgs, and opening.

Authenticate an Org as your ‘Dev Hub’

sfdx force:auth:web:login -d -a DevHub -r https://login.salesforce.com

Where DevHub is your alias for your ‘Dev Hub’. Note that it is case sensitive so devhub is not the same as DevHub

Create the Project Directory

Create the Project Directory from the Git Repo

From the parent directory run the following command. The last name is the name of the directory that will be created.

git clone https://github.com/Account_Name/Repo_Name.git Repo_Name_Todays_Date

If you do not specify the directory it will create a directory as the name of the repo. Dealers choice as to whether to use a custom or not. For testing it is easier to specify the custom directory and then delete it.

Create a scratch org

sfdx force:org:create -s -f config/project-scratch-def.json -v DevHub

If you do not have a config file do a:

sfdx force:project:create -n project_Name --template standard

This will create a directory named 'project_Name' with all the standard files and directories.

You can also create a scratch without a file:

sfdx force:org:create edition=Developer -a scratch_Name -s -v DevHub

List all Org’s

sfdx force:org:list --all

Pull Package Data using the Metadata API

sfdx force:mdapi:retrieve -u Sandbox_Alias -p "Package Template" -r ./temp

The -u is either the user or the alias to the sandbox that you would see in the list command. To create an alias you can do:

sfdx force:alias:set userAlias=some_User@somehost.com

I like to keep mine small with a project or org prefix and a number to keep track.

To add a username to the list for an org that already exists like a sandbox:

sfdx force:auth:web:login -d -a alias_Name -r https://test.salesforce.com

Where alias_Name is what you want to nickname the org connection.

Convert data to DX format

sfdx force:mdapi:convert -r ./temp

Push the data to the Scratch Org

sfdx force:source:push -u Scratch_Org_Alias

Assign the Permission Set

sfdx force:user:permset:assign -n Unlocked_Package_Permission_Set

Create the Package:

sfdx force:package:create -n Unlocked_Package -e -v DevHub -t Unlocked -r force-app

Create the Version

On Dev Org’s you can only do this 5 times in a 24 hours period even if the package fails

sfdx force:package:version:create -p “Unlocked_Package" -d force-app -k test1234 --wait 10 -v DevHub

Make sure you do not have your sfdx-package.json file open in a file edit so that sfdx will update it with the latest packageAlias.

Push to Org

sfdx force:package:install --wait 10 --publishwait 10 --package "Unlocked_Package@1.1.0-1" -r -u Scratch_Org_Alias

You are pushing the latest version of the package so look in your sfdx-package.json for the latest version name or id and use that. You can use the following commands if your sfdx-package.json file did not update with the latest alias.

sfdx force:package:version:list -v DevHub

Updating the Package Version

When you have made changes and need to update the package use the 'Create the Version' section to update the package but in order to update the version number you will need to update your sfdx-package.json file and increment the versionNumber.

There's also a great trailhead that steps you through almost all of this: Quick Start: Unlocked Packages

List of DX Links

 

6Jan/200

Using SFDX to execute apex against a scratch org

Been doing a lot of SFDX lately and in automating the deployment, testing, and validation of unlocked packages I have found that the documentation around sfdx force:apex:execute is a bit lacking. There are a couple things that got missed in the documentation that you need to know to get this working:

  1. The file format is just like what you would type in to anonymous console except that you cannot call other methods and classes, it seems everything needs to reside in the script file. If you are using this script to create data and already have a nice test factory going...you will have to move all that code over to the script file.
  2. You can store this script anywhere but the proper 'salesforce' spot for storing these files is the ./scripts/apex folder. If you do a 'sfdx force:project:create --projectname ProjectName' it will create that folder with the standard folder structure for you with a couple example. I mention this only because these folders will not get created if you just create a project under VS Code.

Here's the command I use:

sfdx force:apex:execute --loglevel debug -u scratch_Org_Name -f ./scripts/apex/install.apex

And the official documentation URL: https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_apex.htm#cli_reference_execute