Git-Based Development in Salesforce- A Comprehensive guide

Git-based development, a widely recognized standard in the software development world, has now become mainstream in the Salesforce ecosystem. With the advent of Salesforce DX, scratch orgs, and second-generation managed packages (2GP), Git-based development has gained significant traction. Salesforce is actively promoting it as a best practice for both low-code and pro-code development on their platform. This comprehensive guide delves into Git-based Salesforce development, its advantages, and provides a step-by-step process to help you successfully adopt this approach.

Git-based development offers numerous advantages, including:

To transition to Git-based development, you can follow these straightforward steps that will help you embark on your Git journey. These steps are designed for release managers or individuals responsible for the application lifecycle (ALM). Additionally, there is a comprehensive video tutorial available to provide you with a more detailed walkthrough of the process.

Please note that it is recommended to watch the accompanying video tutorial in addition to following the steps outlined below. The video tutorial provides valuable additional information to enhance your understanding and implementation of the process. Therefore, for a comprehensive learning experience, we suggest watching the tutorial and then proceeding with the following steps.

 

Let’s step right in.

Step 1: Set Up Your Local Environment

To begin, you need to set up and install the necessary tools:

For in-depth instructions on how to go about your installation, follow “Set Up Command-Line Tools” in the Trailhead Module “Command-Line Interface”.

Step 2: Bootstrap a Salesforce DX Project

Connect Salesforce DX to your project by following these steps:

Step 3: Fetch Your Existing Metadata

To begin working on your project, you need to retrieve the existing metadata from your Salesforce org, which serves as the “source of truth.” Follow these steps to connect your machine to the org using Salesforce DX:

Retrieving metadata from your org is now natively supported with Salesforce DX, eliminating the challenges faced in the past.

Once connected, you can proceed with the retrieval process using two commands. The first command creates a “package.xml” file that contains a comprehensive list of your org’s metadata. The second command utilizes this file to retrieve the metadata from the org.

Code:-
sfdx force source manifest create -t package –fromorg <orgalias>
sfdx force source retrieve -x package.xml -u <orgalias>

Step 4: Create and Initialize a Git Repository

Create a Git repository and connect it to your project:

Code:- (use git in starting of every command (git init))
git init
add .
commit -m “initial metadata fetched from org”
remote add origin <url of your repo>
push -u origin main

Step 5: Use Source-Tracked Orgs for Your Development

When it comes to Salesforce development, using source-tracked orgs is considered a best practice. This approach involves storing the source code for an application or customization in a source control system, such as Git, rather than directly editing it in the Salesforce org. There are several benefits to adopting source-tracked orgs:

1. Collaboration: The benefits of adopting source-tracked orgs include enhanced collaboration among multiple developers, faster development, and more efficient teamwork.
2. Version Control: Version control capabilities enable easy reverting to previous code versions and provide a clear history of changes.
3. Testing: Testing is streamlined through source-tracked orgs, as developers can create mirrored test environments and ensure changes function as expected before deploying to production.
4. Auditing and Compliance: Additionally, source control systems provide an audit trail for tracking changes, promoting compliance with regulatory requirements and facilitating auditing processes.

There are three types of orgs that support source tracking:

While both sandboxes and scratch orgs are viable options, some argue that scratch org-based development is the preferred approach.

Contributors working with source-tracked orgs will use the following commands to retrieve their work from the org and send their local changes:

Code:
sfdx force source push
sfdx force source pull

Once a unit of work is ready, it should be committed and pushed to Git. This can be done using the built-in capabilities of Git, Visual Studio Code, or through the command line.

The steps outlined thus far are fundamental to active Git-based development both within and outside the Salesforce ecosystem. While they cover the basics, Git itself can be more complex. It is beneficial to familiarize yourself with branching strategies and other Git commands to make the most of this version control system.

Fortunately, there are third-party tools available that simplify the transition to Git. These tools enable collaboration between coders and non-coders, facilitating streamlined Salesforce development.

Step 6: Contribute Your Changes

Make your changes known to others in your team by creating a pull request:

To ensure that your team is aware of the changes you’ve made, it’s important to create a pull request. This can be done through the pull request feature provided by Git hosting services, such as the GitHub UI. Pull requests serve as a significant step in the workflow, allowing for review and collaboration before finalizing the changes.

When creating a pull request, it’s recommended to add meaningful comments for others to understand the purpose and context of the changes. Including references to your issue tracking system can provide additional context and help streamline the review process.

Most Git hosting services, upon pushing your branch, will generate a unique URL. You can use this URL to open a web browser and create your pull request. Alternatively, you can use the command line to accomplish this task.
Here is an example of using GitHub CLI to submit a pull request:

Code:
gh pr create –title “my title”

The specific approach for sending pull requests may vary depending on your team’s setup and roles distribution. However, it is common for contributors to finalize their Git development by submitting a pull request for review.

Step 7: Integrate and Promote Changes

After your pull request is created, it will typically be reviewed by a release manager

or a peer, who will eventually merge the changes into the main codebase. The next step involves promoting the changes to higher environments, such as a user acceptance testing org or a production org. This promotion can be handled through automation or a manual process.

There are different options available to ship your work, including:

Here is an example of deploying the metadata from the last merged pull request in 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

The provided code demonstrates using the “sfdx-git-delta” plugin to perform a delta deployment of the metadata changes. It generates the changes between the previous commit (HEAD~1) and the latest commit (HEAD) and deploys them using the Salesforce DX command “force source deploy.” The deployment includes a manifest file (“package/package.xml”) and handles any post-destructive changes if necessary.

Add Continuous Integration and Continuous Delivery (CI/CD)

Embracing Git-based development not only revolutionizes collaboration and version control but also unlocks a world of automation possibilities. Through automation, you can streamline processes, enhance code quality, and expedite deployment. Whether it’s running automated code quality checks, executing front-end or unit tests, or automating the deployment pipeline, the potential is limitless. It’s recommended to start small and gradually expand your automation efforts.

However, it’s crucial to note that the needs and preferences for continuous integration and continuous delivery (CI/CD) can vary from one project to another. The beauty of Git-based development lies in its flexibility, allowing you to tailor your CI/CD practices to suit your specific requirements. Many inspiring open-source examples can serve as valuable references to guide your adoption of CI/CD. While Hutte is actively working on a “Recipe” gallery that will provide an excellent starting point for CI/CD, in the meantime, you can explore GitHub’s vast collection of recipe repositories to gain insights and inspiration.

By harnessing the power of automation in your Git-based Salesforce development, you can streamline processes, ensure code quality, and achieve faster and more efficient deployment cycles. Stay agile, continuously improve, and leverage the wealth of resources available to maximize the benefits of CI/CD in your Salesforce projects.

Conclusion:

While Git-based development may initially appear complex, the benefits of a line-based track record of changes and other advantages outweigh the transition challenges. Numerous tools, including Salesforce’s DevOps Center, Blue Canvas, Salto, Gearset, Copado, and Hutte, can assist in simplifying and enhancing Git-based development. Embrace this new approach to building and developing on the Salesforce platform, as Git-based development is here to stay.