Skip to main content

A Guide To Salesforce Feature And Parallel Branching Strategy For Enterprise Customers

The version control and release management branching strategy of salesforce for an enterprise solution is quite complicated when it is compared to Changesets or VSTS with CI Tools. In the last article, we have discussed salesforce git branching strategies which can be adopted in the current project of the salesforce. But Frankly speaking, even if you read my blog or any other blog the success rate of any salesforce branching strategy depends on the current branching model that you have adopted in your project. In this article, we will discuss advanced branching strategy for enterprise customers.

Read My Previous Post: The Roles And Responsibilities Of Release Manager / Code GateKeepers In Salesforce.

The advanced branching strategy is also known as the feature branching strategy as well as parallel branching strategy. Feature branching strategy in combination with parallel branching strategy is being used by many enterprise clients. It is also considered as a successful branching strategy for continuous delivery. But, there is also a drawback when you adopt this model is merging the branches. Always ask one question to yourself "How often you merge ?"

Let's talk about the problem statement, consider that SFDC247 is an enterprise company have hired an expert to change the current model of branching strategy to the most successful as well as advanced git version control branching strategy.

Let's talk about in detail and understand how we can implement Feature And Parallel Branching Strategy in our current project. In SFDC247 we focus more on fundamentals so that our base is strong and once our base is strong with feature branching you don't need to hire any specialist you can create your own Salesforce branching strategy and implement it on your project.

Feature And Parallel Branching Strategy For Salesforce Enterprise Customers

Let's talk about some basic scenarios which are being adopted in many salesforce projects with an enterprise customer in mind and different types of branches that we will be using for this model.

Scenarios For SFDC247 Type: Sandbox Environment and Number Of Developer's

Scenario 1: Projects Using One Developer and One Sandbox.

There might be some projects who would be using 1 developer and 1 sandbox, in this case, I would recommend you to use changesets.

#Note: By one sandbox I mean one developer sandbox but it also includes staging as well as preprod sandbox.

Scenario 2: Projects Using N Developers and N sandboxes.

For many enterprise projects, we would be using many developers and all of them would be working together to develop new advanced features and all of the developers would be using many development sandboxes including staging as well as PreProd.

For both the above scenarios we will be using many branches and let's look at those branches that we would be using in our current Feature and Parallel Branching Strategy for enterprise customers.

Types of branches in Feature and Parallel Branching Strategy

Feature Branch: The branch which is used to develop user stories or new requirements is called a feature branch.

Developer Branch: The branch where all the feature branches will be merged to develop whole business requirements.

Hot Fix Branch: The branch which is used to debug and resolve user stories issues which have occurred after deployment in Production.

Staging Branch: The staging branch is a full copy of the master branch and used for testing purpose.

PreProd Branch: The branch is also a full copy of the master branch and it can be also used for testing purpose, before deploying your metadata components to Production Instance.

Master Branch: The latest released version of the feature which went go Live for the end-users.

Tagging: It is a label that you attach to a branch once the new release has been deployed to production.

Most of the companies do not use preprod branch because staging, preprod is a full copy of the master branch, so they directly deploy changes from staging to master branch/Production environment.

Step1: Hence, as you can see from the below image we have different feature branches Feature Branch 1, Feature Branch 2, Feature Branch 3, Feature Branch 4, Feature Branch 5 which is being used by several developers and all the developers are working on several user stories/business requirement.

Step2: Once all the SFDC247 Developers commit there changes via IDE via all the feature branches then it has to be merged by the release manager.

#Note: You can see my previous post regarding IDE and how developers commit their changes, hence, I won't be able to explain you in detail. Please go to my previous post Salesforce-Release-Management-And-Version-Control-Branching-Strategy

Parallel Branching, Feature Branching, Version Control Branching Strategy, Enterprise Salesforce Customers
Feature And Parallel Branching Strategy For Salesforce Enterprise Customers

Step3: Once the release manager has merged all the feature branches then it will be committed to developer branch and from the developer branch all the metadata components will be deployed to the developer sandbox.

Step4: Similarly release manager will merge the developer branch to the staging branch and from the staging branch it will be merged to staging sandbox.

Step5: After merging into sandbox branch we have two options First option is to merge your staging branch into preprod branch which is shown in the above figure then it will be deployed to preprod sandbox environment.

Step6: The another approach of deploying the metadata components is from the staging branch. Once we have merged everything to staging branch from there you can directly deploy your changes to preprod environment and production environment by configuring CI Jobs in the back-end. The below diagram explains everything Then, we can do a baseline from the production environment to the master branch.

Salesforce Feature Branching Strategy, Salesforce Parallel Branching Strategy, Salesforce Guide For Feature and parallel branching strategy
Salesforce Feature And Parallel Branching Strategy For Enterprise Customers Without PreProd Branch

Step7: The second last step is to create a label in terms of git it is known as tagging. Hence you can tag your version within your master branch.
#Note: Always follow a good naming convention within your project.

Step8: The last step is to have a perfect backup plan in case anything goes wrong. So, we have created a hotfix branch from the Master Branch. Thus, once you have fixed everything in your hotfix branch you can again deploy it to Production and from there you can again merge to master branch.

Thus, I would like to end my post here by saying that I have tried my best in explaining to you the best Salesforce feature and parallel branching strategy for Enterprise Customers. Thus you can always comment and contact me in case you would like to adopt the best strategy for your clients.

#Note: Publishing this content anywhere without the consent of SFDC247 will result in a lawsuit against copyright infringement


  1. Thanks for the post, it is very helpful. One question, For feature branch , do we have entire repository or only the objects that we are going to change in the feature branch?


Post a Comment

Popular posts from this blog

Flosum Vs AutoRabit Vs Copado : Best Salesforce DevOps Release Management Tool

Are you still using changesets or you have moved from changesets to salesforce ant migration tool? Salesforce has again introduced SFDX which supports the source of truth known as Git. Are you using SFDX or still planning to move ahead of salesforce DX to salesforce app exchange products. If yes, then you have come to the right place and I will introduce you to 3 major competitors of salesforce release management which gives you end to end salesforce release management solution to your needs. I have a lot of experience of working with each of these tools and I must say that each one of them is full of amazing features. So, today, I am not going to dig in detail about each product because it would require a lot of commitment to do it, but I would share my knowledge on why each one of them is unique in itself. Topics To Discuss On Also Read: Just

Salesforce Release Management And Version Control Branching Strategy Using Git

Release branching strategy is comprised of three unique words "Release" it means a go Live of your business requirement, second is "Branching" also known as  salesforce version control using git which is not a salesforce terminology but these days we are using it in Salesforce DX , generally it refers to the Git version control tool and the branches (feature branch, developer branch, staging branch, preprod branch and master branch) that you create in a repository. In short, is used for versioning and history tracking for your changes that you have done via tools like Jenkins, Flosum , AutoRABIT, Copado , Gearset or any other IDE which is used to deploy your salesforce metadata components to Sandbox organization. The third-word " Strategy " which is a mixture of Release and branching. It means that how we can merge Salesforce release process with salesforce version control branching to deploy metadata components in salesforce environment in the best way

Top 5 Best Data Backup And Recovery Tools For Salesforce

Do you know salesforce will stop giving its premium service of Data Recovery in case of Data Loss from 31st July 2020? We came to know about its service when we logged a data recovery case with Salesforce support team and they told us that we can recover your lost data but it will take maximum duration of  6 weeks to 8 weeks. Then we came to know the recent announcement made by salesforce. In this article, I will focus my discussion on the Top 5 best data backup and recovery tools for Salesforce that we will have once this data recovery service will be retired by salesforce. Topics To Discuss On Salesforce Data Vs Metadata In order to understand this, article in detail, first, we need to understand the difference between Salesforce Data as well as Salesforce Metadata. Salesforce Data: It refers to the records stored in our standard and custom objects. All the records in salesforce are referred by a datatype known as ID. Data are like a spreadsheet where values are

Top 8 Salesforce Login Extension To Store Salesforce Org Credentials

Salesforce login extensions will store your multiple salesforce/ org credentials and allow you to log in quickly to your salesforce environment with one single click. It will authenticate your credential and open them in a default browser window. There are many salesforce login extensions which will save your time in storing those credentials and increase your productivity of work ☺. Why Developer/Release Manager/Business Analyst should use Salesforce login Extensions? Let us consider that I am a release manager and daily I have to log in around 10 different salesforce org and for all these orgs I have to memorize there login id and password. There are many occasions where I have to reset my password. Considering these issues/situations, I need a different approach to store all my credentials. Hence, I can choose salesforce login extensions and can open all these 10 orgs at the same point of time and with very minimal memory utilization of remembering salesf

Salesforce Managed vs UnManaged vs Package.xml - A complete Guide

Salesforce provides us with two types of the package in salesforce managed package and unmanaged package. A salesforce package is a list of metadata components which are tightly coupled with all the dependent components. We can use this salesforce package in many ways like deploying them from one Salesforce organization to another. We can also install these packages in our organization and assign them to users. Also Read:   What is Environment, Sandbox, Types Of Sandbox And How To Create Sandbox From Production Salesforce package is the list of metadata components tightly coupled with all the dependent components in the form of a box or container. There are two types of salesforce package Unmanaged Package and Managed Package . Salesforce package.xml contains the list of metadata components in an XML file format. We can retrieve and deploy metadata components using package.xml. Salesforce Topics Of Discussion So, please don’t get confused with salesforce pack

What Are Roles, Duties And Responsibilities Of Release Manager / Code GateKeepers In Salesforce

Salesforce as a whole is a very diverse company and there are many job openings in market if you are working in any salesforce domain whether it is Salesforce CPQ, Salesforce SaaS Platform, Salesforce, Pardot, Analytics, Einstein the list goes on and on.. But, In this article, we are going to primarily focus on the roles and responsibilities of that salesforce release manager or code gatekeepers should possess to perform activities related to deployment in Salesforce. A Good Release Manager Must And Should Be A Core Salesforce Developer, So that he can deploy quality code in production - Nitendra Shukla ( SFDC247.COM ) I know most of you will not agree with the statement that I have made above but it is my thinking that a good salesforce developer understands what is quality code and he will ensure that we are not deploying bad code in Production. Anyways this is not our topic of discussion today and we need to focus on the roles and responsibilities of a release manage

What is Environment, Sandbox, Types Of Sandbox And How To Create Sandbox From Production

Salesforce is known as the world's number one CRM and has been recognized by global leaders all over the world. Salesforce as a platform provides main support for SAAS and PAAS services. SAAS means software as a service and it provides salesforce services on rent based on per user/licence edition you purchase.  PAAS means platform as a service and you take as platform to customize your application but both these services needs salesforce environments so that developers can perform there metadata changes and write code with respect to there business requirement. Thus, In this article we will in discuss about S alesforce Environments . Contents Environment In Salesforce:  Environments in salesforce is an instance of the salesforce platform.It is also known as orgs or organization in salesforce. If someone is talking about orgs it means that he is talking about Environments in salesforce. There are many functionalities as well as features

An Ultimate List Of Top 200+ Salesforce Blogs On Web

An Ultimate List Of Top 200+ Salesforce Blogs On Web Salesforce Trailhead is the most loving and funny way to learn salesforce. It has many modules like salesforce apex, salesforce admin, salesforce development and many more. If you are the one who wants to learn salesforce then you must follow this trailhead link . But if you are the one who also learns salesforce from blogs then I have curated An Ultimate List Of 200+ Salesforce Blogs On Web Thus the second step to learn salesforce is by following bloggers, who are writing informative posts each and every day. These bloggers not only support overall salesforce community but also help users who are facing issues in salesforce lightning , salesforce admin or salesforce development . List of 200+ Salesforce Blogs Read Also: Hence, I have created an ultimate list of Top 200+ salesforce blogs in alphabetical order and this l

What Is SFDC247 And Why It Is Important To Understand Salesforce Release Management Process ?

Which is the best release management tool in salesforce? How code gatekeepers or release managers deploy the changes from one sandbox to another sandbox or in Production? What is the best release branching strategy we can adopt for our project in Salesforce? What are the roles and responsibilities of release managers? There are several such questions which we have in our project during our deployment life cycle phase and these questions must and should be discussed properly with salesforce architects or experienced core developers or release engineers. Salesforce SFDC247 Introduction Are You Having Issues When You Deploy Your Code Into Production? We try to follow the best practice approach proposed by Salesforce during the deployment of code from one sandbox to another or in production but still, we are having a lot of issues during merging of code from several developers. The functionality does not work in production as we are not doing proper testing during our deploy