0

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
3
  • 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
5

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
4
  • 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
1

Do you really need to have more than one Release branch? If you dont have multiple active release versions in production than just use one Release branch.

Merge the changes that are ready into it when preparing for the next 4 week release (or better yet, as they are completed), and make sure you are labeling source code when the artifacts are built.

And if you have migrated to Azure DevOps, you should make sure to specifically retain these builds indefinitely. If you dont, and they get cleaned up, your source control labels will be deleted also. The default age is like 90 days or less. (I had to make a console program to mark these so they didnt get deleted.)

Improve this answer

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.