CODEWITHSUNDEEP
continuous-integrationclearcase
Marcos Brigante
Marcos Brigante

Reputation: 1000

Private Builds for Continuous Integration using ClearCase

I currently have a CI environment setup using the following tools:

VCS - ClearCase (UCM enabled)
CI Server - Jenkins
Build Engine - MSBuild

Basically Jenkins is polling my UCM Project's Integration stream every 2 minutes and building via a msbuild script I wrote.

While in ClearCase it is not a best practice having a individual stream for each developer, good CI demands private builds to be run before commiting the code. Added to that, ideally i would have atomic commits, which ClearCase provides just on the form of Deliver to stream.

Currently we are working directly on integration stream, and sometimes our builds fail because Jenkins starts building before the developer finishes her check-ins.

My question is, how can I have a private work area (Sandbox) and atomic commits on ClearCase without creating a stream for each developer? Am I missing something?

Upvotes: 2

Views: 769

Answers (1)

VonC
VonC

Reputation: 1324258

Currently we are working directly on integration stream, and sometimes our builds fail because Jenkins starts building before the developer finishes her check-ins

You can write your build script in order to detect if a deliver is in progress.
A deliver is characterized by an activity named deliver.xxx: you can list its content and see if any version in it is in checkout. If yes, the deliver is in progress.
If the most recent deliver has only checked-in versions, you can safely start your build.

Or:

How can I have a private work area (Sandbox) and atomic commits on ClearCase without creating a stream for each developer

A private area for Jenkins to use would be a snapshot view on each developer stream.
As the name suggests, a snapshot view would take a snapshot of the code, but you need to define a criteria suggesting that Jenkins can build what the snapshot view has updated.

What I have seen used is a 'BUILD' shifting label (a label you re-apply on the newly updated code, and used by Jenkins in his snapshot view with a selection rule based on that label):
The developer move his/her label when he/she thinks the current code is ready to be build, and a Jenkins jobs update its snapshot view on the developer stream, based on the versions referenced by said shifting label 'BUILD'.

Upvotes: 1

Related Questions