we running nightly builds on jenkins server , use clearcase source control management.
since clearcase file-centric, files checkin operate 1 one. contrary svn or git (which repository-centric), modifications developers not committed atomically.
this not problematic during night, because developers not active anymore , clearcase server has lock @ 1 am.
but here example of cause of concern when developers active day (let's builds run every half hour):
10:55 - developer1 checks in element1 10:55 - developer1 checks in element2 10:56 - developer1 checks in element3 11:00 - ### jenkins runs build #1 ### <-- succeeds 11:29 - developer2 checks in element1 11:29 - developer2 checks in element2 11:30 - ### jenkins runs build #2 ### <-- fails (element3 missing) 11:29 - developer2 checks in element3 thus, release builds (aka "asap builds" or literally "continuous integration") worth considering clearcase or condemned content ourselves nightly builds forever?
if using ucm, can consider clearcase ucm plugin, , trigger build on demand, when baseline created.
that way:
- the developer controls when continuous build appropriate, adding baseline (and cleaning old ones if needed).
- jenkins can promote baselines, making easier trace build has succeeded or failed.
you can provide script developer use for:
- check-in current checked-out file
- set baseline automatically
that user trigger continuous integration, since he/she can decide when current code base stable enough committed (and tested).
you can still use idea base clearcase: make sure put shifting label on all file (shifting means: if file has previous version label, label moved latest version checked-in developer).
your jenkins cc view configured display files label, means if said label moves new version, cleartool lshistory done jenkins change, , build triggered. (note: cannot yet pattern of label)
Comments
Post a Comment