ClearCase‎ > ‎UCMpedia‎ > ‎

Continuous Integration


Continuous Integration (CI) is an approach to software development among multiple developers that argues for integration of developer's work continuously throughout the process. It's kind of the obvious way to work and hard to argue against from a pragmatic point of view:

It's better to keep up with your colleagues' changes often, that it is to do it seldom. (!!!)

Well - obviously the concept of CI is not entirely as simple as that, if you want to know more you can read a very well-written article on the subject by Martin Fowler.

The interesting question related to ClearCase is: "Does ClearCase support Continuous Integration?"  The answer is (as you probably expected)  "yes" and the remainder og the article discusses how to set it up.

The V-model

A very good reference point for discussing CI in ClearCase is the V-model for software devlopment. Imagine that the different horizontal levels in the V-model are implemented in ClearCase through the use of streams. In the top levels op the model you have the rigid and guarded high-quality streams used for final releases and in the bottom you have the more leasure and agile streams used for development and unit-testing. in between you have steams for component integration, nightly builds, internal releases  and stuff like that.

Streams at different levels have different rules attached to them.

At the bottom we have the development streams, where developers check-in and -out directly related to specific activities. These development streams can be shared among different developers, either by having more views on the same stream og by having another  intermediate development stream (a.k.a. team stream) which you and the colleauges in your small team all deliver to before you validate and deliver further up together.

At the lower levels in the model rules on the streams are less strict. The focus is on the efficiency and smoothness of the every-day work scenario. Developers are expected to gather in smaller - closely related - teams and work together on of the code. If system architecture and project organization is of such a nature the parallel development in the same files is necessary (which is bound to cause for a non-trivial merge) then it's crucial the these clashes among developers occur at the lower levels where code fights can be fought among equals. All merge issues should be handled (at least over-looked) by humans - and as we move higher up in the V-model  the integrations will be automated and therefore merge issues should be sorted out already!

At the level above the development streams we might have a docking project integration level. This level is exactly  just as informal as the development level, but this level might be shared among potentially a larger groups of people. The point is to finally rule out any need for file merges above this level.

At the the Component Integration level you find the first level that is automatically integrated  - well it might not actually be automated, it depends if it's feasible tim implement an automated process. But the point is, that the person responsible for this integration is expected to be skilled in the build process, not necessarily in the semantics of the code. At this level we have ruled out the need for file merges, atn what needs to be validated here is the integration among components, sub systems or modules - basically do they respect each others' interfaces and do the co-exist. Zero-tolerance is expected at this level.

At the highest level you find the release level - or the mainline - this is where you put your release candidates and where hands-on testing is introduced.
Comments