Branching strategy - Release Isolation With Continuous Deployments / Integration?

Question

I have been creating builds and releases for the last 2.5 years (also with rm 13) using TFS and RM.

Recently , I tried to embed the 'Branching by Quality' pattern for Branching strategy in our Company. we need hot-fix merge, sprint merging , bug fix merge in our development process. Branching by Quality Pattern Here is a small example :

We can agree that uploading a hot fix to test environment before production will mix all new features currently being tested by qa with the small urgent hot-fix we want , so the code is dirty. Sitting down with smart people, we almost came up with this pattern , so when i stumbled into this pattern I thought it will match us very good and for our continuous deployments and integration , since the merges to each branch (main\dev , test , prod) were going to the right environment and the branches were stable and permanent ,and took no maintenance effort from my department (devops) . We only add more builds and releases upon these branches for more applications we want to automate .

An external consultants company which consults us , and who is promoting Scrum as well, has another thing in mind . I cannot understand the motivation yet ,so maybe someone can assist or contradict what I or the consultant offer in our case (not a competition , just trying to attach the solution to real life in my company) . He sent the following urls : Branching strategies with TFVC

Followed by another reference :

Effective TFVC branching strategies for DevOps

In Short - it is offered that we create an v1.0 and our release pipeline (ci cd) on the new branch.this will always alter and we would change the pipeline on each release (v2.0 , v50.0 and so on).

I went through a lot of articles saying Feature branch strategies are not working well with Continuous Integration - clear enough , release Isolation proposes each release to be on a new branch , kind of resembles the feature branch , we should hope that a release will last 2-3 weeks the most to merge it to main branch. I just cannot see how it can be automated , how it supports hot fixes automation (hot-fix the previous branch will make us change all our builds to work with that branch) and I will show what I mean.

I'm using TFS 2015 with Release Management to perform continuous integration builds and releases all our code is .Net , on windows . and so , we have a branch which is used for continuous integrations , and has triggers on it. I want to mention that in my company we have more than 30 (and increasing) builds and releases for our services, we have above 200 apps so we automated the most urgent ones , and we strive to automate more and more .

the offered solution in the links I added above (consultant shared them) is to create a release pipeline each time there is a new release (working in scrum every 2-3 weeks) mind that in TFS Build , there are specific references to a branch which should be built (sources and triggers) , this means that each release we will have to change all the branches names in sources and triggers and main sln \csproj to the name of the release branch (r12 for example) . this will vary from one project to another since not all of them will have the same release branch name (some will be r5\ r20 for example) , so you cannot just automatically override your branch names of the builds of each different application .

Though it is written as if this type of branching strategy supports tfvc for devops & continuous delivery , it seems like a hard redundant task , to run around changing release branch names for all our automated applications EACH RELEASE.. This seems like an awful lot of unnecessary work , for no great obviouse advantage - to me of course . The consultant , was confident that his solution is much better and advanced, Visual Studio web site shows this solution while using the word 'Continuous' in the same article! In Addition , our department is pretty small with a lot of other stuff on our hands , can anyone help me see what i'm not seeing ?

This is the changing process we have to do in each release :

Note that triggers are not cloneable in tfs 2015 builds .

Please mind That I would like to please request an elegant , not-a-hack ,prove-to-work (even in theory , that's fine) solution to this issue , and if it means we have to code a workaround, it is considered an addition of point of failure , and maintenance from my experience .

Thanks !

Answer 1

Your question is too board, and maybe a little subjective. There's no commonly agreed "best" branching strategy applicable to any project most resources seem to agree that choosing productive strategy depends on the particular project specifics side note.

According to this it looks like any changes to project branching strategy need to be tested, measured and compared to other options tested.

You didn't mentioned such clear how will you handle the release in your first solution. Whether production releases originate from trunk/main or branches. According to most other's experience on the google:

Doing prod releases from trunk are essentially prohibited to use unstable trunk strategy. Teams doing prod releases from branches have more branching options to choose from.

Besides, about the hotfix and automated in your consultant shared. Usually we create the release branch when we are "feature complete," and plan to fix last-minute issues on this code line. As the tutorial and screenshot above, it looks like the process is branching off a release when you need to create a bug fix for already released code. Which may no need to fix every previous branch in this case.