Typical best-practice ClearCase project structure

Question

During a development project, the delivered code can go between different stages different environment before it reaches the production (e.g. Development Environment for testing deployment processes, Internal Testing for QC, Pre-Production and finally production).

This development effort produces many candidate release in which a certain release can be nominated to move upwards in the development process until it reaches production, also, there might be some cases where the code deployed on the production might require hot-fixes in parallel to the current internal development lines (i.e. Parallel Development).

For a certain UCM project maintained by IBM Rational ClearCase (CC), what is the recommended project structure to be created on "Project Explorer" to accommodate for the following:

1. The developers should mainly connect and deliver their work on the internal development line (or in CC terminology the development stream).
2. Once the delivered code to this development stream is considered acceptable, the Technical Team Lead (TTL) can create a baseline. This baseline can be later retrieved by the Deployment Engineer to be deployed on the local Development Environment.
3. If this baseline was found acceptable, this baseline can be delivered as a whole to the Internal Testing stream to be deployed for further Quality Control (QC) test.
4. If this baseline was found acceptable, this baseline can be delivered as a whole to the Pre-Production and so forth to the production similar to what was described above.
5. Of course, if any of these baselines were not accepted by its receiving party, it can be rejected, and the receiving party will wait for another baseline to be recommended for their stream.

Note: The Deployment Engineer will always use a dedicated stream for each environment to get his/her files required to carry out the build/deployment activities.

My apologies for everybody here since I understand that answering this can be long, but my question more concentrates on the exact type of streams and/or views that need to be created in "Project Explorer" to suffice the above objectives.

I am really trying to come up with the best practice approach for release management using CC and how it can be best used this purpose.

I would appreciate your help guys and many thanks to all in advance ...

Answer 1

The rule of thumb is simple:
The less branch, the better.

I mean, if you ever done deliver and rebase before with ClearCase, you know:

• how painful it is
• how poorly it scales with the number of file (merging 1000 files is awfully long, merging 5000 files is murder)

So the real rule of thumb is:

if you don't have to modify any file for a given development stage, don't create a branch.

For instance, for promoting a code to QA, where you will only read it (and launch some tests, in order to accept that code if they pass, or to reject that code if they fail), don't create a QA Stream where you would deliver the code: it is too long for an non-existent added value.

Use baseline promotion level whenever you can, and recommend your promoted baselines.

The Deployment Engineer will always use a dedicated stream for each environment to get his/her files required to carry out the build/deployment activities.

Err... no, if you don't have any change to do.
The Deployment Engineer doesn't care at all where the baseline is coming from, only if the code deploys and runs successfully.