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
 |
| 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 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
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?