What is your strategy for converting RC builds into retail?

Question

We're trying to implement a strategy for how we transition our builds from RC to released retail code.

When we label a build as a release candidate, we send it to QA for regression. If they approve it, that RC then becomes our released retail code.

I liked the idea of "obvious" labeling of versions so that a user knows whether they have a beta or an RC or retail code... where you would have some obvious watermark in non-retail code (think Windows 7 where the RC or non-genuine builds watermark in the bottom right).

... but it seemed strange to us to manipulate the project (to remove the watermark) once it passed regression. If QA certified version a.b.c.d then our retail code should be that same version, not a.b.c.d+1

what strategies have you employed to clearly label non-release software versions without incrementing your build to disable the watermarks in your retail code? One idea I've considered is writing your build to look for a signed file in the installer archive... non-release code wouldn't include this file and so the app would know to display a watermark.

But even this seems like QA is then working with non-release code.
Ideas?

EDIT: What about a process that QA themselves can run to remove the "RC" indicator? That might be an interesting way to handle it.

Answer 1

Follow your instinct. It'd be nice if you could make the release candidate look one way before release and another way afterward, but you're right: it's important that the released version be exactly what QA approved. In my experience, the usual MO is:

• Produce test (alpha, beta) versions that are clearly marked. Send them to QA for testing.

• As you get closer to release, produce release candidate versions that are again clearly marked. Send them to QA for testing.

• Once a release candidate gets the seal of approval, produce a final "golden master" build that is exactly what you intend to ship. No "golden master" or "release candidate" markings. Send that to QA one more time.

• When QA approves the golden master, ship it. Or better, have them ship it so that there's no question that the version they approved is the shipping version.

It's still a good idea to come up with some technical means for turning the "test" markings on and off. That'll help you minimize the steps that you have to perform between approval of the final candidate and the shipping version. My point here is just that you should have QA review the product after you've performed those steps, whatever they are.

Answer 2

Let us look at this the object oriented way. A project just has a version --in the sense that a code change makes it is different from its previous version. Therefore, version must be a property of the project.

On the other hand, a project (in most cases) does not test itself or certify it. That decision is made by the testing/QA teams. And hence, while you/they can label the project "Alpha", "Beta", "RC", "Gold", "Platinum", "Retail" etc. this labelling is not a property of the build but rather of your perception of that build.

It is tempting to store this information in the project itself (perhaps even in the AssemblyInfo.cs) but as your question and Caleb's answer shows it requires re-building the project after each stage (to edit/remove the watermark).

So here is the solution --generate the watermark at run time by using another system (can be as simple as a web object queryable by your project, a simple file, database entry --you decide). The key is to keep this system outside the project scope and only have the testing authorities update the build "watermarks".

Here is how this system looks like (with the timeline):

  Version  |   Status |    Comment
------------------------------------------------------------------------------------------------------------
    1.0    |   Alpha  |  First dev. build released
    1.0    |   Beta   |  Dev. team tests and decides to release it as beta without any code change/rebuild
    1.0.1  |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.0.2  |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.1    |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.1    |   RC     |  QA team promotes it to RC build. You send the exact same build for user testing/preview.
    1.1    |   Retail |  Users do not report bugs, QA team also does not. You decide this build (without any change) can be shipped to retail.

An added advantage of this system is that you control the build tag and can easily create a newer tag (e.g., expired, recalled) and push it out without application reinstalls or rollouts. As a fail safe, the watermark should show a default value or last queried value in case it cannot establish a connection to the system.

Edit: If you are not fan of external systems, then just keep a simple file within the project itself but not embedded into the main assembly/jar/etc. This file can track the build watermark. The key is to not embed the watermark into a unit that has to be compiled in order to be changed.

Answer 3

You should explore Visual Studio's Configuration Manager. It can do what you want it to do. We implemented each configuration with a different Installer Project so that for each build all that was needed was to run compile on the installer project that the desire was to build. We incorperated Dev/Test/prod watermarking scheme into that.