A Guide to Git and Version Control for Salesforce Developers
Empowering Salesforce Teams with Effective Version Control and Git Workflows
Version control is crucial for harnessing the advantages of an effective DevOps process in Salesforce. It enables automation, which in turn speeds up development and release cycles, empowering Salesforce teams to efficiently create, test, and deploy code and configurations. However, there are typical obstacles that teams must overcome to successfully embrace source-driven and automated workflows.
This article elucidates the means to surmount two primary challenges in adopting version control. By doing so, your Salesforce team can fully experience the incredible benefits of Salesforce DevOps.
The Difficulties Faced in Version Control
The inherent flexibility of version control, while empowering, can also introduce complexity that poses challenges during adoption. According to the extensive State of Salesforce DevOps survey, teams encounter various difficulties when initially implementing version control. Essentially, there are two primary hurdles:
Discovering the appropriate process: Teams frequently face difficulties in identifying a suitable Git branching strategy.
Ensuring team collaboration: There is a people-oriented challenge that necessitates an effective change management process to ensure cohesive teamwork.
Before delving into these obstacles, let's explore a source-driven approach tailored for Salesforce.
The Concept of the Feature Branch Model
To incorporate version control as a reliable source of truth in your workflow, the feature branch model emerges as the simplest strategy. While numerous branching strategies are available with version control, this model offers your team distinct advantages over more intricate approaches:
Minimal lead time: It reduces the duration between completing your work and releasing it to production.
Efficient release cycle: Releasing smaller changes more frequently enables a tighter feedback loop.
Reduced merge complexity: Opt for the simplest branching strategy available, minimizing the number of merges required.
In the aforementioned model, the changes are implemented within a feature branch that corresponds to a Salesforce development environment, such as a dev sandbox. After committing the changes, a pull request is created to merge them into the master branch, preparing for testing and eventual release to production.
To introduce automation into the process, stability is crucial. Salesforce orgs are dynamic, with ongoing configuration changes, platform updates, managed packages, and user modifications. In contrast, Git provides a static environment. By utilizing Git branches, new features can be isolated, allowing controlled gating, approval, and release of changes to production. This source-driven process represents a significant departure from Salesforce's native in-org development practices.
In addition to stability, automation requires a suitable tool to streamline the processes. Since Salesforce lacks native deployment automation, Git serves as a robust framework that can be integrated with other tools like Jenkins or CircleCI to facilitate automation. By utilizing a DevOps solution designed specifically for Salesforce, it is even possible to configure continuous integration tools to validate and test new changes against downstream orgs immediately upon committing a change or opening a pull request, ensuring rapid readiness for release.
Despite the benefits of the simple feature branch model, it may not be the ideal Git strategy for every team. Larger teams with diverse roles and multiple use cases for different environments might find value in adopting a slightly more complex branching model.
Selecting the Optimal Git Branching Strategy
The selection of a branching strategy plays a vital role in determining how your team will collaborate with Git. Choosing the right strategy is crucial for the successful adoption of version control, and it requires careful consideration. Here are five factors to keep in mind when deciding on a branching strategy:
Complexity: Branching strategies can vary in complexity. While more complex strategies may closely align with your current workflow, they can be challenging for new or less technically inclined team members to grasp. Additionally, complex models often require more maintenance and can potentially slow down the release process. In general, simpler strategies tend to be more favorable.
Team size: The size of your team influences the optimal strategy for you. Larger teams typically have a diverse range of roles that interact with the workflow. They may also manage multiple environments with distinct use cases, necessitating a slightly more intricate branching strategy. Conversely, smaller teams can often benefit from adopting a straightforward approach, enabling quick implementation and future model adjustments as needed.
Release cadence: Version control allows for increased release frequency, but there may be business considerations that dictate a specific release cycle, such as regulatory requirements or limited maintenance windows. In such cases, the branching strategy may need to be adjusted to accommodate the necessary approval stages, potentially requiring a more complex approach.
Current workflow: The transition to version control presents an opportunity to reshape your existing workflow. Gaining buy-in from your team is crucial, and the configuration of your current environments may also impact the choice of branching strategy. For example, you may need to incorporate testing and development environments into the new workflow or ensure a long-term side project remains up to date. Alternatively, you might be open to exploring new approaches and introducing fresh ideas into your workflow.
Ambition: Not all teams share the same goals or requirements. What works well for a small team may not be suitable for a larger organization. It is essential to understand the specific challenges you aim to address and what constitutes an effective solution for your team when selecting a branching strategy.
By considering these factors, you can make an informed decision about the most appropriate branching strategy for your team's needs and circumstances.
Utilizing Branching for Multiple Testing and Staging Environments
While there is no universally applicable Git branching strategy, our experience at Gearset, based on conversations with numerous Salesforce teams, has led us to identify a model that proves effective for many of them.
The aforementioned model, while similar to the feature branch model, incorporates additional complexity by including multiple testing and staging environments (such as QA and Stage) with each environment having a dedicated long-lived branch in Git. Let's walk through the process for this model, assuming your team works in sprints:
At the beginning of the sprint, a release branch is created from the master/main branch.
Each team member creates feature branches as they start working on individual user stories.
Changes are developed in individual dev sandboxes (and/or IDE) and regularly committed to the respective feature branches.
When a feature is ready for QA, a pull request is opened, and the feature branch is merged into the QA integration branch.
After the merge to the QA integration branch, the changes are deployed to the QA sandbox for testing and approval by the QA team.
Once the testing and approval in the QA environment are completed, a pull request is opened to merge the feature branch into the Stage integration branch.
After merging the changes to the Stage integration branch, the branch is deployed to the Stage sandbox for further testing, approval, and potentially user acceptance testing (UAT).
Once the changes are approved in the Stage environment, the feature branch is merged into the release branch. This process is repeated for every change made during the sprint, with each approved feature being accumulated in the release branch.
At the end of the sprint, all changes present in the release branch are deployed to the production environment and made live for end users.
After verifying the new work in the production environment, the release branch is merged back into the master branch to synchronize it with the production environment.
It is also advisable to merge the master branch back into the integration branches to ensure synchronization in case any unauthorized changes were made outside of the defined process.
The sprint concludes, and a new cycle begins.
By following this process, your team can effectively manage their development workflow within the context of sprints, utilizing feature branches, multiple testing and staging environments, and controlled merging into the release and master branches.
Ensuring Team Adoption and Collaboration
Now let's address the second major hurdle in adopting version control, which is the people challenge. In order for any change to be successful, the new approach must demonstrate clear benefits; otherwise, team members may revert to their familiar way of working. The adoption of version control often presents a people challenge due to the following reasons:
Familiarity with the current workflow: Team members who have been solely working with Salesforce may find Git to be a significant change. It introduces a new tool with its own terminology and processes. Moreover, it requires a closer understanding of the underlying XML that defines Salesforce orgs, which may be unfamiliar to many team members. Initially, individuals not accustomed to Git might face a learning curve. However, it's important to note that becoming proficient in version control doesn't necessarily require admins to be familiar with command-line interfaces, and there is no need to spend time mastering complex Git commands.
Lack of familiarity with Git and perceived entry barrier: Most Git providers offer user-friendly interfaces for common actions, and tools like Gearset enable deployment between Salesforce orgs and version control without the need for command-line interfaces. Reducing the perceived barrier to entry is crucial in gaining buy-in from the team.
Complexity of branching strategies: Introducing a completely new workflow all at once can be challenging. To overcome this, it can be beneficial to run a pilot or establish a center of excellence that advocates for the new process. Additionally, it's important to keep the process as simple as possible. While it may be tempting to replicate the current release workflow in Git or account for every edge case, this can result in an overly complex process that is difficult for team members to grasp.
Regardless of the chosen workflow, it is essential to ensure that the team starts experiencing the benefits from the beginning. This allows the team to gain confidence in the improvements and understand that the initial disruption is worthwhile.