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.
 |
| Fig1:Change Sets Design: Types Of Salesforce Org In SFDC247 |
 |
| 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.
 |
| 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.
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.
 |
| Fig4: Types Of Salesforce Org And Git Branches |
I have given you a detailed diagram of the git flow and salesforce
 |
| Fig5: Salesforce SFDC247 Git Branch Flow |
 |
| Fig6: Salesforce Metadata Release Management Process/Flow |
Things You Didn’t Know About Salesforce Release Management Process Which We have Not Discussed In Our Salesforce Release Management Strategy.
- 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)
- 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 😎
- 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.
- 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.
- 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.
- What about salesforce dx branching strategy–> I will discuss this in future posts.
#Note: Publishing this content anywhere without consent of SFDC247 will result in lawsuit against copyright infringement
Your knowledge of dresses really impressed me. I really Like your suggestions.it's really helpful for me and everyone.
Platform For Public Speaking In Canada
Your article is very interesting and I really enjoyed reading it.Thanks for sharing this article here. Change management strategy
It is really a great work and the way in which you are sharing the knowledge is excellent.Thanks for your informative article
CRM Software
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