How to do a Feature Branching Strategy with TFS

Question

I'm trying to propose a new branching strategy for our company and I'm wondering if there might be any edge cases that I haven't accounted for with what I've come up with.

First, Here is our current branching strategy:

Each team has their own development branches, Team 1 and 2 are very small so they do not have a separate QA environment like Team 3. Each Team merges their changes up to Main and back down to their Development branches.

Currently I'm on Team 3, and the strategy I'm looking to replace is specifically under Team 3's section. We are cherry picking changesets from Main to INT to QA to Dev and then all the way back up again. There are no full branch merges and I'm starting to believe that every merge we do is a baseless merge due to the fact that we just cherry pick.

What I'm trying to do is eliminate the need to constantly cherry pick changesets and go back to merging entire branches, here is what I've come up with:

For long running features we will create feature branches and dev will be used to work mostly on bugs and User Stories that are meant to go to production in the next release.

There is no development done in the QA branch, we will only be merging changes up to QA from DEV when they are ready to be tested.

Once all of the tests are passed we will merge to Main and create a version branch off of main for the next release. The version branches will allow us to have a clean branch to perform hotfixes since we have multiple teams merging to main.

The hope is to utilize feature branches and shelvesets as much as possible to eliminate the need to cherrypick changesets and hopefully reduce the crazy amount of merge conflicts we are currently having.

Does this seem like a sound strategy?

Answer 1

Branching per environment is a generally bad practice. You should be building once, then deploying that build through a pipeline of environments. Every time you merge code and create a new build, you're effectively throwing out all of the testing you've done and starting from scratch.

Isolate features under development behind feature toggles. As each feature is considered 'done', merge it into Main, which starts your QA cycle. The other teams should then merge back from Main to their feature branches, in order to continue developing against the same codebase.

If a feature is deemed not-ready-for-production, disable it via the feature toggle, then you can still release the features that are ready. The later you integrate your features together, the higher the chances that someone misses a bug. Having features integrated-but-disabled helps you prove that, at the very least, the disabled feature isn't breaking anything else. It may not work right, but at least it's not breaking the application.

As this model becomes more natural to the teams, you can drop the feature branches entirely and just work right off of trunk.

More reading on feature toggles.