È possibile l'integrazione continua con ClearCase?

Question

Stiamo eseguendo build notturni su un server Jenkins e utilizziamo ClearCase come gestione del controllo del codice sorgente.

Poiché ClearCase è incentrato sui file, i file di controllo funzionano uno per uno. Contrariamente a SVN o Git (che sono incentrati sul repository), le modifiche degli sviluppatori non vengono commesse atomically.

Questo non è problematico durante la notte, perché gli sviluppatori non sono più attivi e il server ClearCase ha un blocco all'1 del mattino.

Ma qui è un esempio di quello che potrebbe essere un motivo di preoccupazione quando gli sviluppatori sono attivi di giorno (diciamo che costruisce eseguito ogni mezz'ora):

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 

Così, sono Costruisce rilascio (alias "ASAP Builds" o letteralmente "Continuous Integration") che vale la pena considerare con ClearCase o siamo condannati a contentarci per sempre di build notturne?

Answer 1

Se si utilizza UCM, si può anche considerare il ClearCase UCM Plugin, e innescare solamente una build su richiesta, quando viene creata una linea di base.

questo modo:

• i controlli di sviluppo, quando un accumulo continuo è appropriato, ma l'aggiunta di una linea di base (e la pulizia quelli vecchi se necessario).
• Jenkins può promuovere le linee di base, rendendo più facile tracciare quale build ha avuto esito positivo o negativo.

Si può anche fornire uno script per lo sviluppatore da utilizzare per:

• del check-in tutti i file ritirato corrente
• impostato automaticamente

una linea di base che farebbe aiuta l'utente a innescare quell'integrazione continua, dal momento che può decidere quando la base di codice corrente è abbastanza stabile da essere impegnata (e testata).

---

È comunque possibile utilizzare tale idea con ClearCase di base: è sufficiente fare in modo di mettere un'etichetta di spostamento su tutto il file (mezzi di spostamento: se un file ha una versione precedente con quella etichetta, l'etichetta sarebbe spostato nella versione ULTIMA appena effettuata dallo sviluppatore).

La vista CC di Jenkins sarebbe configurata per visualizzare tutti i file con tale etichetta, il che significa che se detta etichetta si sposta su una nuova versione, il cleartool lshistory eseguito da Jenkins cambierà e verrà generata una build. (Nota: è cannot yet do it for a pattern of label)

Answer 2

C'è un plug-in clearcase https://wiki.jenkins-ci.org/display/JENKINS/ClearCase+Plugin Sembra un po 'complesso da implementare ma ha aggiornamenti recenti.

D'altra parte, si potrebbe colmare a git/svn How to bridge git to ClearCase?