1

Hello to all guru's out there. I came across a requirement that our TFS needs to support multiple releases. Listed are some of the requirement.

Scenario: We have 2 releases, Release 1.0 and Release 2.0

  1. Release 1.0 needs a patch and will be released as Patch 1.1
  2. The changes in Patch 1.1 can be optionally added to Release 2.0
  3. If there is a new patch, lets say Patch 1.2. It should only contain the changes of Patch 1.1 and what ever additional changes for 1.2.
  4. In relation with item no. 3. The reason for this is some customer doesn't want to pay for the upgrade and just want a minor fix for their current version.

I have come up with a solution but Im just wondering if there are other way or is this not recommended at all because it really is hard to maintain.

Thanks

  • What is the question: how to organize your source control? how to organize your release pipelines? your builds? Be specific and eventually break your question in manageable chunks – Giulio Vian Mar 24 '18 at 11:52

1 Answers1

-1

According to your description, base on my understand as follow example:

version A in Release 1.0,

version B in Release 2.0 ( = version A + new features)

You want 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)

In TFS Release Management, 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.

Another way is rolling-back your code to the last known release point, code your patch, shelve the code, then build and release the shelveset.

For more multiple release structure in TFS please take a look to this link: Team Foundation: Multiple release structure which may be helpful to you.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62