Git-based development – a common gold standard all over the software development world for decades – has finally arrived in the mainstream of Salesforce.
While using the benefits of version control for handling Salesforce metadata isn’t new, it was only with the arrival of Salesforce DX, scratch orgs, and second-generation managed packages (2GP) that it saw more traction within the Salesforce ecosystem. With the inception of the Salesforce DevOps Center, we now see Salesforce openly promoting Git-based development as a best practice for developing low-code and pro-code on the Salesforce platform. Let’s have a closer look at that, and how to best adopt Git-based Salesforce development.
Getting Started
Some of the many advantages of using Git-based development include the following:
- Working against a single source of truth as a team.
- Maintaining a consistent track record of who changed what and when.
- Reverting to earlier states of your metadata.
- Detecting and managing conflicts early in the development process.
- Executing control and quality assurance on work submitted by the contributors to your project.
But how do you convert to Git-based development? Well, you can follow these simple steps to nudge your Git journey along. These steps are aimed at target release manager roles or whoever “owns” the application lifecycle (ALM). There is also a video tutorial available that will guide you through this process in more detail.
Note: The video tutorial provides additional information, so watching the video and going through the steps below is recommended.
Let’s step right in.
Set Up Your Local Environment
The first step in the process is to set up and install the environment you intend to work in. You can install a set of free tools, such as:
- Visual Studio Code with the Salesforce Extension Pack
- Node.js and Salesforce CLI (sfdx)
- Git
For in-depth instructions on how to go about your installation, follow “Set Up Command-Line Tools” in the Trailhead Module “Command-Line Interface”.
Bootstrap a Salesforce DX Project
Once your environment is installed, you will need to connect Salesforce DX to your project. You can do so by:
- Opening Visual Studio Code.
- Opening the Command Palette via the keyboard shortcut – ‘Command+Shift+P’ – or selecting “View” and then “Command Palette”.
- Choosing “Command Salesforce DX” and then “Create project”.
- Selecting the “Standard” project type.
Fetch Your Existing Metadata
To begin working on your project, you will need to retrieve your org’s existing metadata. First, connect your machine to your (current) “source of truth” Salesforce org with Salesforce DX. You can do this by opening the Command Palette, selecting Command Salesforce DX, and then Authorize an Org. Retrieving all the fancy metadata from your org was a challenge for a long time – now it is natively supported with Salesforce DX.
The first command creates a “package.xml” file containing a list of your org’s metadata. This file is then used by the second command to retrieve the metadata:
Code
sfdx force source manifest create -t package --fromorg <orgalias>
sfdx force source retrieve -x package.xml -u <orgalias>
Code
Create and Initialize a Git Repository
You will now want to create your Git repository. A popular choice for creating your private repository is GitHub (or any other Git host, like Bitbucket, GitLab, or Azure). From there, copy the URL (for example, on GitHub, it will follow the schema “https://github.com/<userOrOrg>/<repoName>.git”).
If you oppose the idea of hosting your repository in the cloud, there are offerings, like the Bitbucket Data Center, that allow for additional enterprise security features.
Next, you’ll need to create a local Git repository, connect it with the remote repository, and upload your project:
Code
git init
git add .
git commit -m "initial metadata fetched from org"
git remote add origin <url of your repo>
git push -u origin main
Code
Use Source-Tracked Orgs For Your Development
Source-tracked orgs are a best practice for Salesforce development because the source code for an application or customization is stored in a source control system – such as Git – rather than directly edited in the Salesforce org. This has several benefits, including:
- Collaboration: With source control, multiple developers can work on the same code base simultaneously without interfering with each other’s changes. This allows for faster development and more efficient collaboration.
- Version Control: Changes to the code are tracked and versioned, making it easy to revert to previous versions or to identify who made a particular change. This makes it simpler to manage changes and ensures a clear history of all changes made to the code.
- Testing: Source-tracked orgs allow for seamless testing of changes before they are deployed to production. Developers can create test environments that mirror the production environment, test their changes in these environments, and then deploy them to production with the confidence that they will work as expected.
- Auditing and Compliance: Source control systems provide an audit trail that allows organizations to track who made changes, when they were made, and why. This helps organizations comply with regulatory requirements and provides a record of changes for auditing purposes.
When it comes to source tracking, three types of orgs support it:
- Developer Sandboxes
- Developer Pro Sandboxes
- Scratch orgs
Sandboxes and scratch orgs are excellent options, but some argue that scratch org-based development is the go-to option. For a detailed write-up of the pros and cons of using scratch org-based development, you can look at this insightful piece by Diéffrei Quadros on Medium.
A good rule of thumb is to use scratch orgs if your project allows, and to fall back to Sandboxes if you struggle getting your metadata deployed to scratch orgs.
Contributors to your source will use the following commands to retrieve work from their source-tracked orgs. They will also use these commands to send the changes they’ve performed in their local environment (typically using code from Apex or Lightning Web Components):
Code
sfdx force source push
sfdx force source pull
Code
Whenever a unit of work is ready, you’ll commit and push it to Git – from built-in capabilities, Visual Studio Code, or a command line.
All the steps outlined so far are common ground for active Git-based development inside and outside the Salesforce ecosystem. They cover the basics, but there is a bit more complexity to Git. That is why it is beneficial to familiarize yourself with branching strategies and other Git commands.
Admittedly, this can be overwhelming to less technical staff members like admins and no or low-code developers. This is probably the biggest hurdle for Salesforce teams when switching to a Git-based application lifecycle.
However, there are third-party tools that come to the rescue to simplify your switch to Git. Tools that allow coders and no-coders alike to collaborate on Salesforce development.
Contribute Your Changes
It’s now time to make your changes known to others in your team. You’ll achieve this by making a pull request (for example, on the GitHub UI). Pull requests are a significant workflow step to incorporate into your work.
They polish up your work before handing it off. Just remember to add meaningful comments for others – ideally including a reference to your issue tracking system.
Most Git hosting services print a unique URL when you push your branch, which you can use to open in a web browser to create your pull request. You can also use the command line as an alternative.
Here is a code example to submit a pull request with GitHub CLI:
Code
gh pr create --title "my title"
Code
Most contributors finish their Git development by sending a pull request, depending on how their team is set up and how roles are distributed.
Integrate and Promote Changes
Typically, a release manager or a peer will review your pull request and eventually merge it. Next comes the promotion to higher environments such as a user acceptance testing org or a production org. Automation or a manual process can take care of or assist with this.
In essence, there are different options to ship your work, such as:
- Deploying metadata
- Deploying the differences from a single unit of work
- Using managed or unlocked Salesforce 2GP
The third option is probably the most underrated and underused, as it is a very efficient way to promote changes. There are also open-source Salesforce DX plugins that can support the process.
Here is an example of deploying the metadata of the last merged pull request from Git to a Salesforce Sandbox or production org using the popular SFDX plugin “sfdx-git-delta“:
Code
sfdx sgd source delta --from "HEAD~1" --to "HEAD" --output "." --ignore .forceignore
sfdx force source deploy --manifest package/package.xml --postdestructivechanges destructiveChanges/destructiveChanges.xml --wait 30 --testlevel RunLocalTests
Code
Add Continuous Integration and Continuous Delivery (CI/CD)
Working Git-based development opens the door for all kinds of automation, such as running automated code quality checks, executing test automation (on the front end or by conducting unit tests), and automating the deployment. The sky is truly the limit. Start small and continuously build out your automation.
The needs and flavors of CI/CD are very individual and may vary from project to project. Many great open-source examples inspire adoption. However, we, at Hutte, are working on a “Recipe” gallery that will serve as a great starting point for your CI/CD. However, in the meantime, you can have a look at GitHub’s recipe repositories.
Summary
Working with Git might initially seem complicated compared to the (not so) good old change set-based deployment. But the overall benefit of a line-based track record of all changes (and the many other advantages presented in this article) more than justifies the transition.
A wide range of tools helps you get the best of both worlds – the ease of no-code and the power of Git. Some of these tools include:
- Salesforce’s DevOps Center, which is still relatively in its infancy stage and faces some crucial limitations (such as only supporting GitHub as a Git host).
- Blue Canvas, Salto, and enterprise tools like Gearset and Copado (they also base their rich product suites on version control with Git).
- Hutte supports no-code development while keeping the complexity of a command-line interface and Git away. You can also still maintain complete transparency and flexibility.
It’s time to embrace the new way of building and developing in Salesforce, as Git-based development is here to stay.