lunes, 16 de agosto de 2010

SubVersion, Eclipse y las ramas de desarrollo. (I) Intro


Vamos a adentrarnos en ciertas complejidades del desarrollo de proyectos java que utilizan SubVersion como herramienta de control de versiones.La intención es ver cómo se gestionan las ramas (branches) en un proyecto de este tipo, y para ello vamos a crear un proyecto de ejemplo y una rama, haremos modificaciones en paralelo y acabaremos haciendo la fusión (merge)  de los cambios de la rama y del proyecto principal, que en la jerga SVN se denomina trunk.

SVN

Para los que no lo conozcáis, SubVersion (o SVN) es una herramienta de control de versiones, que gestiona los cambios en los ficheros de forma centralizada, lo que permite que haya diferentes usuarios (programadores en nuestro caso) realizando cambios sobre un proyecto, manteniendo el control de los archivos que han sido modificados por el resto de usuarios.

No quiero extenderme más en las características de SubVersion, por lo que a partir de aquí voy a suponer que tú, que me estás leyendo, tienes cierto conocimiento de la herramienta. En concreto, basta con tener los siguientes conceptos claros:

- Qué es un repositorio
- Qué es un checkout
- Qué es un commit
- Qué es un update

Si no entiendes bien estas cuatro cosas, creo que todavía estás bastante lejos de tener problemas con los branches, por lo que te recomiendo otras lecturas más ligeras :)

Repositorio

También voy a suponer que tienes acceso a un repositorio SVN para poder alojar el proyecto, las ramas, etc. La creación de un repositorio SVN en tu propio equipo es una tarea sencilla, sobre todo si te apoyas en herramientas denominadas clientes SVN, como por ejemplo TortoiseSVN, uno de los más utilizados y más simples para el entorno Windows. En entornos Linux el SVN se suele utilizar desde la línea de comando, lo que requiere cierta capacidad para memorizar las diferentes opciones de la herramienta, o tener el manual siempre cerca. Si me dan a elegir, me quedo con TortoiseSVN. Para no complicarnos más de lo necesario, dejamos para otro post la creación del repositorio, y suponemos que tenemos ya uno, es decir, disponemos de la URL del repositorio, un usuario y un password.

Branches

En proyectos de cierta envergadura se hace necesario el uso de ramas (branches) para permitir dos trayectorias de desarrollo paralelas. El ejemplo clásico es el de la aplicación que se encuentra en producción, en la que un equipo de programadores hace el mantenimiento correctivo mientras que otro equipo se encarga del desarrollo de la siguiente fase. Los mantenimientos deben realizarse a partir de la versión que se haya desplegado, y no deben verse afectados por las modificaciones realizadas por el desarrollo de la siguiente fase. Por otro lado, los desarrolladores de la siguiente fase deben poder realizar las modificaciones que consideren oportunas en un lugar distinto al que utilizan sus compañeros de mantenimiento para no afectar a la versión en producción, pero también deben tener la oportunidad de actualizar su copia de trabajo con las correcciones que realicen desde el mantenimiento.

Esto se soluciona con la creación de una rama (branch) que permite al equipo de mantenimiento seguir trabajando en el proyecto principal o trunk (también se le llama «rama principal») y a los desarrolladores de la siguiente fase en una ramificación del proyecto principal. A partir de aquí se podrían hacer varias ramas, ramas de ramas, etc, dependiendo de los requerimientos del proyecto. En este ejemplo no vamos a pasar de un caso simple en el que se pretende dejar claros los conceptos, con un proyecto principal y una rama, dejando para la cruda realidad las ramificaciones más complejas.

Estructura del repositorio

Como ya veremos más adelante, vamos a necesitar algún sitio en el repositorio para hacer esa segunda copia a la que vamos a llamar rama. En principio no hay nada establecido en cuanto a dónde hacerla o cómo gestionar las ramas; sin embargo hay una estructura que se ha convertido ya casi en un estándar, que es la siguiente:

  • repositorio:dir_raiz
    • Proyecto1
      • trunk
        • código...
      • branches
        • branch1
          • código...
        • ...
      • tags
    • Proyecto2
      • trunk
      • branches
      • tags 
    • ...

Es decir:
  • Del directorio raiz del repositorio cuelgan las carpetas, que se corresponden con los proyectos
  • En cada proyecto existen 3 carpetas
    • trunk, en donde se encuentra el código de la rama principal
    • branches es el directorio donde vamos a crear las ramas. Cada vez que creamos una rama, crearemos un directorio dentro de esta carpeta.
    • tags, lo pongo aquí para que nadie lo eche en falta, pero no lo vamos a utilizar para las ramas. Lo veremos en próximos posts.
Próximo paso

Vamos a empezar poco a poco. Lo primero, la instalación del SubClipse.

No hay comentarios:

Publicar un comentario