¿Es posible la continuous integration con ClearCase?

Estamos ejecutando comstackciones nocturnas en un server Jenkins y utilizamos ClearCase como gestión de control de origen.

Como ClearCase está basado en files , la comprobación de files funciona uno a uno. A diferencia de SVN o Git (que están centrados en el repository), las modificaciones de los desarrolladores no se realizan de forma atómica .

Esto no es problemático durante la noche, porque los desarrolladores ya no están activos y el server de ClearCase tiene un locking a la 1 AM.

Pero aquí hay un ejemplo de lo que podría ser motivo de preocupación cuando los desarrolladores están activos de día (digamos que las comstackciones se ejecutan cada media hora):

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 

Por lo tanto, ¿son válidas las versiones de Release Builds (también conocidas como "ASAP Builds" o literalmente "Integración continua") con ClearCase o estamos condenados a contentarnos con comstackciones nocturnas para siempre?

Si está utilizando UCM, también puede considerar el plugin ClearCase UCM , y solo desencadenar una creación bajo demanda, cuando se crea una línea base.

De esa manera:

  • el desarrollador controla cuando una construcción continua es apropiada, pero agrega una línea base (y limpia las antiguas si es necesario).
  • Jenkins puede promover las líneas de base, lo que facilita el rastreo de la construcción que ha tenido éxito o ha fallado.

Incluso puede proporcionar un script para que el desarrollador lo use para:

  • registrar todo el file actual desprotegido
  • establecer una línea base automáticamente

Eso ayudaría al usuario a desencadenar esa continuous integration, ya que puede decidir cuándo la base del código actual es lo suficientemente estable como para comprometerse (y probarse).


Todavía puede usar esa idea con ClearCase base: simplemente asegúrese de poner una label de desplazamiento en todo el file (desplazamiento significa que si un file tiene una versión anterior con esa label, la label se moverá a la última versión que acaba de registrarse) por el desarrollador).

La vista de Jenkins CC se configurará para mostrar todos los files con esa label, lo que significa que si dicha label se mueve a una nueva versión, el cleartool lshistory hecho por Jenkins cambiará y se generará una compilation. (Nota: todavía no puedes hacerlo para un patrón de label )

Existe un complemento claro https://wiki.jenkins-ci.org/display/JENKINS/ClearCase+Plugin Parece un poco complejo de implementar pero tiene actualizaciones recientes.

Por otro lado, podrías pasar a git / svn Cómo unir git a ClearCase?

Intereting Posts