Multi-stage check-in with PB Classic

Question

I'd like to implement a multi-stage check-in, i.e. check-in for cross-testing, when that's passed check-in for QA, and when that's passed check-in for production. The only way I can think of is keeping a list of all the objects that were changed then doing a compare to make sure no-one else has changed anything while it was being tested, merge any changes if there are any, and don't make any mistakes. This sounds error prone.
Does anyone out there do this kind of thing and how do you handle it? (We're using Microsoft Team Foundation Server for our source control, but I'm not sure it matters what the back-end is).
I'm grateful for any ideas!
Thanks,
  Aron.

Answer 1

I don't know TFS, but in general this is accomplished using Build Numbers, labels, and branches.  I've implemented this methodology using StarTeam back in the PB9 days.
To make things easy, let's say Production is linked to build 1000, build 1100 is Beta, build 1200 is QA.  Developers are working on the tip revision, which is currently build 1300.
Every time a build is done on the DEV branch, generate a new build number and assign that build to the tip revision of every object.  Most of your objects won't change between builds, but that's OK.  All you need to be able to say is "Give me the version of object X as it was for build Y."  That lets you recreate any build from any branch.
Now, let's assume that the QA testers discover a bug that needs some repair.  You can't change the tip revision (build 1300) and compile, because that would pollute your QA build (build 1200) with in-process code.  What you need to do is create a BRANCH from build 1200, and ensure that any changes that get checked in for those defects increment along that branch - NOT the DEV branch.  The KEY to this is to create a separate workspace (NOT a separate target in the original workspace) and bind it's SCC properties to the branch off of build 1200.  Use a copy of the PBLs that represent the QA build (or do a full bootstrap from the TFS exports, but it's easier just to save copies of each promoted build).  When you do builds from this workspace/target, number them from 1200 - I used 1200.001, 1200.002, etc.  The QA people get this build to test.  If the bug is fixed, then you need to manually merge the fixed code into back into the corresponding objects in the DEV branch.  If you don't do this, your changes won't be there in any new DEV build.
The same process is in place for changes to PROD or BETA.  Create a new workspace, branch off of the label's current build number, and ensure that code revisions increment along the branch.  And then comes the manual merge process into the downstream labels.
Promoting a build to the next stage is simply reassigning the label from one build number to the next.  When it's time for the QA build (1200.002) to become Beta, you take the "Beta" label and reassign it to build number 1200.002.  (Build 1100 is no longer the Beta release, and for this moment in time both BETA and QA labels point to the same build number.) 
-Paul Horan-