Salto for
Salesforce
Articles
SHARE
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.
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:
Make sure you go play with it to show you know your stuff during the interview.
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.
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.
This will output a big JSON response to the terminal
Now, what if you wanted to both see the output in the terminal and send it to a file? You can use this command:
As for the 2nd part of the question: Why would you want to do this?
It’s possible to run many Salesforce CLI commands without specifying a target org, for example
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
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
You can read more about environment variables here.
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
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!
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.
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 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:
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
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:
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.
In case you didn't know, creating a sandbox through the Salesforce CLI is possible. Here's a sample command
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.
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!
Salto for
Salesforce
Salesforce
SHARE
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.
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:
Make sure you go play with it to show you know your stuff during the interview.
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.
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.
This will output a big JSON response to the terminal
Now, what if you wanted to both see the output in the terminal and send it to a file? You can use this command:
As for the 2nd part of the question: Why would you want to do this?
It’s possible to run many Salesforce CLI commands without specifying a target org, for example
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
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
You can read more about environment variables here.
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
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!
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.
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 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:
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
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:
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.
In case you didn't know, creating a sandbox through the Salesforce CLI is possible. Here's a sample command
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.
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!