1

Our team uses TFS for version control. Our branching strategy is as follows:

  • We have a main branch that we use as the dev branch
  • In a four-weekly cycles, we release our software
  • When this is done, a release branch is created from the main branch, representing the state of the software as it is released
  • When changes need to be made before the next planned release is due (critical bugs), an emergency release branch is created from the most recent release branch.
  • When the software is live, this branch will be merged to the main branch to ensure the bug is not reintroduced with the next release

The result of this branching strategy is that the list of branches is, obviously, consistently growing over time creating a nice scroll-fest, if you need to create/merge branches for a release.

Is it a good idea to keep all branches, or are there other strategies to deal with this?

|improve this question
  • Can you describe the sort of environments you're deploying to and the requirements for upgrades/patching as this will be very important to give a good answer. Are they on premise installs or environments under your control? Will clients accept frequent/continuous deployment models or does your industry require more structured deployment processes (finance for example)? – Liath Mar 22 '18 at 9:53
  • 1
    For how long do you have to give support on old versions? Is that 1 release cycle, 2 cycles, more? Does TFS support a concept like tags for identifying a particular version that has been released? – Bart van Ingen Schenau Mar 22 '18 at 11:33
  • Your branching strategy is fine. This sounds more like a TFS issue and how it displays branches.Work on that. – Doc Brown Mar 22 '18 at 13:45
4

Instead of branching, create a label for each release.

Code can be pulled from source control using a label or you can use the label as a basis for a branch if you need to hotfix a release before the next release is ready.

In Visual Studio 2015, you can apply a label by right-clicking on a node in Source Control Explorer. Go to Advanced->Apply Label. You can label by the latest version, workspace version, date, or changeset. Current MSDN documentation here.

You can also apply labels through the TFS build system. You could create a release build definition that packages your release and labels the source. Refer to this answer on StackOverflow.

You can view existing labels from the History window. History defaults to changesets, just switch the view to Labels.

|improve this answer
  • How does one create a label in TFS? I've been all around TFS and I haven't come across this feature yet. – Robert Harvey♦ Mar 22 '18 at 18:18
  • @RobertHarvey Updated my answer to include that – 17 of 26 Mar 22 '18 at 18:58
  • You can also get your build process to create a label automatically I believe – Liath Mar 23 '18 at 9:47
  • 1
    @Liath is correct, updating my answer. – 17 of 26 Mar 23 '18 at 12:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.