Salesforce Branching Strategies

Let’s talk about Salesforce Branching Strategies. I learnt a lot from these two Sessions:

1. Session by Rob Cowell (DevOps Advocate from Gearset) - Youtube Link

2. Session by Pablo Gonzalez (Salto DevOps Architect) - Youtube Link

I will be summarizing my learnings from these sessions in my post. Contributions like these, makes Salesforce Ecosystem stronger and encourages others to give back.

But before we explore Salesforce Ecosystem specific branching strategies, it’s important to understand Industry Terms and Industry classification of Branching Strategies.

Types of Common Industry Branching Strategies:

1. Trunk-Based Development

2. GitHub Flow (aka Feature Branches)

3. Forking Strategy (Applicable for Open Source Development)

4. Release Branches

5. Git Flow

6. Environment Branches

OPTION 0: Git as a Backup

Git as a Backup. This is not really a Branching Strategy. Instead, this method uses Git exclusively for backing up Metadata. Here we push Metadata from Org to respective branches using Continuous Integration (Automated Jobs) using tools such as Gearset, Copado etc. Usually this is the first step when introducing Git into Developer ecosystem.

NOTE: This is not source control driven development as Git is not acting as source of truth.

Git as Backup

OPTION 1: Trunk Based Development

Trunk Based Development: Here we have a single branch. It is also referred as Main (or) Trunk (or) Master Branch. All Developers start with cloning Master/Trunk/Main branch, make changes to this branch Locally and push changes directly to the Main Branch.

There are no Branches, no Pull-Requests - Only rapid merges to the Main Branch. It is one of the easiest branching strategies of all.

It is important to note that this strategy might require “Feature Toggles” as there is only one Main branch. It is also only applicable for teams with High Maturity and pushing changes frequently.

Trunk based Development

OPTION 2: Github Flow (aka Introducing Feature Branches)

Github Flow: This is also a Simple Branching Model, also recommend this model as a good starting point.

The Latest version of the metadata is stored in the Main Branch and it should always be in the state of release. This is considered as “Long Live Branch”.

If someone wants to develop a new feature or fix, they create a new Branch from Main and work on that Branch. Once the feature is done, the branch is merged back into the Main Branch.

In general, Feature Branch should be short-lived as possible and deleted for general tidiness.
The Main branch is usually deployed automatically to environment whenever it is updated, using a CI Process. This means that the latest version is always available in Salesforce Environment (QA or UAT Environment).

Once satisfied with latest version, a manual deployment from Main Branch to Production Environment will release your changes to End Users.

Github Flow for Salesforce DevOps

OPTION 3: Forking Strategy
I am skipping Option 3 (Forking Strategy) as they mostly apply to Open Source Development.

OPTION 4: Release Branches

Release Branches: Introducing Release Branches. Unlike feature branches, release branches are long lived (Say Months). Different team can be working on different releases, so we have branch for each release.

Release Branching usually associated to Low frequency deployments. And it is usually works well with “Waterfall” development Methodology. Drawbacks include high probability of merge conflicts due to delayed integration. There is no continuous Integration when we are adopting Release Branches.

This strategy is usually not recommended for Salesforce Development. (May be useful in situations where a Software Vendor may need to support multiple versions of package simultaneously).

Release Branches - Salesforce DevOps

OPTION 5: Git Flow

Git Flow: In this Strategy, you have your Main Branch, which represents Production Metadata. Here we assume that we work in Sprints (or some iteration which are time-boxed). Typically we create a Development Branch out of Main Branch.

Then we create Feature Branches out of Development Branch. Here each feature branch should ideally represent User Stories within given Sprint. Developers merge back all features which passes unit test back to Development Branch.

Now Development branch can now be merged back into Main Branch (or) merged into another Release Branch. This strategy is commonly referred as “Git Flow with Release Branch”.

When we are ready to release, we cherry-pick some of the release features from Develop Branch into Release branch and get merged to Main Branch.

Git Flow Strategy for Salesforce DevOps

This flow is also referred to as Protected Branch Model according to Gearset.

OPTION 6: Org Based Branching Strategy

This is the most complex Branching Strategy. Here we would represent 1 dedicated Git Branch for each Salesforce Sandbox.
We would have Release/Merge Branch, UAT Branch and Main Branch (Production). This branching strategy was popularized by Copado.

If we do use this strategy, we would need tools like Copado or Gearset or Salto or anyother tools to manage the complexity for you.

This Strategy typically includes Feature Branches, Develop Branch (Merge Branch), Release Branches AND dedicated Git branches for each Environment.
It is also referred as “Expanded Branching Model” according to Gearset.

I generally do not recommend this as complexity is the enemy of execution.

Org Based Branching Strategy

KEY TAKEAWAYS:

1. There can be “n” number of combinations to create unique Branching Strategy.

   1. With (or) Without Feature Branches

   2. With (or) Without Develop Branch

   3. With (or) Without (n) Release Branches

   4. With (or) Without 1:1 Dedicated Org Branches

   5. With (or) Without HotFix Branch

2. Architects are recommended to prioritize simplicity when designing Branching Strategy.

3. For most Salesforce implementation GitFlow or GithubFlow Branching model should suffice.