Typical Best Practice of the ClearCase Project

During a development project, the supplied code can move between different stages of different environments before it reaches production (for example, a development environment for testing deployment processes, internal testing for quality control, pre-production, and finally production).

This development work yields many candidate releases in which a particular release can be pushed upward in the development process until it reaches production, there may also be cases where code deployed to production might need to be patched in parallel current internal lines of development (i.e. parallel development).

For a specific UCM project supported by IBM Rational ClearCase (CC), what is the recommended project structure that should be created in the Project Explorer to host the following:

  • Developers should basically plug in and do their work on the internal development line (or in CC terminology, the development flow).
  • Once the resulting code into this development stream is deemed acceptable, the technical team leadership (TTL) can create a baseline. This baseline can later be retrieved by the deployment engineer for deployment to an on-premises development environment.
  • If this baseline has been found to be acceptable, this baseline can be delivered as a whole to an internal testing flow that will be deployed for further quality control (QC).
  • If this baseline has been found to be acceptable, this baseline can be delivered as a whole to Pre-Production, etc. for a production similar to that described above.
  • Of course, if any of these baselines have not been accepted by the receiving side, they may be rejected and the receiving side will expect a different baseline to be recommended for their stream.

Note . The Deployment Engineer will always use a dedicated thread for each environment to get his / her files needed to complete the build / deployment steps.

My apologies to everyone here, as I understand that the answer to this question may be long, but my question concentrates more on the exact type of streams and / or views that must be created in the Project Explorer in order to achieve the above goals.

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

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

+3


source to share


1 answer


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

I mean, if you've ever done shipping and reinstalling with ClearCase, you know:

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

So the real rule of thumb is:

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



For example, to promote code to QA where you will read it (and run some tests to accept that code if they pass, or reject this code if they don't work), t create a QA thread where you will deliver the code : it is too long for a nonexistent appended value.

Use baseline level whenever you can and recommend your advanced baselines .

promoted baselines

The Deployment Engineer will always use a dedicated thread for each environment to get his / her files needed to complete the build / deployment steps.

Err ... not if you don't have any changes.
The Deployment Engine doesn't care where the baseline comes from, only if the code is deployed and run successfully.

+1


source







All Articles