Control de versiones con ClearCase

Rational ClearCase es el sistema de control de versiones de IBM. Aunque Subversion es más de mi agrado por su sencillez, esta herramienta es la que utilizo en el trabajo. Estamos teniendo un montón de problemas trabajando con ella, aunque estoy convencido que es más por desconocimiento que por la herramienta en sí. Así que voy a exponer a continuación que es ClearCase, cómo lo usamos y qué problemas estamos encontrando de cara a compartir experiencias con otros usuarios de ClearCase.

Cómo otros sistemas de control de versiones, ClearCase almacena distintas versiones de los elementos que forman parte de un proyecto, que pueden ser directorios o archivos. Estos elementos se almacenan en un repositorio que en ClearCase se llama base de objetos de versionado (VOB).

ClearCase proporciona un proceso de gestión de la configuración llamado gestión del cambio unificado (UCM). UCM se situa sobre la base de ClearCase simplificando el trabajo.

En UCM un proyecto es un producto de un desarrollo de software que contiene información de configuración sobre el mismo. Un proyecto está formado por componentes, que constituyen las partes de un proyecto, como módules web o módulos JAR en un proyecto Java.

Las modificaciones que se llevan a cabo durante las tareas de desarrollo dentro de la ejecución de un proyecto se registran en actividades, que consisten en varias versiones de distintos elementos de un componente.

Un proyecto consta de un área de trabajo compartido y muchas áreas de trabajo privadas. Cada área de trabajo está formada por una corriente y una o varias vistas. Una corriente es un objeto de ClearCase que mantiene una lista de actividades y líneas base que determinan que versiones de elementos aparecen en la vista. Una vista es un árbol de directorio que muestra una única versión de cada archivo del proyecto.

Todo proyecto tiene un área de trabajo compartido que se maneja mediante una corriente y una vista de integración. Su función es registrar las líneas base del proyecto y recibir las nuevas versiones de los elementos compartidos del proyecto para su integración conjunta.

Cada línea base representa una versión de los elementos de un componente en un determinado momento del desarrollo. A lo largo del proyecto, el administrador crea y recomienda líneas base para reflejar hitos del proyecto.

Según UCM, los desarrolladores tienen un área de trabajo privada donde realizan sus cambios. Esta área de trabajo consta una de corriente de desarrollo que mantiene la lista de actividades del desarrollador y determina qué versiones de los elementos del proyecto aparecen en su vista de desarrollo.

Cuando los desarrolladores se unen a un proyecto incluyen en sus áreas de trabajo las versiones de los elementos del proyecto marcados en la línea base recomendada del proyecto. Éstos harán sus cambios dentro de actividades en su área de trabajo privada y, una vez finalizados y probados, harán entrega (deliver) de estas actividades a la corriente de integración, lo que podría llevar a tener que combinar elementos si otro desarrollador ha hecho modificaciones en los mismos elementos.

Periódicamente, los desarrolladores deben hacer rebase para actualizarse a las últimas líneas base recomendadas. Si las líneas base incluyen nuevas versiones de los elementos que se están modificando en la vista de desarrollo, la operación de rebase fusiona las dos versiones en una nueva versión dentro de la corriente de desarrollo.

Lo explicado hasta ahora es el proceso de gestión de la configuración que define UCM, que implica que cada desarrollador tiene su propio área de trabajo privada. Esto permite que los desarrolladores trabajen de forma paralela e independiente sin colisionar entre ellos a la hora de modificar los mismo elementos. Estos serán fusionados posteriormente en las operaciones de deliver y rebase.

Sin embargo, esto añade carga de gestión al desarrollo, porque para ver las últimas modificaciones de otro desarrollador es necesario que haya entregado sus actividades, se haya hecho una nueva línea base y los otros desarrolladores hagan un rebase.

Para aligerar esta carga, nosotros usamos una única área de desarrollo para todos los desarrolladores, que tienen vistas a ella. Todos los cambios que un desarrollador registra pueden ser vistos por los demás desarrolladores sin más que hacer un update de su vista, permitiendo que los nuevos cambios se publiquen de manera más inmediata.

Sin embargo, si todos los desarrolladores están desarrollando en vistas de la misma corriente, se pueden producir situaciones no deseadas:

Modificaciones concurrentes de los mismos archivos

• Un desarrollador desaA está modificando un archivo fich1, para lo cual lo ha reservado (check out).
• Otro desarrollador desaB también quiere modificar este archivo, y, si no quiere quedarse bloqueado en su trabajo, lo reserva (check out) después de que aparece un aviso de que el desarrollador desaA lo ha reservado previamente.
• El desarrollador desaA sube (check in) el archivo con sus modificaciones.
• El desarrollador desaB sube (check in) el archivo con sus modificaciones, pero en ese momento ClearCase le avisa de que en el repositorio hay una versión de este archivo posterior a aquella que reservó, por lo que debe fusionar las dos versiones (merge). Este merge puede ser automático o manual, a través de la herramienta de ClearCase para esto.
• Este problema, que con un solo archivo puede ser fácil de solucionar, se complica cuando se están modificando varios archivos que coinciden por parte de varios desarrolladores. Se puede llegar a situaciones de bloqueo, por ejemplo, si un desarrollador no puede actualizarse un archivo que ha modificado otro desarrollador y es necesario para que los cambios en otros archivos compilen sin error porque el archivo necesario está reservado y siendo modificado por el desarrollador. Se puede llegar a situaciones difíciles de salir.

Dependencia entre actividades no relacionadas

• Un desarrollador desaA está realizando modificaciones dentro de una actividad activA que implican a los ficheros fich1, fich2 y fich3.
• Comienza reservando (check out) fich1, haciendo los cambios pertinentes y subiéndolo (check in) al repositorio, y después pasa a reservar fich2 y modificarlo.
• En ese momento, otro desarrollador desaB realiza otras modificaciones distintas dentro de otra actividad activB que implican modificar el fichero fich2, previamente modificado en la actividad activA de desaA.
• Por necesidades del proyecto, hace falta crear una nueva versión (línea base) del proyecto sólo con la modificación realizada en la actividad activB y no las modificaciones de activA. Por ejemplo, porque activB es una corrección de un bug que queremos solucionar rapidamente en producción, pero activA es un nuevo desarrollo que no queremos subir hasta no haberlo probado concienzudamente.
• Al tratar de subir la actividad activB, ClearCase nos dirá que esta actividad depende de la actividad activA y que también hay que subirla. Esto es debido a que la modificación del fichero fich2 se hizo sobre la versión modificada en la actividad activA.
• Resultado, no se puede subir activB de forma independiente de activA. Y este problema se puede complicar exponencialmente a mayor número de desarrolladores.

Conclusión, hay que evitar que varios desarrolladores modifiquen los mismo archivos por el bien de la productividad del equipo y de la facilidad en la gestión del proyecto. Lo cual me hace pensar que lo mejor sería un área de desarrollo privada por cada desarrollador como dicta UCM, pero esta forma de trabajar, que también usamos en otro proyecto aumentaría el número de merges de forma considerable con el riego que conllevan.

Aquí os pido colaboración. ¿Alguien tiene experiencia con ClearCase? Me gustaría saber qué estrategias se están usando en otros proyectos y cómo solucionan todos estos problemas.

Referencias:
Introducción a Rational ClearCase LT (Rosa María Carretero López)
ClearCase en Wikipedia
Comparación de software de control de versiones