Welcome to the 3rd 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.

In case you missed them, here are parts 1-2:

Sandbox Strategy Interview Questions

Salesforce CLI Interview Questions

‍

This time, I ask detailed questions about using Git with Salesforce.

Let's get started.

‍

‍

When should you use a remote Git repository for Salesforce?

This can be done without your local repository being connected to a remote repository, such as GitHub, BitBucket, or GitLab.

So, when should the local repo be connected to a remote one? 

The remote repository is typically used for two reasons:

a) Backup

If your laptop crashes or gets stolen, you don't want all your Git history gone with it. By pushing changes to a remote repository, you have a backup.

b) Collaboration

When you use a remote repository, all developers can connect to it. This allows everyone to see everyone else's changes.

It also allows for Continous Integration because you can pull someone else's changes to your computer before you start working on a new feature, thus making sure your changes work alongside theirs. 

‍

You have made several (uncommitted) changes to an apex class and decided to return to its previous version. What Git command can you use? 

You can give the stash a name, and later, if you want to, you can cover the changes. 

You can learn more about this command here. 

‍

What is the difference between an org-based and a Git-based deployment?

An org-based deployment is one where the source of a change (say, a new apex class and a modified custom field) is a Salesforce org.

You deploy the changes to a new org by taking the metadata from the source org and deploying it to the destination org. This is the model used by change sets and other Salesforce DevOps tools.

In contrast, a Git-based deployment is one where the change source is a Git branch. 

Fun fact: Salto's deployments are a hybrid of these two models. We take the best of both worlds. It's pretty interesting! 

‍

What role does Git play in Salesforce Continuous Integration?

As explained extensively in this other article, Continuous Integration (CI) is the practice of committing changes to a shared branch as frequently as possible to ensure that your changes don't break other developers' work, and vice-versa.

‍

‍

With this said, Git is at the core of CI. Git is what allows you to see what other developers have changed and what will enable you to fetch their changes and integrate them into your local copy of the repository.

Without Git, you cannot practice CI. 

‍

You just created a new validation rule. What commands from the Salesforce CLI and Git do you need to commit this to version control? 

This one is easy. First, make sure you master the Salesforce CLI. 

To retrieve the validation rule, you can run the following command:

Then, you can commit the change to version control with 

‍

How do you ensure VSCode, Git, and your org are all in sync?

Imagine this scenario:

a) You have a validation rule in your org. This validation rule is also in your sfdx project in VSCode and in the Git repo. 

b) You edit the validation rule in the org but forget to retrieve the latest version of the rule using the Salesforce CLI.

c) Two days later, you change the rule directly in VS Code and forget to deploy it to the org and commit it to Git.

Now your org, the sfdx project, and Git all have a different version of the rule. 

How do you reconcile the changes?

You can use the source diff command to see how the validation rule differs between your org and VS Code.

‍

‍

Then, you’ll be able to see the diffs right within VS Code

‍

‍

To see the differences between the validation rule in VS Code and Git, you can use a VS Code extension called Git Lens. With this extension, I can see a timeline of changes made to the validation rule and how it's currently different from the last version I committed to Git. 

‍

‍

Once I can see all the versions, I can use a combination of Salesforce CLI and Git commands to ensure only one version exists across all three places.

How do you decide what metadata to track in Git?

This question is about how much metadata you should store in Git. For example, do you download the entire Salesforce org and commit it to Git, or only the code-based metadata? Like apex classes, LWCs, etc.? 

I wrote about this in my CI/CD Checklist for Salesforce Architects. 

The key is determining how much complexity you want to deal with vs. how much metadata you are happy to be accountable for.

It's perfectly ok to decide that you will only track code-based metadata and that other metadata will not be tracked.

You can always add more metadata types as you get familiar with Git and the complexities of Salesforce metadata and deployments. 

‍

Should you commit directly to a shared Git branch or use a pull request instead?

In Salesforce, you can also have a CI job run a validation deployment when a PR is created, allowing you to check if your changes are deployable.

If you commit directly to a shared branch and the changes are not deployable (i.e., you get a deployment error), you have to revert the commit, which can be complicated. 

‍

How do you roll back to a previously known state using Git?

Let's say you've made 5 commits on an apex class, and you want to go back to commit number 3 and get rid of 4 and 5, as if they never happened.

How do you do this?

Here's one way

b) Then, create a branch from that commit

c) Now, go back to main

d) Finally, do a hard reset. This'll reset the timeline to commit number 3

‍

Can Git be the source of truth for your Salesforce org?

I answered this question in this short blog post and recommend reading it (if I paste it here, Google will flag it as plagiarism).

The long story short is that Git can be the version of some truth in your Salesforce org, but not all. It can also be the source of truth of specific changes in the org but not the source of truth of the current state of the org (as is the case with infrastructure as code in traditional software development).

This is because:

a) Not all metadata can be deployed via the Metadata API; some must be modified manually in Production.

b) Your org may also have configuration data, such as CPQ, which cannot be versioned in Git (unless you do this).

c) As long as Salesforce allows direct production changes, Git will always be behind.

And that's it! I hope you enjoyed this article! See you in part 4! 

‍