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:
- Collaborative Development: Working as a team against a single source of truth.
- Traceability: Maintaining a consistent track record of changes made to the metadata and identifying who made the changes and when.
- Version Control: Reverting to previous states of metadata when needed.
- Conflict Management: Detecting and resolving conflicts early in the development process.
- Control and Quality Assurance: Ensuring control and quality by reviewing and managing work contributed to the project.
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:
- Install Visual Studio Code with the Salesforce Extension Pack.
- Install Node.js and Salesforce CLI (sfdx).
- Install Git.
Step 2: Bootstrap a Salesforce DX Project
Connect Salesforce DX to your project by following these steps:
- Open Visual Studio Code.
- Open the Command Palette using the keyboard shortcut “Command+Shift+P” or by selecting “View” and then “Command Palette.”
- Choose “Command Salesforce DX” and then “Create project.”
- Select the “Standard” project type
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:
- Open the Command Palette.
- Select “Command Salesforce DX” and then choose “Authorize an Org.”
- This will initiate the authorization process to connect your machine with the Salesforce org.
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:
- Choose a Git host, such as GitHub, and create a private repository. Copy the repository’s URL (e.g., “https://github.com//.git”).
- Initialize a local Git repository, add your project files, commit the changes, and connect it to the remote repository.
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:
- Collaboration: The benefits of adopting source-tracked orgs include enhanced collaboration among multiple developers, faster development, and more efficient teamwork.
- Version Control: Version control capabilities enable easy reverting to previous code versions and provide a clear history of changes.
- 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.
- 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:
- Developer Sandboxes
- Developer Pro Sandboxes
- Scratch orgs
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:
- Deploying metadata
- Deploying the differences from a single unit of work
- Using managed or unlocked Salesforce 2GP
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.