Herramientas para un entorno de varios desarrolladores

Viene de Tutorial de Maven

Basándose en maven se puede montar con varias herramientas un entorno de desarrollo adecuado para proyectos grandes y muchos desarrolladores, veamos cómo.

Sistema de control de versiones

Lo primero es que todos los desarrolladores necesitan intercambiarse los fuentes de código. Un desarrollador va haciendo su parte y cuando la da por buena, tiene que haber un sitio donde pueda poner esos fuentes accesibles a los demás desarrolladores. Para este tipo de taresas es adecuado un sistema de control de versiones, como git, subversion, cvs, etc.

En un sistema de control de versiones lo normal es tener un servidor donde se instala dicho sistema de conttrol de versiones. Cada desarrollador debe disponer de un cliente de dicho sistema de control de versiones, integrado o no con su IDE favorito. Cuando un desarrollador toca el código fuente del proyecto y ve que las modificaciones que ha hecho son correctas, con el cliente del sistema de control de versiones "sube" ese código fuente al servidor del sistema de control de versiones. Los demás desarrolladores, cuando lo deseen y usando el cliente del sistema de control de versiones, pueden obtener una copia de trabajo de los fuentes actualizados con los últimos cambios.

El servidor del sistema de control de versiones es capaz de guardar el histórico de todos los fuentes, quienes han hecho los cambios, que han cambiado en cada momento e incluso comparar el mismo código fuente en dos versiones distintas. Un sitio perfecto para guardar no sólo los fuentes de nuestro proyecto, sino toda su historia de cambios.

El sistema de control de versiones no tiene nada que ver con maven, pero organizar el proyecto con maven de alguna forma deja definida una estructura de directorios estándar para el proyecto, así como la forma de compilarlo, generar documentación, pasar los test, etc. Si subimos nuestros fuentes de acuerdo a la estructura de maven, automáticametne todos los desarrolladores sabrán dónde está cada cosa, como compilar, generar documentación, etc.

Repositorio de jars

Si el proyecto es grande, posiblemente esté compuesto de varios jar y habrá grupos de desarrolladores que trabajarán en unos jar y otros en otros. Los desarrolladores deberán intercambiarse esos jars actualizados para tener la última versión del proyecto. Este proceso manual puede dar lugar a errores y equívocos. Lo mejor es automatizar este intercambio de jars.

El primer paso es hacer que todos los jars que deben compartirse estén en un sitio común, donde cada desarrollador deje sus jar y pueda conseguir los de los demás. Maven busca los jar en repositorios de jars de internet. Hay herramientas, como archiva o nexus que permiten a un equipo de desarrolladores instalar su propio repositorio de jars compartido. Una vez instalado, sólo tiene que configurar su maven para que busque y deje los jars en ese repositorio. De esta forma, cuando un desarrollador tiene una versión nueva de su jar y lo quiere compartir, ejecutando el comando de maven mvn deploy, Si todo está debidamente configurado, cuando los demás desarrolladores compilen su proyecto usando maven, maven se encargará de bajarse del repositorio común la nueva versión del jar y ponerlo en el repositorio local del desarrollador.

Estas herramientas que hace de repositorios de jars suelen poder hacer también de proxys de los repositorios que hay en internet. Esto quiere decir que si la configuramos adecuadamente, podemos hacer que maven baje TODOS los jar de esta herramienta independientemente de dónde esté el repositorio real. Si pedimos por ejemplo una versión de log4j a nexus (por ejemplo), nexus verá si tiene ese jar para entregarlo. Si no lo tiene, irá a internet a buscarlo, se hará una copia local y se lo entregará al desarrollador. La siguiente vez que otro desarrollador pida esa versión de log4j, nexus ya lo tendrá y se lo servirá directamente, sin necesidad de ir a internet a buscarlo por segunda vez.

Herramientas de integración contínua

Hay dos detalles que nos quedan para que nuestro equipo funcione estupendamente a nivel de compilado de código.

Por un lado, hemos visto que si un desarrollador genera un jar nuevo y quiere compartirlo, debe ejecutar el comando mvn deploy. Esto no deja de ser un proceso manual y el desarrollador puede "despistarse" y no hacerlo.

Por otro lado, hay una serie de tareas que conviente hacer con el proyecto con cierta frecuencia, básicamente, asegurarse que lo que hay en el sistema de control de versiones compila correctamente y que pasa todos los test. Se puede encargar a alguien que en su PC se encargue de esta tarea, actualizar todos los fuentes, compilarlos y verificar test. Pero seguiría siendo un proceso manual que el desarrollador según las ganas y lo sistemático que sea haría peor o mejor y al ser un PC, siempre corremos el riesgo de que algo compile y funcione bien en su PC porque en su PC están todos los ficheros necesarios o está configurado de determinada manera. Este riesgo es mayor si esa persona encima es uno de los desarrolladores.

La solución pasa por, en un PC neutral que no sea de nadie, actualizar por ejemplo todas las noches el proyecto con lo último en el sistema de control de versiones, compilarlo y pasar los test. Para esto ayudan las herramientas de integración contínua, como Jenkins o CruiseControl.

Estas herramientas, aunque son configurables, se "tragan" directamente los proyectos java con maven. Una vez instalada y configurada, se encargan de sacar todas las noches lo último del sistema de control de versiones, compilar y pasar test. Pueden enviar correos a los desarrolladores implicados en caso de fallo y suelen tener una interfaz web donde se pueden consultar los resultados de las compilaciones o incluso provocar mediante un click un nuevo compilado. Al estar instalada en un PC "de nadie", suele fallar inmediatamente si alguien se olvida de subir algo al sistema de control de versiones o algún desarrollador, descuidadamente, usa paths propios de su PC (como /user/fulanito/Proyecto/mi_java).