Branching Strategies for Salesforce

Join us to learn about Effective branching strategies for Salesforce Developers. In this session I’ll be looking at some of the common branching strategies used by Salesforce developers that have adopted source control as part of their DevOps strategy. We’ll look at why the choice of Branching Strategy is important, and how you can choose one that best fits your way of working.

While we won’t be covering every approach there is, we’ll go over some of the most common ones we see, before comparing the pros and cons of each approach in a summary. Finally, We’ll leave you with ways in which to expand your knowledge in this area.

Why do I need a branching strategy?

Since version control is such a fundamental building block of any DevOps architecture, Salesforce or otherwise, it’s important to select a branching model that fits our needs as a business and as a team delivering change to that business.  A branching strategy sets your Salesforce DevOps process up for success in a number of ways.

It helps define how each change is handled by the team and thus ensures the team follows a common approach. This helps reduce the complexity of change control and deployments, since changes move between environments for specific reasons – bug fix, UAT as part of a sprint, a release to prod. It contributes to the efficiency and accuracy of your process by fostering better team collaboration both within your team and across other teams in some cases.

The branching strategy we select both shapes, and is shaped by, factors such as team size, the team’s technical level and/or experience with source control, our desired release cadence of changes and more. It’s therefore important that we endeavor to select a model that takes in these considerations. In this session, We will show you some common approaches we’ve seen across many teams of all sizes. Hopefully one will resonate with you as an approach to bringing your Salesforce DevOps to life.

Version Control

Over the past few years, as the Salesforce platform has continued to mature and offer more complex functionality, it’s become apparent that version control is an increasingly key tool for every Salesforce team, and we’ve seen the transition to source-driven workflows become more common – from our recent state of Salesforce DevOps report that surveyed over 500 Salesforce teams, we found that 70% of them were already using version control in one form or another.

Fundamentally, version control provides a structure for tracking changes to files over time. Those files can be text documents, source code, or Salesforce metadata. What that gives you is a complete history of any change, to any file, at any time, by anyone, and a much greater level of insight that you get through Salesforce natively.

There are many flavors of version control out there, but the de facto standard for Salesforce is git. Git provides teams with the ability to separate out multiple streams of development and avoid stepping on each others’ toes by making changes in isolated branches, instead of in shared sandboxes. 

What is Git?

Git also provides a shared source of truth for all code changes. Each repository has a main or master branch, which holds the current “production ready” versions of all files. By having everyone work from this single starting point, and tracking all changes across the codebase, it’s easy for teams to have a shared understanding of what’s approved and reduce the chances of code duplication.

• Git provides a structured way to review changes via pull requests and integrate them back together before release, as well as dealing with any conflicts that may arise.
• Continuous integration, and as a result continuous delivery, is built on top of version control – it’s not possible without it. So version control is completely foundational to any DevOps process.

To get started with git, you’ll need to pick a hosting provider. The majority of teams are happy with hosted options like GitHub, or Bitbucket, or GitLab, but there’s also the option to self-host, either with a self-hosted offering from one of the major providers, or by actually hosting the repo yourself.

Branching strategies

So, coming back to Branching Strategies for Salesforce, we can define them as “A set of conventions or rules for how you use and manage branches when developing features in source control”. Let see how to Choosing the best Git branching strategy.

Team size

Larger teams are more likely to have a larger variety of roles who need to interact with the source control strategy, and this may have an impact on which model is right for you.

Team structure/ Complexity

More complex models will take longer for newer and less technical members of the team to get their heads around.

Desired release cadence

There can be business reasons that dictate a particular release cycle. Branching strategy allows you to manage those requirements.

Current workflow

In many ways, switching to using version control is an opportunity to reshape your workflow. Starting with a branching strategy that more closely resembles your existing workflow. How your environments are set up ( ex: how many Sandbox)? How these environments correspond to your branches?

Different Type of Branching Strategies

Let see the different type of branching strategies for Salesforce.

1. Git as a backup

This strategy is often the first step teams take into version controlling their metadata. They set up one branch per environment, and start pushing metadata from their orgs into the branches, often with an automated CI job.

Whilst this is a decent first step into getting metadata into Git, it’s not really source control driven development. Source control is not acting as a source of truth here, just a record of the changes that have happened. To be clear, this is still useful – but to get most of the benefits of Git you need to flip the flow of changes so that changes start in source control and get deployed to environments from there.

For example, in this flow you can’t easily accommodate parallel development streams on multiple features, or easily integrate peer review into the workflow. And because you’re not regularly deploying from source control into your environments, you probably won’t have confidence that you could roll back a release by deploying an older revision from source control.

Version control is first and foremost designed to help teams create, track and deploy new features. It shouldn’t be seen as a full backup of your Salesforce environments for disaster recovery purposes – there are solutions geared towards that available.

2. Feature branch model

This is the simplest model, and also the one we recommend as a good starting point.  With a feature branch strategy, the latest version of your metadata is stored on the master branch, and it should ideally always be in a state that’s ready to release. This is your only long-lived, permanent branch. When someone wants to develop a feature or a fix, they create a new branch from master, and work on that branch. Once the feature is done, the branch is merged back into master.

Ideally, in this model, feature branches should be as short-lived as possible and deleted after use for general tidiness. Larger features should be sliced into smaller deliverables and implemented one at a time. This reduces the length of the feedback cycle, and reduces the chance of merge conflicts.

The master branch is usually deployed automatically to a staging environment whenever it is updated, using a CI process. This means that the latest version is always available for testing on the staging environment. Once you’re happy with the version on staging, a manual deployment from `master` to the production environment releases the changes to your end users. Optionally, before deployment to production, you could deploy to a UAT or QA environment for further testing.

3. Protected Master Branch

This strategy is similar to the feature branch model, but adds one long-lived branch for integration, before merging into master. In this model, the master branch isn’t updated until everything is tested and ready to go. Master is a more protected source of truth, as only work that has been fully tested in UAT makes it into the branch.

One drawback with this model is that it’s not possible to propagate just a subset of changes if some others aren’t ready yet. If some work has all been tested and approved in UAT, but other things aren’t good to go yet, you can’t easily cherry pick what to promote to master. You’d need to revert features that aren’t ready from the release branch. So a lot of the teams don’t like this model because of the inflexibility to pull changes.

4. Expanded branching model

This model adds a few extra long-lived branches which correspond to your integration and UAT/QA environments.Once a feature branch is complete, rather than merge straight into master, it is merged into your integration branch. To promote any changes from there that you’re happy with, you would merge into the UAT branch, and then onwards into `master`.

• This model allows more fine grained control of which changes get through to each environment.
• Allows for better isolated review of changes on a per-request basis
• better for slower paced dev streams where releases happen less frequently.

Comparing the approaches

So let’s recap and summarise across those four approaches.

• Git as a backup is pretty self explanatory, we’re using it as a mechanism to save our metadata off-platform, which allows us to revert changes – although this is not easy if the change is several Git commits back and there are deep chains of dependencies. It also doesn’t deliver any of the main benefits of a source-driven development approach
• The feature branch model is great for teams that rapidly iterate – we use it ourselves internally and it allows us to deliver changes daily, or often more frequently than that. If you’re process requires more stage-gates and checks along the way, this may not work for your longer dev cycles.
• The protected master branch model has multiple testing environments and an integration branch to support them means that your primary Master or Main branch is the source of truth, but this model still acts as a queue, where items requiring longer test cycles can hold up other changes until promoted
• The expanded branch model allows for a more asynchronous approach to changes, with individual pieces of work that can be moved through the environments, which allows for questions in the style of “Bob, where are we with JIRA 34533?” to be answered accurately in the style of “it’s in UAT awaiting sign-off for release to Production, Sarah”

Effective branching strategies for Salesforce Developers Video

Where can I learn more?

I appreciate that this has been very much a whistles top tour of a few branching strategies, so if you’d like to learn more about the topic at your own pace, sign up for free at devopslaunchpad.com where you’ll find a module on Git branching strategies and many more topics, all completely free of charge. There’s also a brand new DevOps Fundamentals certification path, resulting in a digital certificate to share on your social media to demonstrate your knowledge.