Sort by Topics, Resources
Clear
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Salto for

Salesforce

Articles

SHARE

Cracking the Salesforce DevOps interview—Part 2 (Salesforce CLI)

Pablo Gonzalez

March 5, 2023

9

min read

Welcome to the 2nd part of our “Cracking the Salesforce DevOps Interview” series. In these series, I come up with sample interview questions I would ask if I was hiring for a Salesforce DevOps role.

Our first entry was about Sandbox Strategy interview questions. This time, I ask detailed questions about the Salesforce CLI; I’m sure many of these will put your knowledge to the test!

Let’s get started.

Experience the Ease & Confidence of NetSuite Customizations with Salto

Automate the way you migrate Jira configurations from sandbox to production

Everything you need for error-free Salesforce deployments

Try it free

Have you ever seen XML-free org comparison tool?

Try it free

STAY UP TO DATE

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

1- What are some differences between the sfdx and sf CLIs?

In case you were unaware, Salesforce released a new CLI called sf instead of sfdx This new CLI will unite the CLIs for other Salesforce products like Heroku.

As part of this change, the typical sfdx commands are changing a bit, too, so this question is about how much you know these differences.

To start, you can read this article which details what’s happening and all the changes. As you can see, there are a lot of changes, but I’d highlight a few:

  • New commands don’t use colons as separators, i.e., instead of force:source:deploy you can write force source deploy

  • There are new commands for retrieving and deploying metadata, such as sf deploy metadata

  • The new commands are interactive; for example, if you launch sf deploy

Make sure you go play with it to show you know your stuff during the interview. 

2- What are the differences between the metadata API and source format?

Before SFDX came out, the old force.com migration tool was used to retrieve and deploy metadata. The retrieved project structure is what is known as the Metadata format.

In this format, all the data associated with an object (fields, layouts, list views) is in a single XML file. For example, this is what the XML file for the account object would look like:

 

As you can see, fields, search layouts, sharing model, everything is in one big file. This makes version control a nightmare because merging these huge files is very difficult.

With sfdx, the folder structure is broken down into subdirectories, making it much easier to reason about the metadata of an object. This is known as the Source format. 

And while we are at it, you should know there are Salesforce CLI commands to convert metadata from one format to another.

To convert from the source format back to the old metadata API format, use sfdx force:source:convert

To convert from the metadata API format to the newer source format, use sfdx force:mdapi:convert -r path/to/metadata -d path/to/outputdir

Finally, it’s very important to know that you can use the source format without using scratch orgs; the source format is compatible with org-based development and sandboxes. 

I say this because I’ve seen some confusion about this, where people think that to benefit from the newer source format, you have to adopt source-based development (scratch orgs, etc.), and that’s not the case. 

3- How do you send the output of a Salesforce CLI command to a file? and what are some use cases?

Let’s say you run this command with the --jsonflag.

sfdx force:source:deploy -p "force-app/main/default/classes" –json

This will output a big JSON response to the terminal

How can you create a .jsonfile containing this JSON response as its content?

You can do this by redirecting the output of the command with the > character, followed by the name of the file that should hold its contents, for example:

sfdx force:source:deploy -p "force-app/main/default/classes" --json > deploy-result.json

With the above command, the JSON output will not be printed to the terminal; instead, it’ll be saved in the deploy-result.jsonfile

Now, what if you wanted to both see the output in the terminal and send it to a file? You can use this command:

sfdx force:source:deploy -p "force-app/main/default/classes" --json 2>&1 | tee deploy-result.json

As for the 2nd part of the question: Why would you want to do this?

There are many scenarios. For example, you could read this json file using a node.js script and do some additional processing. You could also store this file in an external application and create deployment metrics, like how many deployments succeed in a week.

4- How does the Salesforce CLI know which org to run the commands against?

It’s possible to run many Salesforce CLI commands without specifying a target org, for example

sfdx force:source:deploy -p "force-app/main/default/classes"

How does this command know which org to deploy the apex classes?

The idea is that before you run this command, you would have set up a default alias or default org. This tells the CLI to run any subsequent commands against that org unless another org is specified. 

You can set the default username/org using this command

sfdx config:set defaultusername=test-wvkpnfm5z113@example.com

5- Can you change the behavior of the CLI depending on the computer it runs on?

Yes! You can set environment variables for the Salesforce CLI either globally or on a specific command.

For example, I can set this environment variable to deploy metadata using the Metadata REST API as opposed to the traditional SOAP API

SFDX_REST_DEPLOY=true sfdx force:source:deploy -p force-app/main/default/classes

You can read more about environment variables here

6- What are 3 ways to script Salesforce CLI commands so you can run them automatically?

Let’s say you run a Salesforce CLI command very often and are tired of typing it out every time, passing parameters, etc. You can script this command into something that can be executed quickly. So, how can you do that?

I can think of three ways to do this. Let’s say we want to automate the following command, which deploys all apex classes in our project

sfdx force:source:deploy -p "force-app/main/default/classes"

Adding this command to a nodejs file using a child process is one way. So, I can create a sfdx-commands.jsfile that looks like this

Then, I can run node sfdx-commandson the terminal, and I get the following output:

A deployment was created by Pablo Gonzalez Alvarez with Deployment Id 0Af68000007Z94nCAC

Basically, I run the Salesforce CLI command and process the result with JavaScript. Then I can do whatever I want with that result. This a great example of how to combine the Salesforce CLI with JavaScript!

Another way to do this is to add the command as a script in the package.jsonfile that comes with all SFDX projects. Here’s what it would look like:

Then, I can run npm run deploy-classes from the terminal, and it’ll execute the Salesforce CLI command. Much easier than the previous approach, but it’s less customizable.

This approach is useful when you want your developers to have access to frequently used commands and you want all of them to use exactly the same commands. 

You can add the CLI commands as scripts to the package. Jsonfile and train your team to run them using npm run command-name>

Finally, you can create a shell script. 

Here’s a real-life example: Many of the Salesforce Trailhead Sample Apps require you to run multiple commands to set them up. Here are the instructions for the e-bikes sample app:

 

Rather than running these commands individually, you can group them in a shell script. And actually, the same sample app comes with a shell script that does this already!

You’ll see the shell script has all the commands while printing some progress information along the way. You can run this command by typing sh bin/install-scratch.shin the terminal.

7- How can you add completely custom functionality to the Salesforce CLI?

You can create entirely new functionality on the Salesforce CLI by creating a CLI Plugin. The sky is the limit. You can create commands to call the REST API, call an external web service, etc.

Here are a few popular examples: 

  • The org documentor can document your org based on the files in your SFDX project.
  • Sfdx-git-delta can be used to generate delta folders for deployment based on differences between two git commits
  • SFDX Hardis wraps multiple CLI plugins into one, creating a super powerful CLI. 

8- You are having trouble remembering Salesforce CLI commands. What are two options to help you easily use commands without remembering all their parameters?

First, you can use many Salesforce CLI commands directly in Visual Studio Code as long as you have the Salesforce Extension Pack installed.

For example, I can see a bunch of org-related commands directly in the command palette. 

Many other commands are available as well. For example, I can deploy a specific folder of my SFDX project just by right-clicking it rather than typing an entire command

The second option is to enable auto-complete for the Salesforce CLI. This is a huge time saver as all commands will be auto-completed for you, including their parameters

9- How do you get diagnosis information from the CLI?

If you are having trouble with a specific CLI command, you can use the doctor command to get diagnosis information about it. Here’s an example:

sfdx doctor --command "force:org:list --all

The command will generate a few files in your directory. These files can be added to GitHub issues or other conversations with the Salesforce CLI team.

10- What configuration file is needed before creating a Sandbox through the CLI?

In case you didn't know, creating a sandbox through the Salesforce CLI is possible. Here's a sample command

sfdx force:org:create --type sandbox --targetusername prodOrg --definitionfile config/dev-sandbox-def.json -a MyDevSandbox -s -w 30

Before you can create a sandbox, though, you need to create a sandbox definition file. This is a JSON file that will list the properties of the sandbox.


{
     "sandboxName": "dev1",
     "licenseType": "Developer",
     "apexClassId":"00R288889ffff2GEY",
     "autoActivate":true,
     "description":"Dev sandbox for personal use"
}

STAY UP TO DATE

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Have you ever seen XML-free org comparison tool?

Try it free

Have you ever seen XML-free org comparison tool?

Try it free

When you run the command, you need to specify the location of this definition file. Then, the new sandbox will be created according to the values defined in the file.

And that’s it! Hopefully, you know feel more confident about your knowledge of the Salesforce CLI to pass that Salesforce DevOps interview!

Stay tuned because in the next entry, we’ll go over some Git questions!

WRITTEN BY OUR EXPERT

Pablo Gonzalez

Business Engineering Architect

Pablo is a Business Engineering Architect at Salto. He is the developer of HappySoup.io and has 11 years of development experience in all things Salesforce.

Sort by Topics, Resources
Clear
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Salto for

Salesforce

Salesforce

SHARE

Cracking the Salesforce DevOps interview—Part 2 (Salesforce CLI)

Pablo Gonzalez

March 5, 2023

9

min read

Welcome to the 2nd part of our “Cracking the Salesforce DevOps Interview” series. In these series, I come up with sample interview questions I would ask if I was hiring for a Salesforce DevOps role.

Our first entry was about Sandbox Strategy interview questions. This time, I ask detailed questions about the Salesforce CLI; I’m sure many of these will put your knowledge to the test!

Let’s get started.

What if Zendesk was 4x less work?

Request a Demo Get started with Salto

1- What are some differences between the sfdx and sf CLIs?

In case you were unaware, Salesforce released a new CLI called sf instead of sfdx This new CLI will unite the CLIs for other Salesforce products like Heroku.

As part of this change, the typical sfdx commands are changing a bit, too, so this question is about how much you know these differences.

To start, you can read this article which details what’s happening and all the changes. As you can see, there are a lot of changes, but I’d highlight a few:

  • New commands don’t use colons as separators, i.e., instead of force:source:deploy you can write force source deploy

  • There are new commands for retrieving and deploying metadata, such as sf deploy metadata

  • The new commands are interactive; for example, if you launch sf deploy

Make sure you go play with it to show you know your stuff during the interview. 

2- What are the differences between the metadata API and source format?

Before SFDX came out, the old force.com migration tool was used to retrieve and deploy metadata. The retrieved project structure is what is known as the Metadata format.

In this format, all the data associated with an object (fields, layouts, list views) is in a single XML file. For example, this is what the XML file for the account object would look like:

 

As you can see, fields, search layouts, sharing model, everything is in one big file. This makes version control a nightmare because merging these huge files is very difficult.

With sfdx, the folder structure is broken down into subdirectories, making it much easier to reason about the metadata of an object. This is known as the Source format. 

And while we are at it, you should know there are Salesforce CLI commands to convert metadata from one format to another.

To convert from the source format back to the old metadata API format, use sfdx force:source:convert

To convert from the metadata API format to the newer source format, use sfdx force:mdapi:convert -r path/to/metadata -d path/to/outputdir

Finally, it’s very important to know that you can use the source format without using scratch orgs; the source format is compatible with org-based development and sandboxes. 

I say this because I’ve seen some confusion about this, where people think that to benefit from the newer source format, you have to adopt source-based development (scratch orgs, etc.), and that’s not the case. 

3- How do you send the output of a Salesforce CLI command to a file? and what are some use cases?

Let’s say you run this command with the --jsonflag.

sfdx force:source:deploy -p "force-app/main/default/classes" –json

This will output a big JSON response to the terminal

How can you create a .jsonfile containing this JSON response as its content?

You can do this by redirecting the output of the command with the > character, followed by the name of the file that should hold its contents, for example:

sfdx force:source:deploy -p "force-app/main/default/classes" --json > deploy-result.json

With the above command, the JSON output will not be printed to the terminal; instead, it’ll be saved in the deploy-result.jsonfile

Now, what if you wanted to both see the output in the terminal and send it to a file? You can use this command:

sfdx force:source:deploy -p "force-app/main/default/classes" --json 2>&1 | tee deploy-result.json

As for the 2nd part of the question: Why would you want to do this?

There are many scenarios. For example, you could read this json file using a node.js script and do some additional processing. You could also store this file in an external application and create deployment metrics, like how many deployments succeed in a week.

4- How does the Salesforce CLI know which org to run the commands against?

It’s possible to run many Salesforce CLI commands without specifying a target org, for example

sfdx force:source:deploy -p "force-app/main/default/classes"

How does this command know which org to deploy the apex classes?

The idea is that before you run this command, you would have set up a default alias or default org. This tells the CLI to run any subsequent commands against that org unless another org is specified. 

You can set the default username/org using this command

sfdx config:set defaultusername=test-wvkpnfm5z113@example.com

5- Can you change the behavior of the CLI depending on the computer it runs on?

Yes! You can set environment variables for the Salesforce CLI either globally or on a specific command.

For example, I can set this environment variable to deploy metadata using the Metadata REST API as opposed to the traditional SOAP API

SFDX_REST_DEPLOY=true sfdx force:source:deploy -p force-app/main/default/classes

You can read more about environment variables here

6- What are 3 ways to script Salesforce CLI commands so you can run them automatically?

Let’s say you run a Salesforce CLI command very often and are tired of typing it out every time, passing parameters, etc. You can script this command into something that can be executed quickly. So, how can you do that?

I can think of three ways to do this. Let’s say we want to automate the following command, which deploys all apex classes in our project

sfdx force:source:deploy -p "force-app/main/default/classes"

Adding this command to a nodejs file using a child process is one way. So, I can create a sfdx-commands.jsfile that looks like this

Then, I can run node sfdx-commandson the terminal, and I get the following output:

A deployment was created by Pablo Gonzalez Alvarez with Deployment Id 0Af68000007Z94nCAC

Basically, I run the Salesforce CLI command and process the result with JavaScript. Then I can do whatever I want with that result. This a great example of how to combine the Salesforce CLI with JavaScript!

Another way to do this is to add the command as a script in the package.jsonfile that comes with all SFDX projects. Here’s what it would look like:

Then, I can run npm run deploy-classes from the terminal, and it’ll execute the Salesforce CLI command. Much easier than the previous approach, but it’s less customizable.

This approach is useful when you want your developers to have access to frequently used commands and you want all of them to use exactly the same commands. 

You can add the CLI commands as scripts to the package. Jsonfile and train your team to run them using npm run command-name>

Finally, you can create a shell script. 

Here’s a real-life example: Many of the Salesforce Trailhead Sample Apps require you to run multiple commands to set them up. Here are the instructions for the e-bikes sample app:

 

Rather than running these commands individually, you can group them in a shell script. And actually, the same sample app comes with a shell script that does this already!

You’ll see the shell script has all the commands while printing some progress information along the way. You can run this command by typing sh bin/install-scratch.shin the terminal.

7- How can you add completely custom functionality to the Salesforce CLI?

You can create entirely new functionality on the Salesforce CLI by creating a CLI Plugin. The sky is the limit. You can create commands to call the REST API, call an external web service, etc.

Here are a few popular examples: 

  • The org documentor can document your org based on the files in your SFDX project.
  • Sfdx-git-delta can be used to generate delta folders for deployment based on differences between two git commits
  • SFDX Hardis wraps multiple CLI plugins into one, creating a super powerful CLI. 

8- You are having trouble remembering Salesforce CLI commands. What are two options to help you easily use commands without remembering all their parameters?

First, you can use many Salesforce CLI commands directly in Visual Studio Code as long as you have the Salesforce Extension Pack installed.

For example, I can see a bunch of org-related commands directly in the command palette. 

Many other commands are available as well. For example, I can deploy a specific folder of my SFDX project just by right-clicking it rather than typing an entire command

The second option is to enable auto-complete for the Salesforce CLI. This is a huge time saver as all commands will be auto-completed for you, including their parameters

9- How do you get diagnosis information from the CLI?

If you are having trouble with a specific CLI command, you can use the doctor command to get diagnosis information about it. Here’s an example:

sfdx doctor --command "force:org:list --all

The command will generate a few files in your directory. These files can be added to GitHub issues or other conversations with the Salesforce CLI team.

10- What configuration file is needed before creating a Sandbox through the CLI?

In case you didn't know, creating a sandbox through the Salesforce CLI is possible. Here's a sample command

sfdx force:org:create --type sandbox --targetusername prodOrg --definitionfile config/dev-sandbox-def.json -a MyDevSandbox -s -w 30

Before you can create a sandbox, though, you need to create a sandbox definition file. This is a JSON file that will list the properties of the sandbox.


{
     "sandboxName": "dev1",
     "licenseType": "Developer",
     "apexClassId":"00R288889ffff2GEY",
     "autoActivate":true,
     "description":"Dev sandbox for personal use"
}

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

When you run the command, you need to specify the location of this definition file. Then, the new sandbox will be created according to the values defined in the file.

And that’s it! Hopefully, you know feel more confident about your knowledge of the Salesforce CLI to pass that Salesforce DevOps interview!

Stay tuned because in the next entry, we’ll go over some Git questions!

WRITTEN BY OUR EXPERT

Pablo Gonzalez

Business Engineering Architect

Pablo is a Business Engineering Architect at Salto. He is the developer of HappySoup.io and has 11 years of development experience in all things Salesforce.