1

From what I've seen so far, the usual way of using Release Management is with the following release path :

Dev -> Test -> Production

Let's say I have :

  • version A in Production,

  • version B in Test ( = version A + new features)

Is there an easy way to deploy a "Patch" for version A (i.e. a quick fix of version A without the new features of version B) ?

That's a frequent problem and I haven't seen any topic on that specific issue. That's something usually done through branching code on tfs (or git), but branching isn't exactly compatible with Release Management philosophy.

... or am I missing something ?

Community
  • 1
  • 1
emmanuel k
  • 11
  • 3

3 Answers3

0

You can hide/disable the new features of version B through "switches" (feature toggling) then later you have only to enable them. More details here.

Community
  • 1
  • 1
ds19
  • 3,178
  • 13
  • 33
  • This is not the same thing : A + patch is not the same as A + B (toggled off) + patch. there could be side-effects, etc. – emmanuel k Feb 29 '16 at 13:54
0

I would say this issue is more on the source control and build systems than it is on the release management. Although, to your point, MS Release Management's path's don't support applying a patch to just one Stage in that path. We manage multiple release and release paths for this reason. Some go through the entire Dev -> QA -> Production, others go directly to each of the stages. This does mean that when we make a change to any release, we have to make that same change many times.

Although branching solutions have become less popular recently, this is something my team tends to handle with keeping both a Development and Release branch. We do code promotion to our Release branch and only build our Releases off of that branch.

Any hotfixes or patches we need to do, we either commit directly to the release branch (and later Reverse-Integrate back to the Dev branch) or promote a single change-set forward.

For more TFS branching strategies: http://vsarbranchingguide.codeplex.com/

If you do not want to go with branching, another alternative is rolling-back your code to the last known release point, code your patch, shelve the code, then build and release the shelveset.

abest
  • 484
  • 4
  • 14
0

The new features released recently in the Release Management allows this kind of custom behavior.

Now you have the ability to deploy sequentially, in parallel, or in any other user specified order ( you can deploy manually )

You can trigger a new release with patched version A ( adding some description regarding patching to identify it later ) with no deployment conditions and then can manually deploy to whichever environment you want.

Go over this link to find more - https://blogs.msdn.microsoft.com/visualstudioalm/2016/01/07/vsts-release-management-plans-for-2016-h1/

Harshil Lodhi
  • 6,098
  • 1
  • 31
  • 41