viernes, 11 de diciembre de 2009

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

6 comentarios:

  1. Yo lo uso y me parece bárbaro. La gestión de configuración tiene varias patas, una de ellas la herramienta (clearcase en este caso) pero mas importante aún es la gestión que se haga del proyecto. Planificar los cambios no es algo trivial, se debe poner el pienso al ppio. de cada desarrollo para no tener dolores de cabeza despues. En el caso de tener varios desarrollos en paralelo, yo recomiendo utilizar branchs independientes y luego mergearlos hacia branchs de integración. Es cierto que los merges conllevan un riesgo, pero esta me parece la mejor solución para no perder la independencia en los desarrollos. Saludos.

    ResponderEliminar
  2. Muchas gracias por tu comentario, Fabio.

    No sé si has trabajado con Subversion. ¿Piensas que ClearCase es mejor herramienta? A mí ClearCase me parece bastante más complicada y no llego a sacarle partido.

    ¿Sabrías decirme qué puede hacer ClearCase que no pueda hacer Subversion?

    Un saludo.

    ResponderEliminar
  3. Hola, buenos días.
    Te felicito por tu entrada... se nota que hay trabajo.

    Quiero hacer las siguiente aclaración:
    1. Una corriente es la traducción que hiciste de un "stream", yo lo llamaría [flujo de trabajo].
    2. Para ver el contenido del VOB se hace a través de una vista, y esta puede ser estática o dinámica,.
    3. Se de tener en cuenta que las acciones de entrega (deliver), se debe subir el código válido. No hacer acciones de entrega como intentos de prueba/error en los flujos de Integración, para ello están los flujos de desarrollo.
    *******************
    Es importante:

    1. Plasmar la arquitectura de los Entornos de trabajo en ClearCase (Definir los flujos o stream de integración y desarrollo) con los entornos reales (físicos) de desarrollo.

    2. Planificar la evolución de los artefactos de software para su adecuación en ClearCase, cómo lo mencionó Fabio, no es tarea sencilla, y al hacerlo bien, te evitaras dolores de cabeza. Te encuenta que puedes manejar roles y tareas por roles (controlaboles a través de triggers).

    Comparto este documento que explica la dependencia de actividades:
    http://www-01.ibm.com/support/docview.wss?uid=swg27012941&aid=2

    No estoy de acuerdo con tu conclusión, puedes pensar en cambiar el esquema o arquitectura de tus flujos de promoción, puedes dejar flujos para evolutivos, para correctivos, para desarrollos... en fin... si en un mismo flujo, trabajas varias cosas... tendrás seguro muchos dolores de cabeza con las dependencias...

    ClearCase es muy adaptable y personalizable, de pronto te vendría bien trabajar con Vistas dinámicas? (claro, desconozco las caractrerísticas de la red y de los servidores de desarrollo). Con lo que escribiste, deduzco que estás trabajando con vistas estáticas... este cambio de concepto te vendría bien.

    Aunque escribiste bastante, es poco para tener un panorama claro de lo que tienes y lo que quieres (tamaño, arquitectura física, evolución, etc)

    ResponderEliminar
  4. Muchas gracias por tus comentarios, Fabian. Los tendré muy en cuenta.

    En cuanto tenga algo de tiempo voy a tratar de escribir un post con un entorno de ejemplo sobre el que poder discutir para poder hablar de algo un poco más "concreto".

    Un saludo.

    ResponderEliminar
  5. OK, muy bien... estaré pendiente. Un saludo

    ResponderEliminar
  6. En un trabajo use la herramienta Clear Case es un poco complicado al principio. En mi opinion esta herramienta te ayudara a crear una vista el cual esta ligado al proyecto(sistema), y a la vez te ayudara a crear subvistas el cual esta ligado por el proyecto padre estas subvistas la usan los desarrolladores el cual cada uno desarrolla sus requerimientos.
    Con respecto a los Check in te ayudara a proteger tu codigo de aplicacion y check out lo desprotege en caso de que quieras realizar cambios.
    Hay otros conceptos como Deliver esto significa subir tus cambios hacia la vista padre el cual esta ligado el proyecto.
    Rebase te ayudara a obtener la ultima version o sea actualizar tu proyecto con los ultimos cambios.
    Mergue esto si hay que tener mucho cuidado significa cuando tu haces un cambio en una aplicacion perteneciente a un codigo y otro desarrollador tambien realizo cambios en el mismo proyecto te aparecera el mensaje Mergue el cual permitira realizar la mezcla de codigos osea tus cambios mas los cambios que realizo el otro desarrollador. asi que pilas

    ResponderEliminar