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:




martes, 9 de febrero de 2010

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

Banco de experiencias (V)


El orden es el placer de la razón pero el desorden es la delicia de la imaginación.
-Paul Claudel.

El desarrollo de software aúna una fascinante mezcla de pensamiento divergente (o creativo) con conceptos técnicos y prácticas metódicas. Para que un desarrollador (y especialmente un equipo de desarrollo) alcance los mayores niveles de eficiencia y productividad, las herramientas utilizadas deben garantizar la seguridad del proceso, pero siempre de forma proporcional a la envergadura del proyecto y manteniendo compatibilidad con el proceso creativo sin ahogarlo. Hay herramientas libres que nos ayudan a mantener este este delicado equilibrio entre orden y libertad para todo tipo de proyectos de forma sencilla e impecable.

Éste, como el resto de los artículos de la serie "banco de experiencias", no pretende ser un artículo más de documentación sobre las herramientas aquí comentadas ni encontrarás tampoco el enésimo tutorial sobre el asunto. Hay mucha documentación en la red y a lo largo del artículo suelo ofrecer información y referencias suficientes para que puedas profundizar en el tema. La idea de estos artículos es exponer buenas prácticas y comentar mi punto de vista, basado en mi propia experiencia profesional, sobre la utilidad real y pragmática de los temas abordados. Sin demagogia rimbombante ni publicidad interesada. Simplemente la síntesis de mi experiencia subjetiva.

Subversion

Subversion (también conocido simplemente como svn) es probablemente el mejor sistema de control de versiones centralizado que existe. Sin entrar en la discusión Centralizado vs Distribuido (DVCS), lo que si está claro es que el control de versionado es un aspecto crítico de cualquier proyecto de software.

En todo caso, si has llegado hasta aquí y no has usado nunca un software de control de versionado (VCS) la recomendación es clara: úsalo. Debes usarlo. Aunque tu proyecto sea muy pequeño. Aunque sólo exista un desarrollador. Has de asumir que, de la misma forma y con la misma naturalidad que usas un IDE o un compilador, deberás usar un VCS. Es absolutamente esencial. Si ya tienes claro que hay que usar uno y has decidido usar uno centralizado (o simplemente sueles usar otro, como CVS, por ejemplo), la recomendación también es clara: usa svn. En la wikipedia puedes consultar por qué SourceForge.net, Apache o Google Code lo eligieron, así como la documentación y herramientas disponibles.

Como decía, un software de control de versiones es necesario aunque el proyecto sea pequeño ya que te garantiza un seguimiento de cambios que te puede ahorrar muchas horas de trabajo. Si tienes clara la diferencia entre un editor de texto y un procesador de texto, entenderás enseguida la diferencia de usar backups de tu directorio de código y usar un VCS. No obstante, hay otro aspecto importante de los VCS que no suele ser tan comentado (quizá por obvio) y es su dimensión como herramienta colaborativa. Si de forma individual es extremadamente importante, para un equipo es absolutamente imprescindible. Un equipo no puede trabajar de forma "decente" sin Subversion. La idea de no usar un VCS o de usar uno bloqueante (tipo Visual SourceSafe) es una pesadilla para no dormir: "¡eh, cuidado!, no toquéis que voy a tocar yo" "¡Oh, mierda!, ya ha tocado alguien. ¡A ver ahora cómo lo arreglamos!"... o "¡fulanito, desbloquea el fichero que necesito añadir un método de la clase!" "¡No, espera que termine!"... Qué pesadilla. Me recuerda a aquellas herencias arcaicas de los programas COBOL de no pasarte de la columna 73 y poner los asteriscos en la columna nº 7... Bufff.

Trabajar con svn en equipo es lo más parecido a hacerlo como si estuvieses tú sólo. Si las tareas están repartidas, los conflictos son muy poco frecuentes (para que existan, dos desarrolladores deben haber modificado la misma línea simultáneamente antes del último commit) y cuando los hay, se suelen solucionar en pocos segundos. Es muy gratificante comprobar cómo un equipo numeroso puede trabajar en una aplicacion Web (un tipo de proyecto con un alto grado de colisión y concentración de trabajo) de forma cómoda y fluida sin problemas.

Maven

Aunque llevamos oyendo hablar de Maven desde hace varios años (Maven tiene ya 8 años), la adopción hasta hace cuatro o cinco años ha sido puntual y conceptual. Es desde la aparición de Maven2 (con su nueva arquitectura revisada) cuando realmente empieza a incorporarse (aunque también de forma muy lenta) a los distintos proyectos open source y esto ha hecho que en la comunidad de desarrollo comencemos a interesarnos y a integrarlo en nuestros proyectos. A mucha gente le ocurre que, tras leer sobre Maven y Ant, entiende las diferencias entre ellas, pero no alcanza a concretar por qué es tan importante y para qué le sirve realmente (qué le aporta que no tenga ya). Para aclarar definitivamente este punto simplemente hay que preguntarse cómo realizamos el proceso de construcción (generación de empaquetados y otros artefactos) en nuestros proyectos, y esto nos dará la respuesta. Veamos las opciones:
  1. Construimos con nuestra herramienta de desarrollo (Eclipse, Netbeans, etc...).
  2. Construimos con un fichero (build.xml) ant que nos hemos hecho nosotros.
Si se trata de un pequeño proyecto de un sólo módulo (un war, un jar, etc...) y/o el ciclo de vida de la aplicación es muy reducido (es una pruebecilla nuestra, una pequeña aplicación de las que se hacen en casa en zapatillas, etc) no importa, claro. ¿Qué más da? La he hecho yo y podré volverla a construir con mi IDE favorito o con mi Ant dentro de un año cuando tenga que hacer un cambio. Incluso aunque cambie el IDE o cambie mi entorno, podré adaptarme a la situación sin más problemas, hacer las correcciones y volver a generar el empaquetado.

Ahora bien, si nos situamos ahora un escenario profesional, el tema cambia mucho. A continuación expondré los problemas que nos encontramos con esas formas de construir aplicaciones. Seguramente ya te habrás encontrado con ellos, y si no, es porque el proyecto no era lo suficientemente grande o, simplemente, es una cuestión de tiempo que te los encuentres.
  • Homogeneidad. Cada desarrollador tiene sus costumbres y sus ubicaciones (paths) para sus proyectos, librerías, ubicación del JDK, etc. Es difícil e incómodo homologar a todo un equipo de desarrollo en una única estructura de ficheros. Aunque Sun hiciese su propuesta de convenciones para proyectos (estructura y nombrado) hace mucho tiempo, casi ningún IDE lo respeta al 100%. Además, la heterogeneidad de los distintos Sistemas Operativos no hacen más que complicar la posibilidad de tener una estructura y ubicación homogénea para todo el mundo. Eso hace que los ficheros de proyecto (.nbproject, .project, etc) no puedan ser portados de unos desarrolladores a otros ni compartidos entre distintas máquinas. Esta estructura acaba teniendose que modificar manualmente en los distintos IDE's o en el fichero build.xml de ant. En el caso de los IDE's es particularmente grave, ya que la información de librerías, por ejemplo, descansa en la configuración local del IDE de cada desarrollador, que suele ser distinta para cada uno, con lo cual la construcción se torna algo tremendamente frágil y poco transparente.
  • Reproducibilidad. Necesitamos realizar tareas forma constante y estable nuestro proyecto: construccion, pruebas unitarias, informes, etc... Repetibles en el tiempo (hoy y dentro de un año) y en el espacio (en mi máquina de desarrollo, en integración, en preproducción...). Necesitamos fijar parámetros que no están implícitos en el proyecto en si y que acaban también fijados en los IDE's o en el script ant: versión de Java, versiones de librerías, destino de cada librería (sólo para compilar, sólo para desplegar con la aplicación, para compilar y desplegar...), ficheros de configuración, etc... Esto dificulta el mantenimiento y oculta información esencial del proyecto. Si el proyecto se sube a SVN y no lo volvemos a tocar en un año, a menudo nos encontramos con que las partes esenciales del proyecto han quedado ocultas en IDE's (o lo que es peor, se han perdido porque eran parte de la configuración local de un miembro del equipo) o permanecen en un script de ant poco amigable para modificar.
  • Gestión del cambio. Algo tan común como añadir una nueva librería al proyecto o realizar una actualización de una existente tiene demasiado impacto en el equipo hasta resultar ligeramente traumático: todos deben realizar las tareas de la descarga y localización de las librerías, la configuración de su IDE y de su proyecto y/o la adaptación de sus ficheros ant. Incluso un equipo de desarrollo con normas rígidas y paths homologados, además de sufrir esta falta de libertad, sigue estando expuesto a este tipo de problemas.
  • Gestión de dependencias (externas). Este es sin duda el aspecto más importante, por delicado, y por el impacto de sus consecuencias. Imagina el siguiente proyecto: un EAR compuesto por dos módulos WAR, tres módulos EJB y un par de módulos de de librerías comunes (jar). Uno de los desarrolladores añade al EAR una librería "A" que necesita uno de los módulos EJB y otro desarrollador añade otra librería "B" que necesita uno de los módulos JAR. Ambas librerías tienen sus propias dependencias: la librería "A" requiere de xxx-commons-2.3 y de asm-2.1, la librería "B" de yyy-commons (que a su vez depende de xxx-commons-1.5) y asm-3.0. Ya tenemos el problema servido. Como ya comenté en el artículo "Errores comunes de despliegue JEE", este tipo de problemas algunas veces sólo se presentan aleatoriamente, ya que el problema puede presentarse o no en función de la secuencia de carga del ClassLoader de la máquina de turno. Esto ocurre muchas más veces de lo que nos pueda parecer a simple vista, si bien en la mayoría de los casos los conflictos no plantean problemas porque muchas librerías mantienen una compatibilidad perfecta hacia atrás. En mi experiencia, es habitual que ocurra sin embargo con grandes frameworks tipo Hibernate, Spring, Struts, etc, con consecuencias muy desagradables. Sin Maven, la gestión de dependencias no la hace nadie, o lo que es lo mismo, se hace manualmente si el equipo de desarrollo es muy cuidadoso y está muy bien coordinado.
  • Gestión de dependencias (internas). Otro aspecto de los proyectos medianos con varios módulos interdependientes entre si es que, además de tener que realizar gestión de dependencias de librerías de terceros tenemos que gestionar nuestras propias dependencias. Por ejemplo, para el caso anterior, si ambos WAR necesitan de los proyectos JAR de librerías comunes, todos los desarrolladores de los WAR deberán tener también que tener los proyectos (código fuente incluído) de dichos JAR, para estar debidamente actualizados... O bien buscar otra forma de distribución manual de empaquetados que también exigirá un esfuerzo adicional de coordinación.

Como puedes suponer a estas alturas, Maven es una solución perfecta a todos los problemas comentados anteriormente (salvo para el último punto, para el que se requiere un colaborador, pero eso lo comentaré en la segunda parte). Maven es y sirve para muchas cosas (compilación, paso de pruebas unitarias, control de calidad, etc) pero, fundamentalmente, es la mejor herramienta de construcción posible. Hasta ahora, para una construcción lo más homogénea y reproducible posible necesitábamos unas normas (o convenciones) y ant. Pero ant es un lenguaje específico de dominio para la construcción de proyectos: te tienes que crear tus propios scripts basado en tus convenciones y el esfuerzo de mantenimiento es exponencial a la envergadura del proyecto. Maven ya te aporta ambas cosas: convenciones (sobre disposición de directorios de proyecto, por ejemplo) y todo el trabajo listo para usar sin tener que configurar nada. Con Maven puedes realmente bajarte unos fuentes y ejecutar un "mvn build" sobre el directorio que contiene el "pom.xml". Y tener en poco tiempo todos los empaquetados, un informe de construcción, pruebas unitarias realizadas, etc, etc.. con configuración cero.

No obstante, el punto fuerte (e incluso espectacular) de Maven es la gestión de dependencias: sólo por la gestión de dependencias transitivas que realiza de forma automática, ya merece la pena con creces. En este tema me recuerda a los repositorios de Ubuntu. Cuando quieres una librería, añades la dependencia y la versión que quieres de las disponibles y él se encargará de aprovisionarse de todas las dependencias transitivas adicionales.

Incluso aún respetando las convenciones de Maven (te las puedes saltar si especificas en el pom.xml cuáles son tus directorios) Maven te ofrece toda la libertad posible: permite que un equipo trabaje con IDE's heterogéneos: cada desarrollador con su IDE favorito. Lo único que debes subir a SVN son los fuentes y el pom.xml. Podrás construir el proyecto de forma repetible, independiente del IDE, ejecutar las pruebas unitarias y olvidarte de problemas de librerías.

Obviamente no te vas a olvidar de tu IDE o de ant. Toda esta maravilla de Maven tiene un precio: el rendimiento. Un build con Maven te lleva más segundos de los que estás dispuesto a considerar como aceptables para tu trabajo de desarrollo habitual. No es aceptable desarrollar realizando builds con Maven. Por lo menos para mi. Por eso yo continúo realizando los ciclos de iteración compilación-despliegue-pruebas con mi IDE. Maven lo dejo para realizar las construcciones, para subir a svn proyectos autónomos y autogenerables y para poder realizar las integraciones y las puestas a preproducción de una forma segura y repetible.


En esta primera parte he expuesto 2 de 3 de las herramientas más esenciales para el desarrollo en equipo de proyectos Java (especialmente JEE). En el siguiente artículo cerraré el círculo con la herramienta que falta: un gestor de repositorios de Maven. Y explicaré cómo, con tan sólo esas tres herramientas, tenemos un entorno de trabajo potente y seguro para equipos de tamaño mediano sin rígidas normativas ni procedimiento burocráticos.

Referencias:

(continuación: Parte II)
Related Posts Plugin for WordPress, Blogger...
cookieassistant.com