Entre los plugins, recientemente instalé dos, el de Chuck Norris, que hace que aparezcan fotos de Chuck Norris contento si la compilación ha ido bien, o cabreado si ha ido mal, aparte de poner frases aleatorias estilo "Chuck Norris’s first program was kill -9". También puse otro similar, pero con fotos de chicas.

Pues bien, justo ayer, cinco minutos antes, me llaman por teléfono que van a venir de una auditoría de software para ver, entre otras cosas precisamente el Hudson. Así que, como un loco, mirando qué fotos salían en los proyectos para enseñar sólo proyectos de Chuck Norris, no vaya a ser que algún auditor/a se me mosqueara o mosquease.

En su día nos instalamos un repositorio propio para nuestros jar, de forma que estuvieran accesibles para todos los desarrolladores. Para ello usamos archiva, y ha funcionado más o menos bien con sus cosillas. Hace además las veces de proxy con los repositorios de maven que hay por internet. De esta forma, cada desarrollador únicamente debe configurar maven para que busque los jars en el repositorio de archiva y es este el que se encarga de acceder a internet y buscarlos si es necesario.

No hace mucho descubrí que había otra herramienta similar llamada nexus. Como archiva nos hacía cosas raras de vez en cuando (no traía las cosas de los repositorios de internet, no sé muy bien si por culpa de archiva o de nuestra conexión a internet, que va con proxy autentificado. También dejaba ficheros tmp vacíos en el repositorio de vez en cuando). Así que hoy me he decidido a instalar nexus y probar.

La instalación sencilla, un zip que te bajas, desempaquetas y tienes los scripts necesarios de windows, linux, solaris… para instalar nexus como servicio y arrancarlo y pararlo. Eso sí, hay dos versiones, la gratis con menos posibilidades de autentificación/seguridad, y la de pago que tiene de todo. La gratis en principio tiene lo necesario: gestión de usuarios y permisos propia, funciones de proxy y repositorios propios.

La interface web mucho mejor que la de archiva. Bastante más bonita y agradable. Rápidamente me puse en ella a configurar nuestros repositorios, tanto los propios, como los repositorios que son proxy de los estándar de internet (que ya vienen configurados los de maven central, apache y codehaus).

Y vamos a las cosas que me han gustado y que me han decidido a intentar el cambio en serio:

1. Es más estricto que archiva con los SNAPSHOTS y las releases. Archiva permite subir y bajar jars snapshots y no snapshots de repositorios snapshots y no snapshots indistintamente. Somos los desarrolladores los que tenemos que tener cuidado de dónde subimos los jar. Nexus es más estricto, si intentamos subir un jar no snapshot a un repositorio que hemos marcado como snapshot, protesta. Y al revés también.
2. Permite programar tareas de mantenimiento periódicas y entre ellas, la que veo más útil en nuestro caso: permite que se limpien automáticamente las versiones snapshots más antiguas o indicar cuántos snapshots quieres como máximo por cada jar. En un entorno de desarrollo como el nuestro en el que Hudson genera y sube muchos snapshots gigantes todas las noches, una limpieza periódica se hace imprescindible.
3. Cuando configuras un repositorio como proxy de uno externo, tienes más visibilidad de si tiene o no conexión con el repositorio externo, si se ha bajado algo de él y qué se ha bajado.

Para ser justos, estoy comparando una versión antigua de archiva, que instalé hace mucho, con la última de nexus. Es posible que las versiones más modernas de archiva hayan mejorado o permitan hacer estas cosas que digo que hace nexus.

Hace un tiempo instalé y probé Sonar, una estupenda herramienta que genera un informe muy vistoso y cómo de usar sobre las métricas de nuestro código, Pero al final tuve que abandonarlo. El compilado con maven generando el informe era muy lento y el servidor web de sonar acababa dando timeout por la carga a la que se veía sometido. Al final el compilado con maven fallaba por este timeout y eso me hacía totalmente imposible integrarlo con hudson, para obtener los informes actualizados todas las noches.

El otro día me dio por revisar cómo iba el desarrollo de Sonar, qué nuevas versiones habían sacado, qué problemas habían resuelto … y me resulto interesante que habían corregido/añadido una nueva "feature", la SONAR-764, en la que básicamente dicen que cargan el trabajo en el plugin de sonar para maven en vez de en el servidor web de sonar. Esto tiene pinta de que puede solucionar los problemas de timeout con el servidor de sonar. Así que a ello, descargar, instalar y probar.

Las primeras pruebas manuales funcionan a la perfección. Eso sí, los compilados tardan casi el doble ya que deben generar además todos los reportes de métricas, pero ya no tengo el problema de timeout y el informe acaba correctamente y se publica en el servidor web de sonar.

Siguiente paso, hacer que Hudson genere con sonar ese informe todas las noches y lo publique. Y ahí empezaron los problemas. Algunos proyectos tardaban más en compilar, pero lo hacían todo bien y el informe se publicaba. Pero otros proyectos, no necesariamente los más grandes, acababan dando una excepción en el compilado, indicando que "Sonar no se puede ejecutar" y un NullPointerException en los MOJOS de maven. Tras unas investigaciones rápidas, no llegué a ninguna conclusión ni ningún arreglo. El mismo proyecto compilado manualmente en el sitio donde lo hace hudson funciona, pero si lo hace hudson no funciona.

Así que mi gozo en un pozo. Desinstalar sonar y esperar a una nueva ocasión.

Ayer, jugando con Hudson, descubrí una característica interesante que podía solucionar algunos de los problemas que teníamos y que además me ha dejado alucinado de la facilidad de instalación. Es la posibilidad de poner a otros ordenadores como esclavos de Hudson, de forma que envíe los compilados de los proyectos a ellos. De esta forma, una sola instalación de Hudson puede disponer de varios ordenadores para hacer los compilados y repartirlos entre ellos según una serie de criterios.

Poner un ordenador esclavo de Hudson en muy sencillo. Desde la misma página web de nuestra instalación de Hudson le damos a "añadir nodo esclavo". Hay varias formas de hacer que Hudson hable con el ordenador esclavo y yo elegí "instalar un servicio hudson-esclavo". Para esta opción, solo hay que dar la IP o nombre del ordenador, un usuario y password con permisos de administrador y luego los detalles "técnicos", como el path del ordenador esclavo donde queremos que hudson trabaje, dónde tiene instalado java o maven, etc. No es necesario que esos paths estén compartidos o sena públcos.

Pues bien, una vez dados estos datos, y esto es lo que me ha alucinado, hudson el sólito copia unos jar en el directorio remoto que le hemos dicho, instala un servicio y lo arranca. A partir de ahí, ya tenemos nuestro ordenador esclavo funcionando para nuestro Hudson.

¿Cómo repartimos nuestros proyectos?. Pues hay varias formas:

1. Dejar que Hudson reparta como quiera.
2. Asignar un proyecto (desde su configuración) a un esclavo concreto.
3. Poner etiquetas a los distintos ordenadores esclavos y luego decir en el proyecto que puede ejecutarse en cualquier ordenador que tenga determinada etiqueta.

Esta última característica está pensada para que las etiquetas sean estilo windowxp, linux, java5, java6, etc en función del sistema operativo o versión de java que tenga instalado. De esta podemos decir que un proyecto debe compilarse en cualquier ordenador esclavo que tenga la etiqueta java5 y que, por supuesto, tendrá instalado java 5.

En nuestra web de hudson, donde habitualmente se ponen las barritas de progreso del compilado, veremos los distintos ordenadores, cada uno con sus barritas correspondiente. Pinchando uno de esos ordenadores, veremos sólo los proyectos asignados a ese ordenador.

La posible pega de todo esto es que los compilados paralelos pueden ser problemáticos, sobre todo si hay proyectos que dependen unos de otros y se compilan a la vez. La versión más moderna de Hudson, la 1.323, permite poner un "check" en la configuración del proyecto, indicándole que se quede en la cola de espera si hay algún proyecto del que depende que esté compilando en ese momento. Ese check tiene un pequeño bug, y es que no se puede salvar, así que hay que marcarlo tocando directamente en el config.xml del proyecto dentro de los directorios de Hudson.

Hace tiempo que usamos Hudson como herramienta de integración continua. Básicamente saca automáticamente todas las noches los fuentes de los proyectos que se han tocado durante el día, los compila y si hay errores de compilado, manda un correo-colleja a los que han tocado el código. Hudson proporciona una interface web, de forma que con nuestro navegador podamos ver en todo momento si los proyectos compilan, qué fallos de compilado tienen, quién ha tocado, qué ha tocado, etc.

Sin embargo, hoy he descubierto que tiene un "jueguecito". A Hudson se le pueden instalar fácilmente plugins, por ejemplo, todos los de métricas (checkstyle, pmd, findbugs, etc), de forma que además de compilar, pasa todas estas métricas y genera unos informes visibles desde el navegador. Pues el jueguecito consiste en un plugin adicional que se puede instalar, el Continuous Integration Game.

Una vez instalado este plugin, debemos activarlo en la configuración de cada proyecto (junto con los informes de métricas). De esta forma, cada vez que compila, Hudson asigna o quita puntos a los desarrolladores que ese día han tocado el código. Les da un punto si compila correctamente, les quita diez si falla, les da puntos si hay test nuevos que pasan, les quita puntos si fallan los test, les da puntos si han corregido métricas, les quita si hay más violaciones de las mismas. Al final, tenemos una tabla de jugadores (desarrolladores) ordenada del de más puntos (el mega-top-developer que lo puede todo) hasta el de menos puntos (el torpe-hasta-decir-basta).

Quizás es injusto para un solo compilado, ya que si falla, se quita diez puntos a todos los que han intervenido, independientemente de que sean o no los causantes. Pero está claro que por estadística, a la larga, el torpe interviene en casi todos los compilados fallidos y el listado de puntos se acabará ordenando de una forma lógica.

Es una chorrada, pero supongo que si hacemos una bromillas con el segundo, el último y animamos al primero a conservar su puesto, puede haber verdaderos piques por hacer el código bien. Pues ahí ha quedado todo instalado, a ver mañana quién es el primero de la lista. Incluso podemos poner que todos los lunes los de la mitad de abajo inviten a café a los de la mitad de arriba o que echen un euro en un bote.

Como de todos es sabido, soy un "pupas" y las cosas nunca me funcionan bien a la primera ni a la segunda. Comenté hace unos días que había instalado y probado sonar. Las primeras pruebas fueron bastante bien, pero con el uso me he ido encontrando las pegas.

Realmente, pegas no tiene muchas, en realidad, sólo le he visto una, pero molesta bastante.

El plugin de sonar para maven compila nuestro proyecto y pasa todas las métricas. Luego, se pone a insertar en la base de datos de sonar toda esa información. Durante ese tiempo, el servidor web de sonar se queda bastante pillado y responde muy lentamente. El problema es que en ese ordenador tenemos también instalado redmine, archiva y hudson. Todas esas "web" dejan de responder o responden muy mal mientras se están insertando estadísticas en la base de datos.

La siguiente pega, que es más de lo mismo, es que el plugin de sonar para maven también intenta acceder a la web de sonar. No sé el motivo exacto, pero me estoy temiendo que es para avisar al servidor de sonar de que hay nuevas estadísticas en base de datos y empiece e echar unas cuentas, organizar los datos o algo. El caso es que cuando el plugin de maven termina, el servidor sonar puede tirarse diez u once minutos "procesando estadísticas", según pone en la web. Durante ese tiempo, todo el ordenador va muy lento y dejan de responder el hudson, el redmine y el archiva.

Y otra pega más, que viene a ser lo mismo, es que cuando el plugin de maven intenta acceder a la web de sonar, tiene para mi gusto un timeout muy corto, dando error rápidamente si no consigue conectarse. Basta con que pille a Hudson compilando para que aquello tenga ciertas probabilidades de error en la conexión. Y no te digo si le pilla procesando estadísticas del mismo sonar de un proyecto anterior. Ahí es imposible conectarse y hay que esperar. Esta pega es realmente gorda, porque me impide meter el plugin de sonar en el hudson, de forma que además del compilado nocturno, se calculen las métricas nocturnas. El compilado del primer proyecto funciona o no, según le de, pero los demás nunca funcionan.

Total, que voy a tener que agenciarme otro pc/estación de trabajo para instalar exclusivamente sonar. Y aun así, quizás hudson no pueda publicar las estadísticas si pilla a sonar "procesando" información.

Ah, el ordenador no es lo más mejor del mundo, pero tampoco es viejo. Supongo que tendré que probar en un linux en vez de un windows, o quizás es una estación de trabajo solaris.

Así que al terminar la reunión, me fuí a comer y me pasé la tarde totalmente desmotivado para el trabajo. Me puse a "internetear" en busca de cosas interesantes y encontré Sonar.

Sonar es una herramienta para la medición de métricas del código java (pmd, javancss, findbugs, … todo junto), pero aporta un par de cosas que me han parecido interesantes.

En primer lugar, al arrancar Sonar, se arranca un servidor web. Las métricas de nuestros proyectos estarán accesibles en el navegador vía web. Bien, de momento nada del otro mundo.

La parte interesante es que las métricas se generan con un plugin de maven y ese plugin busca al servidor web para añadirle el proyecto (si es la primera vez que lo compilamos con el plugin) o para actualizarle las métricas. Esto no deja de ser una pequeña maravilla, puesto que se puede ejecutar el plugin en nuestros compilados nocturnos, de forma que siempre tendremos en el servidor web de Sonar las métricas actualizadas al día. Es más, Sonar guarda las estadísticas de cómo evolucionan las métricas, así que con el tiempo tendremos un gráfico que indica si cada vez hay más o menos violaciones de métricas en el proyecto.

La segunda cosa que me ha resultado interesante es la forma de presentar los resultados. Aparte de las obligadas tablas con valores, se presentan con bloques de colores por proyectos, paquetes y clases. Me explico, hay una vista en la que salen los proyectos como bloques de colores, cada bloque del tamaño proporcional al tamaño del proyecto. El color es rojo si el proyecto tiene muchas violaciones de métricas y va tirando a verde según esté mejor. Pinchando el cuadro de un proyecto, se cambia la vista a los paquetes en ese proyecto, nuevamente con rectángulos de distintos tamaños y colores. Pinchando en uno de esos paquetes, aparecen las clases con el mismo tipo de presentación visual.

Esta forma de presentación es realmente interesante si se pretenden arreglar las métricas de un proyecto que esté mal. Con ella se puede navegar rápidamente e identificar los proyectos, paquetes y clases más conflictivos, centrándose primero en ellos.

Y ya puestos, también tiene una nube de tags en el que cada tag es una de las clases del proyecto. Los tags más gordos son las clases más horribles "métricamente" hablando. Así que incluso es mucho más sencillo identificar de un sólo vistazo cual es la primera clase que deberíamos arreglar de todos los proyectos que tenemos. Por supuesto, te presenta el código fuente de la clase indicando en qué puntos hay violaciones de métricas y cuales.

En este enlace tienes explicadas las distintas pantallas de Sonar y puedes ver los cuadraditos y nubes de tags que menciono.

Actualmente metemos el plugin pmd en maven de forma que si fallan las métricas, falla el compilado. Es la forma de garantizar que la gente codifica siguiendo las métricas desde el principio. Sin embargo, tenemos mucho código con métricas horribles, ya que nunca nos habíamos preocupado en serio de ello. Sonar me va a permitir identificar los peores trozos de código e ir arreglándolos poco a poco.

En fin, Sonar es una herramienta que intentaré ver cómo integro en los proyectos con Hudson (creo que hay plugin de Sonar para Hudson), que me dará entreteniento unos días y si quieren que trabaje en algo serio, que no me metan en reuniones desmoralizantes.

La primera herramienta, bitten, la descarté sin probarla, porque parece que es como un plugin para Trac, que de momento no puedo usar, aunque quiero, porque no soporta CVS. Tampoco me fijé demasiado si se puede arrancar suelta, pero me hace la impresión de que sí.

Así que me fuí con la segunda, Hudson.

Una maravilla de herramienta.

La instalación muy sencilla. Se baja uno un .war y ejecuta java -jar hudson.war. Abres el navegador y ya tienes lista la página de hudson, preparada para configurar y añadir proyectos.

La configuración sencilla y toda a vía web. Todavía no he tenido que tocar ningún fichero externo, salvo la variable HUDSON_HOME antes de arrancar, para decirle a Hudson dónde debe situar todo.

Los proyectos se añaden fácil, copiando unos de otros, indicando el repositorio CVS, subversion o lo que sea, si es de maven, de ant, etc.

Sin embargo, lo que más me ha gustado de todo, es que es "inteligente". Trabajando con varios proyectos maven es capaz de ver las dependencias entre proyectos y automáticamente, si un proyecto necesita compilarse, después compila todos los que dependen de él. Y al revés, para mirar si un proyecto necesita compilarse, mira también automáticamente si necesitan compilarse los proyectos de los que depende.

Dicho de otra forma, si tengo un proyecto LIBRERIA y otro proyecto PROYECTO que usa librería, si meto algo en CVS de LIBERIA, me compial LIBRERIA y automáticamente después compila PROYECTO. Y al revés, cuando mira a ver si hay algún cambio de CVS en PROYECTO para ver si necesita compilarlo, mira automáticamente también los posibles cambios en CVS de LIBRERIA.

Esto tiene la ventaja de que garantiza que todos los proyectos están siempre actualizados y compilados con las últimas librerías disponibles de las que dependen y que si se toca una librería, se detecta rápido si eso estropea el compilado de un proyecto.

Sin embargo tiene una "pega" o efecto curioso. Basta tocar un fuente en una librería para que Hudson se ponga a compilar como loco unos proyectos y otros, y los compilados de unos provoquen a su vez los compilados de otros. Por un simpel fuente tocado, puede pasarse un par de horas compilando todas las dependencias y las dependencias de las dependencias (cosa, por otro lado, lógica).

En cuanto al resto, también estupendo. Todo lo que se te ocurre configurar, esta configurable via web (el servidor de email, cuantos logs quieres que guarde, comando para construir los proyectos si no es el de defecto, los path de java, ant, maven, sh, etc, etc, etc. También puedes configurar cuántos hilos de compilado paralelos quieres, de forma que pueden compilar hasta n proyectos simultáneos, eligiendo tú el valor de n.

Me queda pendiente probar bitten, pero de momento Hudson lleva todas las papeletas de quedarse como herramienta.