Solved

Maintaining old software product versions in TFS

Posted on 2014-01-29
5
332 Views
Last Modified: 2014-01-31
We used to have the usual regular software releases - once or twice a year - and branched our code in TFS in order to support hotfixes or patches - whatever you want to call them.

Now we are releasing a new version every two weeks and are trying to figure the best way to manage hotfxes. One option of course is just to assume people will upgrade to the latest version, but in some cases that isn't practical, so I was trying to think of how TFS could support this.

Each release gets labelled, so getting the original code isn't a problem, it is making sure you have the current patched code if no branching is being done.

I did wonder about having each developer check in their hotfix changes to a shelveset with the label name in it - so getting the latest hotfixed version would be a matter of finding all the shelvesets containing that label name and checking them out in date order, but TFS doesn't support searching on shelveset names.

I then wondered about developers sharing the same shelveset - to the same shelveset would be used to store all the hotfix changes for a particular version - but developers can't check in to a shelveset that someone else created.

So can anyone think of a good solution to this?
0
Comment
Question by:purplesoup
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
  • 2
5 Comments
 
LVL 96

Expert Comment

by:Bob Learned
ID: 39819814
I remember a Branching and Merging Guide, that explained the different options depending on your requirements, but I am having a difficult time finding that nice pictures that showed each option flow.

I am thinking it might be this:

Chapter 5 – Defining Your Branching and Merging Strategy
http://msdn.microsoft.com/en-us/library/bb668955.aspx
0
 

Author Comment

by:purplesoup
ID: 39820285
Thanks - this is the thing, we can't branch every two weeks things would just get crazy, that's why we're looking at what other options exist.
0
 
LVL 96

Accepted Solution

by:
Bob Learned earned 350 total points
ID: 39820677
If you are saying that you apply hot fixes that frequently, then I would agree that you are in a pickle...

You are going to need an area where multiple developers can work on the same code set, and branching is the only way that I can think of right now.  I never needed to figure out any other way.  I certainly am not in the situation where I create that many branches, but I do understand the headache that can cause.

I was reading a few discussions, like this one, that sounds familiar here:

Why create release branch with Hotfix branch?
http://vsarbranchingguide.codeplex.com/discussions/349773

I ran out of time this morning, but here is a possibility that might get what you want:

Simplifying TFS: Applying hot fixes without branching
http://www.olegsych.com/2009/04/simplifying-tfs-applying-hot-fixes-without-branching/
0
 
LVL 40

Assisted Solution

by:Kyle Abrahams
Kyle Abrahams earned 150 total points
ID: 39820924
To keep things more manageable you might force them to upgrade.  EG:  If you're 3-4 for versions back, you must update to the latest program.  

Branch by Release is the most sound model that I've heard of.   Maybe you can make it modified in your case.  EG:  Do a branch by major release (say, once per quarter).  All hotfixes for that major release get checked into that branch (and merged to the trunk and any later branches, of course).  If people need the hotfix they'll need to update to the latest code of that branch at least.  The brances could survive a year before dropping off and being forced to upgrade.

To replicate your minor releases a label would be needed on that branch.  But the support approach would be to always update to the latest specific update of that branch.
0
 

Author Closing Comment

by:purplesoup
ID: 39823647
Thanks that's all very helpful.
0

Featured Post

Why You Need a DevOps Toolchain

IT needs to deliver services with more agility and velocity. IT must roll out application features and innovations faster to keep up with customer demands, which is where a DevOps toolchain steps in. View the infographic to see why you need a DevOps toolchain.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Entering time in Microsoft Access can be difficult. An input mask often bothers users more than helping them and won't catch all typing errors. This article shows how to create a textbox for 24-hour time input with full validation politely catching …
Real-time is more about the business, not the technology. In day-to-day life, to make real-time decisions like buying or investing, business needs the latest information(e.g. Gold Rate/Stock Rate). Unlike traditional days, you need not wait for a fe…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question