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 with respect to the current model that we have adopted in our current project.

Summary of Salesforce Release and version control Branching Process In Salesforce

Release: The best/worst day that you pick to deploy your salesforce metadata components. Why worst !!!😤 because after deployment something can go wrong in production and you should be ready with your salesforce rollback strategy plan which you would have adopted within your project.

Branching: The salesforce business requirement OR the new feature that you build for the project and commit your changes to the respective branch which is assigned to the respective developer.

Strategy: How to adopt best SWOT Analysis Technique to deploy your components in production without any risk and failure and I have already discussed some of the strategies in my previous post. Even if the failure occurs what is the best rollback strategy plan for salesforce that you can adopt to minimize failures from occurring again and again.

After talking about basic definitions its time to focus on release branching and version control strategies in salesforce which I have used in past and also I would love to take your opinion, on how we can improve these strategies, so that it can help other release managers. I will be categorizing my strategies based on the deployment of metadata components in the Salesforce organization.

Weird But Effective Salesforce Release Management Branching Strategy

Deployment Strategy without change sets:

Deployment strategy without change sets is also known as the worst strategy. Let us consider the current situation in which most of us are using change sets to deploy metadata components from one organisation to another organisation.

Situation: Let us say SFDC247 have several salesforce org and we are using change sets to deploy salesforce metadata components and we have configured deployment settings, inbound and outbound changes in current project.

As you can see from the below diagram we have several salesforce orgs such as  DevOps_DevOrg, DevOps_QaOrg, DevOps_UATOrg, DevOps_PreProdOrg and Production.

Change Sets, Salesforce Org, Salesforce Developemt Editions
Fig1:Change Sets Design: Types Of Salesforce Org In SFDC247
change sets salesforce, Change sets, salesforce source control
Fig2:Change Sets Zig Zag Design For Salesforce Deployment  In SFDC247

Current Scenario Of Deployment: SFDC247 Developers deploy there changes from DevOps_DevOrg –> DevOps_QaOrg –> DevOps_UATOrg –> DevOps_PreProdOrg –>Production.

#Note: They can also deploy their changes to any other org based on the deployment settings that they have configured in their project. For example, a release manager can deploy its changes from DevOps_DevOrg –> Production (Please never do it 💣)

Limitations of this approach: Deploying salesforce changes from one org to another org without version control means that you don’t have the track of the changes that were deployed to respective salesforce org. I am going to discuss in detail about change sets and its limitation in different posts.

Before talking about the second approach we need to talk about advanced level concepts of git such as git commit and git merge. I think you are feeling scared 😨 well you don’t need to be, as we are not going to talk about these concepts but they are an important part of the strategy that we are going to discuss in the below article.

Stages Of Salesforce Metadata Deployments

It is very important to understand the stages of salesforce metadata deployments which are given in the below diagram. I am going to write a separate post regarding the stages of salesforce metadata deployment. As you can see from the below diagram we are using an IDE to commit our changes using git to our branch within a repository and if we have configured webHooks then it will be triggered based on the commit which has been done on the branch and from there it will trigger our CI Jobs like Jenkins/Circle CI and ultimately it will be deployed to your salesforce environment.

salesforce releases, salesforce release management, salesforce release manager best practicessalesforce release manager best practices
Fig3: Stages Of Salesforce Release Management Process

Below are the definitions of the technical terms which would be used in our strategy.

  • Git commit: Consider like you have developed one feature and changed one apex class then you can push your changes to the respective branch that has been allotted to you with respect to the salesforce org.
  • Git merge: To integrate changes from one branch to another branch. For eg dev branch can be merged with uat branch. Merging is a really important part of salesforce release management.
  • IDE: An environment which is used to commit your changes. Example of IDE is Visual Studio.

Once we have a good understanding of the above fundamentals we can go for our second strategy.

Strategy 2: Release Branching Strategy by using a version control tool known as Git.

To understand this strategy we have to think in terms of salesforce release application lifecycle management and salesforce release schedule that you follow in your project.

Situation: SFDC247 have several developers who are working on different features of a project, hence they need different sandboxes, which we have to refresh from production. So, SFDC247 release manager has refreshed four sandboxes and named as Devops_Dev1, Devops_Dev2, Devops_Dev3, Devops_Dev4 and similarly he has created Qa Sandboxes and named as Devops_Qa1, Devops_Qa2, Devops_Qa3, Devops_Qa4, UAT, PreProd and Production Environment.

#Note: Always follow a good salesforce naming convention so that it can help you to differentiate between salesforce environments.
salesforce releases, release management process, salesforce code repository, salesforce release management best practices
Fig4: Types Of Salesforce Org And Git Branches
Strategy Adopted: We also have git branches assigned to Development Orgs including UAT, PreProd and Production.

#Note: We should not assign any git branch to Qa Orgs with this approach.
Strategy Followed: Developers will commit there changes via IDE to there dev branches and release managers will merge (can use cherry-pick or rebase) an entire branch with staging. Similarly, release managers will merge changes to the pre-prod branch and then we can directly push our changes using CI-CD pipeline via Jenkins/Circle CI to our production org.

I have given you a detailed diagram of the git flow and salesforce

salesforce continuous delivery, sdlc git, salesforce dx and git
Fig5: Salesforce SFDC247 Git Branch Flow
salesforce releases, salesforce deployment using git, salesforce and git, salesforce continuous delivery
Fig6: Salesforce Metadata  Release Management Process/Flow
But note that you have to make your master branch synchronized with production org.
Finally, You will be able to deploy your changes to production org and if any bug occurs, you have to raise a ticket in ALM tool by following salesforce sdlc process and then deploy that bug in a sequential flow as mentioned in the above salesforce release management process.

Things You Didn’t Know About Salesforce Release Management Process Which We have Not Discussed In Our Salesforce Release Management Strategy.

  1. If we don’t have several developer salesforce environments in that case what is the best strategy–> feature branch strategy (I will discuss this later in another post)
  2. How we can ensure that merging is done perfectly by our release manager–>, To be frank, the best release manager knows how to do this, so you don’t have to worry 😎
  3. You have not discussed hotfix or if any bug occurs what we have to do–> Good Question, I would always suggest you create a hotfix branch from the master branch and deploy changes immediately. But, as per my thinking this is not the best approach, I would create a bug in ALM Life cycle management and would ask developers to fix it in the lower environment and then follow the same process mentioned in strategy 2.
  4. What about rollback strategy–> I will write a post on this how we can achieve rollback with Jenkins but its quite complicated but achievable. Secondly, we also have the app exchange managed packages in the app exchange market like Flosum, Copado, AutoRabit or Gearset that can be used to rollback your metadata components.
  5. We would like to use post-deployment/pre-deployment steps and test automation techniques with the release branching strategy–> Answer would be Flosum, Copadao, AutoRabit etc.
  6. What about salesforce dx branching strategy–> I will discuss this in future posts.
Pic Credit: Image by Vitabello from Pixabay
In the upcoming articles, I am going to discuss a feature branching strategy and other related posts.
After reading this post about salesforce release management and version control strategy you would be having many questions and I would love to hear it from you and your team. Shoot any questions that you would like to discuss with me and we can find the best release branching strategy for your project.
You can always comment, contact me on LinkedIn and I will reply back you immediately ūüôā

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



  1. I wish to show thanks to you just for bailing me out of this particular trouble.As a result of checking through the net and meeting techniques that were not productive, I thought my life was done.
    Best CRM System

Leave a Reply

Your email address will not be published. Required fields are marked *