delivery mechanism, Rational ClearCase

Question

Hi All,
We came up with a stream structure for the Rational ClearCase UCM model.

Int
-- Prd
-- Uat
-- Dev
---- Development Stream r1.0

We recently migrated the code base into the new setup. We had three different code bases, i.e. three physical code bases.

Migration process:

we moved the production code first, created an activity,delivered the activity to Integration stream, created a baseline.
Then the uat code, created an activity, delivered the activity to integration stream, during merge we chose the changes from the contributor 2 to preserve the existing code from uat, created a baseline. The same process for the dev environment.

As of now the integration stream has the latest baseline that is the development baseline.
Now we have other two streams for the prd and the uat from which the release will be done in the respective environments.

I have my dev stream now. I create an activity and make some changes. now I need to promote these changes into the uat environment. If I deliver the changes to the integration stream, merge is done but on a development basline. I do not want to rebase it to uat as many development apps wil get rebased into the uat which is not desired.

How do I achieve promoting changes to the uat environment(uat stream). kindly advice.

Answer 1

Looks like your stream structure is like this:

Int
  Dev
  UAT
  Prd

If I deliver the changes to the integration stream, merge is done but on a development basline. I do not want to rebase it to uat as many development apps wil get rebased into the uat which is not desired.

The principle of a stream is to isolate a specific development effort:

• daily development for Dev
• test in read-only mode for UAT (you are not supposed to touch anything, just test and accept or reject)
• Hot fixes in Prd

Int being there to record the latest Prd baseline in order to allow another project to use one of those baselines as starting point, avoiding using a baseline made from a branch of branch of branch ("cascading branching").

I would recommend (and this is only one proposition, many other structures are possible, depending on the exact set of development efforts you need to isolate one from another):

Int
  Prd
  Dev
    UAT

• You rebase UAT with whatever Dev Baseline you want to test (that way, Dev can go on the daily Development without messing with the content being tested for User Acceptance Tests)
• If the baseline being rebased to UAT meet expectations, you deliver it directly to prod (where some last minute Hotfixes can occur)
• When a Prd baseline is set and stable, you deliver it to Int (to record the fact that this is the one running in Production