A Guide to Git (and Version Control) for Salesforce Developers

Version control is the key to unlocking the advantages of a powerful DevOps process for Salesforce. It opens the door to automation, which accelerates development and release cycles to allow Salesforce teams to build, test and ship code and configuration faster. But there are common challenges that teams need to overcome before they can successfully adopt source-driven and automated workflows.

This article explains how to overcome two main hurdles to adopting version control, so your Salesforce team can see the awesome benefits of Salesforce DevOps (that are outlined in Version Control for Salesforce Admins).

The challenges of version control

The flexibility that makes version control so powerful is also the source of complexity that can make it difficult to adopt. From the largest ever State of Salesforce DevOps survey, we know that teams face various challenges at the outset when implementing version control. In essence, there are two initial challenges:

1. Finding the right process. Teams often struggle to find the right Git branching strategy.
2. Getting your team on board. There’s a people challenge that requires a change management process to get the team working effectively.

Before discussing each of these hurdles, let’s take a look at a source-driven process for Salesforce.

The feature branch model

The simplest strategy for implementing version control as a source of truth into your workflow is to use the feature branch model. This relatively simple Git model is just one of the many branching strategies that you can use with version control. But it offers your team the following key advantages over more complex branching strategies:

• Shortest lead time. This is the time between your work being finished and released to production.
• Shortest release cycle. By releasing smaller changes more often, you can tighten the feedback loop.
• Fewest number of merges. Choose the simplest branching strategy possible.

In the above model, you make your changes within a feature branch that maps to a Salesforce development environment such as a dev sandbox. After committing your work, you create a pull request to merge your changes into master – ready for testing and release to production.

Here’s where you add automation to your process. For regular deployment automation to work reliably, you need stability. Salesforce orgs are moving targets, with live configuration changes, platform updates, managed packages and end users tweaking settings. Git, by comparison, is static in nature. By using Git branches, you can isolate new features, so you can gate, approve and release changes to production in a controlled fashion. This source-driven process is a big shift away from Salesforce’s native in-org development practices.

As well as stability, the other thing you need for automation is a tool that will actually automate your processes! As there’s no native deployment automation in Salesforce, Git gives you a great framework that other tools, such as Jenkins or CircleCI, can hook into to give you that automation. Using a DevOps solution built specifically for Salesforce, you can even set it up so that your continuous integration tool will begin validating and testing new changes against your downstream orgs as soon as you commit a change or open a pull request – so your work will be ready for release in no time.

Despite the advantages of the simple feature branch model, it’s not always the right Git strategy for every team. In particular, larger teams with a greater variety of team roles and multiple use cases for different environments may benefit from a slightly more complex branching model.

Choosing the best Git branching strategy

Picking a branching strategy determines how your team will work with Git. The wrong strategy can really hamper your team’s adoption of version control, so it’s important to give it some consideration. There are five things to consider when choosing a branching strategy:

Complexity

Branching strategies range in complexity. The more complex your branching strategy, the more likely it can closely represent your current workflow. But more complex models will take longer for newer and less technical members of the team to get their heads around and often have a higher maintenance burden. At their worst, they can even result in slower releases than before, as people get caught up in the complexities of the process. So, in general, less complexity is usually better.

Team size

The size of your team can determine which strategy is best for you. Larger teams, for example, are more likely to have a greater variety of roles who need to interact with the workflow. They might also have many environments to manage, with different use cases for each, which require a little more complexity in the branching strategy. Conversely, smaller teams can often benefit from picking the simplest approach, getting up and running quickly and adapting the model in the future as they need.

Release cadence

As already mentioned, one of the most important benefits of using version control is that you can increase your release cadence. But there can be business reasons that dictate a particular release cycle – for example, regulatory sign-off or limited maintenance windows. If this is the case, you may need to alter your branching strategy to meet those requirements and move to something more complex that can accommodate the stages of approval required.

Current workflow

Switching to version control is also an opportunity to reshape your current workflow. Getting buy-in from your team is crucial. But how your environments are currently set up might also impact your choice of branching strategy. For example, you might have a whole set of testing and development environments that need to be included in your new workflow, or a long-running side project that needs to be kept up to date. Or you may want to take the opportunity to switch things up and try something new.

Ambition

Finally, not everyone needs or wants to aim for the same goal. What works well for a three-person team may not work for 300. So you need to have a good understanding of what challenges you’re trying to solve, and what a good solution looks like for you when you pick your strategy.

Branching for multiple testing and staging environments

Although there isn’t a one-size-fits-all Git branching strategy, at Gearset, we’ve found that, after speaking to thousands of Salesforce teams, the following is a model that works well for many.

The above model is broadly similar to the feature branch model, but it’s slightly more complex because it includes a number of different testing and staging environments (in this case, QA and Stage) with each org having a long-lived branch in Git mapped to it. Now, as we step through the process for this model, let’s assume your team works in sprints.

1. At the start of the sprint, you create a release branch from the master/main branch.
2. Feature branches are created by each member of your team as they begin work on each user story.
3. You then build your changes in individual dev sandboxes (and/or IDE) and periodically commit them to the feature branch.
4. When your feature is ready for QA, you open a pull request and merge the feature branch into the QA integration branch.
5. After merging any change to QA integration, your branch gets deployed to the QA sandbox, where it can be tested and signed off by your QA team.
6. Once this is complete, a PR is opened to merge the feature branch into the Stage integration branch.
7. After merging any change to Stage integration, the branch is deployed to the Stage sandbox, where it can be tested and signed off for final release to production. Depending on your workflow, you might also have UAT by end users in there for good measure.
8. Once the change is approved in Stage, the feature branch is merged into the release branch. This process then repeats itself for every change made during the sprint, with each approved feature collected in the release branch.
9. At the end of the sprint, all changes in the release branch are deployed to production and set live for your end users.
10. Once you’ve verified the new work on production, you merge the release branch back into master, so that master is once again up to date with production.
11. You’d then also want to merge master back into the integration branches, so that your branches stay in sync should any rogue changes have not followed this main process.

The sprint then ends, and a new cycle begins.

Getting teams on board

Let’s now turn to the second main hurdle to adopting version control. For any change to be effective, the new approach needs to have demonstrable benefits otherwise people on your team will go back to their familiar way of working. For this reason, adopting version control can often be a people challenge for the following reasons.

Team members are used to their current workflow

For teams who have been working solely with Salesforce, Git can be a big change. It’s a whole new tool with its own terminology and process. It also forces you to get closer to the underlying XML that defines your orgs – much more so than many people on your team may have done before. As a result, team members not familiar with Git might struggle with the learning curve at the start. But getting to grips with version control doesn’t mean admins on your team need to be familiar with a command line interface, and you don’t need to spend time learning tricky Git commands.

Lack of familiarity with Git and a perceived barrier to entry

Most Git providers offer UI-based tools for performing the most common actions, and you can deploy from Salesforce orgs to version control and vice versa without the CLI, thanks to tools such as Gearset. Reducing this barrier to entry is a key part of getting buy-in from the team.

Overly complex branching strategies can put people off

Switching wholesale to a completely new workflow all at once may be difficult, so running a pilot or building a centre of excellence to champion the new process can be a great way to help tackle this challenge.

It’s also important to keep things as simple as you can. It can be tempting to start by replicating your current release workflow in Git or trying to think about every edge case. But if you’re not careful, this can lead to an incredibly complex process that’s difficult for people to get familiar with.

Whatever workflow you decide on, it’s important to make sure that your team starts seeing benefits from the get-go. That way, your team can build the confidence that the improvement is worth the initial disruption.

Want more advice on implementing version control?

To learn more about the fundamentals of version control and other recommended branching strategies for Salesforce teams, head over to DevOps Launchpad – a free training platform with fun courses to help you master Salesforce DevOps and earn certifications. DevOps expertise is highly sought after as ever more Salesforce teams adopt streamlined processes, so now’s the time to acquire these valuable certifications.

For more on how admins and developers can share source-driven workflows, see Version Control for Salesforce Admins.