SFDX Insights with a retrospective on ANT Migration tool

Salesforce Developer Experience Command Line Interface (Salesforce DX CLI)

Salesforce DX was made generally available in the Winter ‘18 release of Salesforce which left most of the developers filled with excitement and curiosity. Although all of us were used to sandbox and production Salesforce orgs, the concept of scratch orgs and artifacts left us confused and eager to learn more. The new feature offers the ability to build together and deliver continuously facilitating rapid testing and development. Good programming practices like source-driven development, packaging metadata and distribution of apps are made seamless.

Where to install CLI: https://developer.salesforce.com/tools/sfdxcli

Secure and Automated Authentication

ANT migration tool requires that we store the usernames and passwords (even security tokens) in a plain text file which is not secure. Security tokens could change often making it hard to track; ANT files need to be updated every time they change.

Salesforce CLI offers three forms of authentication:

1. Browser — Authorizes a Salesforce org by opening a browser so you can log in through salesforce.com

sfdx force:auth:web:login -a TestOrg1

When prompted in the browser that opens, enter your salesforce credentials to permit access. You’ll see a confirmation on the CLI and you can close the browser.

2. JWT flow — Authorizes a Salesforce org using the JSON web token (JWT) flow. This form of authorization is especially helpful for continuous integration (CI) environments that are fully automated and do not require the human interactivity of a web-based flow. In such environments, you need to use the JSON web tokens (JWT) to authorize an org. The JWT-based authorization flow requires an initial generation of a digital certificate followed by the creation of a connected app. These tasks are executed only once. After that, you can authorize the org in a script that runs in your CI environment.

For details, lookup Salesforce JWT flow.

3. SFDX auth URL — SFDX URL is unique with the below format

force://<clientId>:<clientSecret>:<refreshToken>@<instanceUrl> 

It is automatically created by SFDX after you do the web browser login and can be used in the future to log in again without prompting for a password. To view the SFDX URL for the Developer Hub you logged into earlier, run the following command in your command line:

$ sfdx force:org:display -u Hub_Org — verbose

The URL will will start with “force://”. Copy this url and paste it into its own file in your DX project’s main directory called “dev-hub-login.txt”. This text file is all you or your CI tool needs to be able to login again. Please consider encrypting this file with a password.

Alias for Salesforce Orgs

Remember the times when you accidentally pushed the metadata changes to the wrong org (using ANT migration tool) because you forgot to put in the right org url and credentials? — Manual intervention is required to change the source and destination orgs and this can get confusing when moving changes periodically from Dev sandbox -> UAT -> PROD. Wouldn’t having aliases for these orgs be useful?!

Salesforce CLI allows you to set custom aliases for scratch orgs, sandbox and Production Salesforce instances. To make things easier Salesforce CLI allows you to set the alias on Login itself. Just use the -a option on login.

First let’s start by connecting to a Dev Hub (What is a Dev Hub? Sign up for a free 30 day trial Dev Hub account here - https://developer.salesforce.com/promotions/orgs/dx-signup

Configure your first devHub org via the web interface. Run the following command with the alias ‘DevHub’; it represents your production instance and the -d option sets the authenticated org as the default Dev Hub org for scratch org creation. You can chose any name for the alias.

sfdx force:auth:web:login -d -a DevHub

This automatically takes you to a Salesforce login page where you use the devHub credentials you created above, and you will see screen requesting to allow access. On clicking ‘Allow’ go back to the CLI and you’ll see a confirmation saying authorization was successful and your org ID as well and you can close your browser now. We’ve not only configured our DevHub, we’ve also set an alias to it ‘DevHub’. Let’s verify if that the alias was actually set using the force:org:list command. Similarly, we can set alias for any sandbox or scratch orgs and just use the alias as a reference instead of having to update username, password, security token or login URL.

Scratch Orgs

ANT migration tool only lets you interact with sandboxes and the production instances. Don’t you wish there was an org which you can spin up quickly, to try out some functionality? Best use case: to test out managed packages! Or something cool that you’ve always thought about and always wanted to build it from scratch. Welcome to scratch orgs!.

A scratch org can be spun up from a Dev Hub (Production instance) and are self-deleting, disposable and designed for source driven development. Since we have a Dev Hub configured — spinning up scratch orgs will be easy, I could hear someone thinking… does this limit just apply to a trial org or is it all devhub orgs? Be aware of the allocation limit for the Dev Hub trial instance we just created above:

Active Scratch Org Allocation: 20, Daily Scratch Org Allocation: 40

Scratch org usernames are autogenerated, long and unintuitive. So let’s go ahead and create a new scratch org and give it an alias to track the scratch org’s function.

We’ll need to perform three tasks before creating a scratch org:

1. Authorize a Dev Hub

2. Set up your Salesforce DX project: Run the following command to create an SFDX project on your local machine. This will generate the required files and folder structure needed to work on a SFDX project.

sfdx force:project:create -n SFDX_CLI_Demo

A scratch org definition file automatically created. It mimics the shape of an org that you use in the development life cycle, such as sandbox, packaging, or production.

https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file.htm

Seamless integration with Version Control System (VCS)

Lets use the scratch org we created before to create a Lightning component:

Set the scratch org ScratchOrgCLI_Demo as your default org as you’ll be developing in this scratch org

Open it up in the web browser:

sfdx force:org:open -u ScratchOrgCLI_Demo

Use the dev console to create a Lightning component and name it “SalesforceCLI_Demo” and just add a custom message to the lightning component.

Now that you’ve previewed your lightning component and you want to save this progress and use the VCS as the single source of truth, its time to pull down the changes and commit it as follows:

Lets run a status check on the scratch to view all changes you’ve made so far using

force:source:status

Once the metadata changes are confirmed pull down these changes to your local file system

sfdx force:source:pull

For the purpose of this article I’ve used GitHub (I’ve worked with BitBucket as well and its very similar)

Let’s go ahead and create a new GitHub repository and link the newly created Git repository and run a git status to verify all your files are added

Add all these changes to the Git Repository and perform your initial commit and push changes to the repository. Now all your changes are pushed into your Github repository and you can move on to building new features and functionalities.

Note: Use the Git desktop app to avoid having to run git commands.

Improved Metadata API commands and accessibility

ANT migration tool has the manual step where we have to adjust the package.xml to specify what metadata items to retrieve and then run a retrieve and deploy, this was cumbersome and confusing. Remember the constant switching between source and destination org credentials?? This is where aliases, Metadata API commands all come together and really make a difference!

mdapi Commands | Salesforce CLI Command Reference | Salesforce Developers

Let’s deploy the ‘SalesforceCLI_Demo’ Lightning component we created above into a sandbox or production environment. Since we have the scratch org set as our default org we can convert the source in the Salesforce DX project which automatically creates a package.xml file that can be deployed using Metadata API

sfdx force:source:convert -d mdapi_output/

We can specify the destination org to which we want to deploy, in this case it will be the DevHub org with alias “DevHub”

sfdx force:mdapi:deploy -d mdapi_output/ -u DevHub -w 5

Remember while using ANT migration tool where we had to keep switching the source and destination org credentials in a text file — isn’t this so easy?

Open the DevHub instance and verify that the Lightning component was migrated successfully. No updating package.xml, no changes to credentials, just use aliases and MDAPI commands. Simple and quick.

Summary

Below is a table summarizing the differences between Salesforce CLI and ANT Migration tool

The Salesforce CLI will prove advantageous to Salesforce developers who want to find ways to automate deployment and testing activities.