Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
I am guessing you are not using visual studio? –  Chad Jun 6 '12 at 20:26
    
We are. QA is not. –  Matthew Jun 6 '12 at 20:45
add comment

3 Answers

up vote 6 down vote accepted
+100

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.

share|improve this answer
    
This will effectively require QA to "re-validate" a version... What happens if they fail it at that step? Then we still have an un-marked version "in the wild"... perhaps my concerns aren't valid scenarios but I'm thinking about this problem more philosophically than anything else. –  Matthew May 31 '12 at 22:13
    
It shouldn't be "in the wild" -- only the QA folks should have access to it. Your process will depend in part on the platform for which you're building: Is code signing involved? Can you include a build number with the app version? Anyway... if QA approves a release candidate but fails the "golden master" version, then either you screwed something up in the (hopefully trivial) process of creating the golden master, or QA changed the test process. Either one is a problem that you'll need to address. –  Caleb Jun 4 '12 at 17:26
    
So then QA would be in charge of signing the files? –  Matthew Jun 6 '12 at 17:21
1  
@MatthewPK If the QA folks are willing and able to take on that responsibility, that could work. Some places have a Configuration Management group that's responsible for doing all final builds. I don't think that the details of the process are as important as simply having a well-defined, well-known process that includes some sanity checks to make sure that the QA-approved version is the version that gets shipped. –  Caleb Jun 7 '12 at 13:15
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
But how does the installer project control watermarking in the application? –  Matthew Jun 7 '12 at 20:27
    
You can do that in your configuration manager. The installer projects set the configuration to use. This allows the devs to never have to change from debug mode. It requires a little maintence on the config files occasionally. But once you figure it out its mostly copy and paste into new projects. –  Chad Jun 8 '12 at 12:49
    
Can you provide me with a little more documentation on this? I'm having a hard time finding any good links. Is this something we would do in the wix? –  Matthew Jun 8 '12 at 14:16
    
Matthew We had a small image 20x40p as I recall that said DEV, TEST, or {ProductName} That image path was a field in the config. The config used was based on the installer package that was built. It really was not that hard. –  Chad Jun 8 '12 at 16:29
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.