This project has moved and is read-only. For the latest updates, please go here.

Team Build Versioning in a Test/Pre-Prod Branch

Jun 3, 2010 at 11:58 AM
Edited Jun 3, 2010 at 12:08 PM

I have a question regarding the practicalities of implementing our branching model in 'TFS team buildi, in particular how team build should handle version stamping in the Release (Test/Pre-Prod) branches. Here is our branching topology:

Dev

- Dev1

- Dev2 (only needed if we need concurrent vNext development whereby the changes are in conflict with Dev1 - we are trying to remove the need for this via better iteration planning)

Main

Release (Test/Pre-Prod)

- R1.0 (Remains here for hot fixes which will build on top of each other)

- R1.1 (as above)

- R1.2 (The current release being tested and stabilised for RTM)

RTM (Read Only branches for auditing purposes only, we have found this better comparing back through version history of the Release branches in terms of giving non Development Team Members read only access to sections of the source code)

- V1.0.0

- V1.0.1

- V1.1.0

- V1.1.1

 

Our Dev and Main team builds take the standard '[BuildName]_20100603.1' naming convention in team build. We also have a distinction between a build and a release in our build definitions whereby a build simply does a compilation on the server only for all check-ins, with a release doing this as well as putting the output in the drop area. We intend to have gated checkins to our dev and main 'builds' in the near future.

We perform early beta releases directly from Dev Branches for testing, and a fully integrated release for manual testing will be done from the most current Release Branch (Test/Pre-Prod). We have automated some of the testing.

It is not clear whether when a stabilising a production release coming from the current release branch (E.g. R1.2), which has the potential to go through a few manual testing cycles, should be version stamped in the same manner as Dev and Main with a datetime stamp, or whether it should commence proper version stamping such as V1.0.0.

There appears to be trade offs under both scenarios.

If datetime stamp versioning is used: A Release would need to have its version changed on the decision to turn it to RTM. Changing a version number doesnt appear possible in the team build explorer. Another build agent or build definition could be setup to do a production release over a branch which will do a version stamp, but then the release will have 2 identities, which is sounding too far away from the out of the box intent of 'Build Quality'

Each Release gets a proper version stamping every time: This works perfect in the team build explorer as you would simply change the build quality to "Release", but the problem is here is that you would start burning V1.0.x numbers. From an aesthetic point of view there would be gaps in the version numbers in your read only RTM area. The first version of V1.0 that is released could be say V1.0.7 and not V1.0.0. It would be preferable that the first release always goes out as V1.0.0 with only hot fix released incrementing the second number and in a sequential manner. This sounds more align with best practices and maybe we just live with the 'gaps'. Most of the concerns about gaps have been raised by management, the Development team is not too fussed about it but we are having trouble as we havent found anything in the industry to suggest that this is the norm.

Interested to here anyones thoughts on this.

Jun 8, 2010 at 6:13 PM

I am not sure this will answer your question.

Typically I recommend doing the stabilization, prior to release, in the Main Branch. Once the code in Main reaches a certain level of quality (passed predetermined quality gates), then it can be considered for Release (RTM).

At the time you make a decision to Release, you would create your release branches. I would not recommend using these Release branches for pre-release stabilization. Depending on your specific needs, you may have release branches created for post-release sustained engineering (hot fix support, service pack suport, etc.)

Regards,
Bill Heys
VS ALM Ranger