Wir betreiben nächtliche Builds auf einem Jenkins-Server und wir verwenden ClearCase als Source Control Management.Ist Continuous Integration mit ClearCase möglich?
Da ClearCase file-centric ist, werden die Dateien nacheinander überprüft. Im Gegensatz zu SVN oder Git (die repository-zentrisch sind), werden Änderungen von Entwicklern nicht festgeschrieben atomically.
Dies ist in der Nacht nicht problematisch, da die Entwickler nicht mehr aktiv sind und der ClearCase-Server um 1 Uhr morgens gesperrt ist.
Aber hier ist ein Beispiel dafür, was ein Grund zur Besorgnis sein könnte, wenn Entwickler für Tag aktiv sind (sagen wir, dass jede halbe Stunde laufen Builds):
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
So sind Release-Builds (aka "ASAP Builds" oder wörtlich "Continuous Integration") mit ClearCase eine Überlegung wert oder sind wir dazu verdammt, uns für immer mit nächtlichen Builds zu begnügen?
Danke für die Antwort. Ich hätte es aufzeigen sollen; Wir verwenden kein UCM, sondern nur ClearCase. Was könnte eine Antwort ohne den Einsatz von UCM sein? –
@ StéphaneBruckert Ich habe meine Antwort bearbeitet: Die Idee ist, den Build basierend auf einem Label auszulösen, nicht nur auf einer neuen eingecheckten Datei. – VonC