CODEWITHSUNDEEP
jenkinsclearcaseclearcase-ucm
Roy Bunting
Roy Bunting

Reputation: 53

clearcase UCM: delivering baselines on developer streams

I am currently working in a large project that just finished transitioning to ClearCase UCM, and our stream tree looks like this:

This pattern is repeated accross multiple projects with each project having just one main int stream and x main dev streams (usually x < 5)

I am aware that one stream per developer is not ideal, but this design is out of my hands, I need to make jenkins do continuous integration given this stream tree.

My teammate and myself came up with this design: Jenkins/CC Continuous Integration Design

Several Notes about this design:

  1. Jenkins will have a job that runs every 3-5 minutes that detects whenever a user dev stream has a new baseline (The users would have to create a baseline on their user dev stream which is then detected by jenkins, that's all the user does, everything else is automated).

  2. The Jenkins Stream would be created by jenkins as a child stream of the user dev stream and it would be based on the baseline detected.

    • Jenkins would use this stream to rebase, then build the baseline and if it fails, it would reject the baseline (user would have to create a fixed baseline and try again).
    • If build is successful, the baseline will then be delivered and the baseline recommended, at which point the baseline gets promoted to delivered.
    • If the rebase causes a merge conflict, user would get notified via e-mail and user would have to rebase and create a new baseline to try again (users are required to rebase before creating a new baseline on their streams).

  3. Once jenkins is done verifying the baseline and taking action according to the build result, jenkins will remove the stream/view it created to perform it's check. (Jenkins Stream is a temporary stream only active while jenkins is building).

  4. Jenkins has a per-component queue, two baselines for the same component will NOT build in parallel, and baselines are done on a component-scope.

That sums up the proposed design, however we have been shut down for now due to the below rationale:

  1. Creating baselines on user dev streams is a "terrible idea" because it creates a "mess" due to not being to backtrack if a given file is broken.
  2. Too many baselines on user dev streams creates a dependency chain that is "unmanageable" and would take "significant amounts of time" to trace a given change in a given file back to its origin.
  3. Basically, this design is "not sustainable" because of the sheer amount of baselines that would be created in the long term.

That's the argument against it. However we pointed out that delivering from the user dev stream (that's how it's currently done) creates a deliverybl baseline on the stream, so the amount of baselines is the same with this design vs the other design.

However, the counter argument was:

"The deliverybl baselines created by clearcase on a deliver form stream is different from the user-created baselines and they are manageable"

When asking what is different between the baselines, the response was:

"They are different, trust me"

Which brings me to the actual questions:

  1. Is this design actually unsustainable( long term dependency chains)?
  2. Is there a problem with users creating baselines on their user dev streams and then delivering those baselines as the method of moving changes from the user dev streams to the main dev branches?
  3. Are the user-created baselines and deliverybl baselines actually different? if so, how are they different? and could a user be given requirements about how to create their baseline that would make the baseline equivalent to the deliverybl ones?
    • If they are different, how does the delivering from stream design actually differ form the delivering from baseline design that makes the latter unsustainable?
  4. Any suggestions on how this design could be improved?

Thanks, I know this is a long post and I appreciate the time you take on reading and replying to my question.

Cheers, Roy Bunting

Upvotes: 2

Views: 206

Answers (1)

VonC
VonC

Reputation: 1323753

Is this design actually unsustainable( long term dependency chains)?

Yes, as you must put in place a purge mechanism to cleanup old baselines.
And a rmbl is not always possible, especially if that baseline is part of a deliver.

Is there a problem with users creating baselines on their user dev streams and then delivering those baselines as the method of moving changes from the user dev streams to the main dev branches?

The principle is sound but the implementation (though ClearCase UCM deliver) can be very slow, depending on the size of the components.
And there can be an order issue, where other devs might want to rebase first, validate that their changes are still valid before delivering themselves (as shown here)

Are the user-created baselines and deliverybl baselines actually different?

Yes, as explained in "What is deliverbl in UCM ClearCase?".
In addition to being unlabelled, you cannot remove them easily as they have hyperlinks and special UCM attributes.

Upvotes: 1

Related Questions