lunes, 22 de febrero de 2010

Desarrollo en equipo con SVN, Maven y Nexus (parte II)

Banco de experiencias (V)

En la primera parte de este artículo, enumeraba los problemas de coordinación a los que se enfrenta un equipo de desarrollo diariamente y cómo la utilización de Maven los soluciona de un plumazo por el simple hecho de utilizarlo. Hay un problema sin embargo, inherente al desarrollo en equipo, para el cual se necesita una herramienta más: un gestor de repositorios.

Imaginemos el siguiente escenario de proyecto: un equipo está desarrollando una aplicación empresarial (ear) formada por un par de módulos web, otro par de módulos ejb (ejb-jar), un conector JCA (rar) y tres módulos de librerías comunes (jar).

En un proyecto de éstas características (proyecto con varios módulos) cada desarrollador trabaja en uno o varios módulos (en función de la funcionalidad, de su perfil, habilidades o experiencia...), pero no suele participar en todos... Al menos, eso es lo habitual. Sin embargo necesita tener las actualizaciones y los progresos de todos (o la mayoría) de los módulos, debido a las dependencias entre ellos. Estas dependencias inter-proyecto o inter-módulo son las que denominé como dependencias internas en la primera parte de este artículo. Pero ¿ćomo estar actualizados y poder tener las nuevas funcionalidades y servicios que han desarrollado nuestros compañeros para poderlos usar en los módulos que estamos desarrollando? Típicamente esto se hace de dos formas:
  1. Todos los desarrolladores tienen todos los proyectos creados en su IDE y vinculados con SVN o, al menos, los proyectos en los que está trabajando, los proyectos dependientes, y los dependientes de los dependientes (dependencias transitivas), y así sucesivamente... es decir, típicamente todos. Esto es lógicamente un engorro, porque cada vez que alguien realice una refactorización que suponga la creación de un nuevo proyecto, afectará a todo el equipo de desarrollo. Todos los cambios impactan a todos (cambios en la configuración, dependencias, nuevos proyectos, etc...), favoreciendo, además, la incidencia de errores dada la exposición de todos los fuentes a todo el equipo.
  2. Los desarrolladores que trabajan en proyectos que son requeridos por el resto "publican" sus artefactos en SVN o un repositorio común en red. Esta segunda opción introduce complejidad de configuración y coordinación en el equipo y scripts adicionales que realicen esas tareas, ya que hay que "avisar" de cuando hay que actualizar las dependencias... en todo caso: la gestión de las dependencias (en este caso internas) se manejan manualmente vía scripts (típicamente de ant).

Software de gestión de repositorios Maven

El software para de gestión de repositorios Maven sirve precísamente para eso: para crear y gestionar nuestros propios repositorios de Maven. De esta forma tendremos la gestión de dependencias solucionada:
  • las dependencias externas, a través del mismo Maven, usando el repositorio Central. También podemos crear nuestros propios repositorios proxies de otros, reduciendo el tráfico de red.
  • las dependencias internas (o inter-proyecto) con nuestro repositorio.
Veamos el siguiente ejemplo: tenemos un equipo de tres desarrolladores que está desarrollando una aplicación que tiene un módulo JAR, que a su vez es usado por un módulo EJB y otro módulo WAR que usa (necesita) los dos anteriores.
  • El desarrollador A participa en el desarrollo del módulo EJB, y es el único que desarrolla el módulo JAR. Este desarrollador no tiene que resolver dependencias internas, digamos que es un "productor" y debe "publicar" su trabajo para los demás.
  • El desarrollador B sólo trabaja en el módulo WAR: por tanto debe disponer de los otros proyectos. Sería el caso del "consumidor" exclusivo.
  • El desarrollador C trabaja en los módulos WAR y EJB: es decir, es consumidor y productor a la vez. Debe publicar su trabajo, pero también requiere del trabajo del desarrollador A.



En el caso anterior, usando un repositorio remoto con un software de gestión de repositorios, Maven realizará todos los trabajos de sincronización de forma transparente, realizando la publicación de artefactos al repositorio (mvn deploy) para los desarrolladores A y C, y la actualización automática para todos. Lo único que hay que hacer es especificarle la URL del repositorio en los pom.xml de los proyectos, simplificando enormemente la coordinación en proyectos reales típicos (más grandes, complejos y con más desarrolladores).

El software repositorio que yo conozco es Nexus, de la compañía que creó Maven (Sonatype), y la verdad, estoy muy satisfecho con su funcionamiento. No obstante, hay otros también bastante usados como Apache Archiva, o Artifactory. En general, todos parecen cumplir correctamente su misión principal y tienen una instalación sencilla. Al final del artículo puedes encontrar algunas referencias útiles con datos y opiniones sobre Archiva y Nexus. Con independencia de la elección, el objetivo del artículo es dejar claro para qué sirve y por qué nos es tan útil un software de gestión de repositorios. En nuestro caso particular, nos decidimos por Nexus porque usamos eclipse y pensábamos que tendríamos menos problemas si todas las herramientas estaban bien integradas por ser de la misma compañía: Maven, Nexus y m2eclipse.

La verdad, he de decir, que m2eclipse nos ha dado algún problema que otro, especialmente alguno  bastante gordo que nos retrasó en el conocimiento del plugin y cómo funcionaba (p.e.: la opción "Enable Workspace resolution" ha dado problemas en sucesivas versiones del plugin), pero nada que decir sobre Nexus: hasta el momento, perfecto.

Finalmente, SVN, Maven y Nexus conforman una tríada perfecta para empezar cualquier proyecto pequeño adoptando buenas prácticas y un mínimo de coordinación automatizada, permitiéndonos poder escalar a proyectos y grupos más grandes afinando más hacia la integración continua con una buena base.

Referencias:




No hay comentarios :

Publicar un comentario en la entrada

Related Posts Plugin for WordPress, Blogger...
cookieassistant.com