Is Continuous Integration possible with ClearCase?

Question

We are running nightly builds on a Jenkins server and we use ClearCase as a Source Control Management.

Since ClearCase is file-centric, files checkin operate one by one. Contrary to SVN or Git (which are repository-centric), modifications by developers are not committed atomically.

This is not problematic during the night, because developers are not active anymore and the ClearCase server has a lock at 1 AM.

But here is an example of what could be a cause of concern when developers are active by day (let's say that builds run every half an hour):

10:55 AM - Developer1 checks in element1
10:55 AM - Developer1 checks in element2
10:56 AM - Developer1 checks in element3
11:00 AM - ### Jenkins runs BUILD #1 ### <-- succeeds
11:29 AM - Developer2 checks in element1
11:29 AM - Developer2 checks in element2
11:30 AM - ### Jenkins runs BUILD #2 ### <-- fails (element3 is missing)
11:29 AM - Developer2 checks in element3

Thus, are Release Builds (aka "ASAP Builds" or literally "Continuous Integration") worth considering with ClearCase or are we condemned to content ourselves with nightly builds forever?

VonC VonC · Accepted Answer · 2013-07-19T10:54:50

If you are using UCM, you can also consider the ClearCase UCM Plugin, and only trigger a build on demand, when a baseline is created.

That way:

the developer controls when a continuous build is appropriate, but adding a baseline (and cleaning old ones if needed).
Jenkins can promote baselines, making it easier to trace what build has succeeded or failed.

You can even provide a script for the developer to use for:

check-in all the current checked-out file
set a baseline automatically

That would help the user trigger that continuous integration, since he/she can decide when the current code base is stable enough to be committed (and tested).

You can still use that idea with base ClearCase: simply make sure to put a shifting label on all the file (shifting means: if a file has a previous version with that label, the label would be moved to the LATEST version just checked-in by the developer).

Your Jenkins CC view would be configured to display all files with that label, which means if said label moves to a new version, the cleartool lshistory done by Jenkins will change, and a build will be triggered. (Note: you cannot yet do it for a pattern of label)

Is Continuous Integration possible with ClearCase?

2 Answers