2 meses después de Hudson

2 meses después de implantar Hudson como servidor de integración continua dentro del modelo de construcción de software de mi equipo de desarrollo, llega el momento de hacer valoraciones y un poco de retrospectiva.

Por qué Hudson

Existen varios servidores de integración continua disponibles a coste cero además de Hudson, como Cruise Control, Continuum y Luntbuild. En su momento estuve probando Cruise Control pero finalmente elegí Hudson por su mayor facilidad de uso, es realmente intuitivo y muy vistoso, junto con su volcada comunidad y número de plugins en constante crecimiento, que ofrecen una cierta seguridad en el soporte para la integración con otras herramientas.

Para los que no tengais mucho tiempo para hacer vuestras propias pruebas, podéis echar un vistazo al estupendo estudio que hicieron en Xnoccio.

Dificultades

Como ante cualquier intento de cambio significativo en la rutina de un equipo, la principal dificultad suele ser de naturaleza humana y no técnica. Cuando hablé de ello, sólo recibí muestras de escepticismo e indiferencia, en definitiva resistencia al cambio. Ya me pasó con el uso del testing, que costó más de la cuenta implantarlo pero que hoy todos aprecian su valor.

Como además coincidió con que ibamos hasta el cuello de trabajo, ya no es que no tuviera tiempo (en realidad Hudson se instala y configura en 5 minutos) es que no me cabía una tarea más en la cabeza. Así que la cosa se fue alargando hasta que un nuevo compañero se atrevió a instalarlo en nuestro servidor de demos. 2 meses después y con 5 proyectos ya configurados, las dudas y la resistencia se han esfumado. Eso sí, algún programador aún podría sacarle más partido si quisiera.

La única dificultad técnica vino en forma de OutOfMemory después de hacer el build de nuestro proyecto estrella. La fase de testing dura más de media hora y creaba los informes con un log bastante grande debido a la baja categoría de log configurada. Esto provocaba el OutOfMemory durante el análisis del parser dom de Hudson. Lo raro era que por más memoria que le asignaramos seguía fallando. La solución fue tan sencilla como subir la categoría del log a error, pero en mi opinión deberían mejorar ese parser porque tampoco los informes eran tan enormes.

Qué hace Hudson por mi

Todos nuestros proyectos cuentan con un script Ant para realizar las tareas de build, testing y varios tipos de revisiones de código que forman parte de nuestro modelo de construcción de software.

Hudson se encarga ejecutar este script sobre la última versión del proyecto de forma automatizada, bajo demanda o planificada periódicamente, para posteriormente publicar los correspondientes informes con gráficas de tendencias y detalles muy cuidados. De este modo se puede disponer de toda la información sobre la salud de un proyecto actualizada y disponible a sólo un par de clicks de ratón.

En concreto las tareas que se ejecutan son:
  • Build. Compila, copia y, en algunos casos, genera código como los ficheros de mapeo Hibernate. En definitiva construye la aplicación para poder ejecutar los tests sobre ella.
  • Test. Ejecuta todos los tests definidos para el proyecto.
  • Checkstyle. Ejecuta el analizador de código Java Checkstyle para obtener un informe de la calidad del código. Revisa todo, desde sintaxis a tamaños, métricas, defectos de programación, código copy/paste, javadoc, etc. La configuración por defecto es, en mi opinión, excesivamente rigurosa con la sintaxis y el javadoc. Recomiendo dedicarle un rato y crear tu propia configuración.
  • FindBugs. Ejecuta el analizador de código Java FindBugs en busca de posibles defectos y malas prácticas de programación que no cubre Checkstyle. Es bastante listo.
  • Tareas abiertas. Detecta los todo y fixme contenidos en el proyecto.
Una de las cosas que hace Hudson que más me gusta, es que en la pantalla de cada build te muestra los comentarios hechos en los últimos commits. Esto es realmente útil para hacerte una idea rápida de por donde va el desarrollo y que se hizo el último día.

Futuro

A corto plazo quiero añadir las siguientes tareas:
  • Cobertura. Sin duda la métrica que nos falta es el nivel de cobertura de los tests sobre el código del proyecto. Hice mis pruebas con el mismo Cobertura pero daba un extraño error con unas clases de nuestro proyecto estrella. Así que probaré EMMA ya que con su plugin para Eclipse no he tenido problemas.
  • Selenium. Hasta ahora todos los tests ejecutados son a nivel de código Java. Una vez probadas las bondades del testing en este nivel, es el momento de dar el siguiente paso y llevarlo a la parte web. Si bien hemos probado Selenium, sólo lo hemos usado para cargar formularios muy largos o hacer un tour por todas las pantallas de la aplicación, pero siempre ejecutándolo luego de forma manual. El objetivo es usarlo más profundamente y automatizar también este tipo de tests.
  • Despliegue. Otro paso lógico, una vez construida la aplicación es hacer que se despliegue automaticamente en nuestro servidor de demos. Además de que resulta imprescindible para los tests Selenium. De hecho en principio sí teniamos el despliegue configurado pero nuestro servidor de demos tiene poca memoria, de modo que en pocos días había que reiniciarlo porque daba un OutOfMemory y no hay más. La solución pasa por automatizar también un reinicio del servidor.

Beneficios

Las ventajas de la integración continua son obvias, (1) detección temprana y automatizada de errores, (2) disponibilidad inmediata de las últimas versiones de los artefactos generados, (3) conocimiento actualizado del estado y calidad del código del proyecto y (4) ahorro del tiempo que supone la automatización de las tareas que forman parte del modelo de construcción del proyecto.

Ahora cada mañana lo primero que hago es navegar por nuestro Hudson. Basta con un par de minutos para revisar el estado de cada proyecto y tomar las medidas necesarias para que el equipo pueda iniciar la corrección de cualquier fallo detectado o situación sospechosa. Un par de minutos.

Además en estos 2 meses ha dado tiempo a observar otros gratos efectos secundarios a la implantación de Hudson.
  • Mayor calidad del código. Antes de implantar Hudon ya habiamos empezado a usar Checkstyle desde Eclipse pero sólo han empezado a verse verdaderos resultados al automatizar las revisiones diariamente y publicar los informes.
  • Disminución del número de tests fallidos. Antes algunos tests dejaban de funcionar y se podían quedar así semanas y semanas. Normalmente hasta que me daba cuenta yo y obligaba a arreglarlos. Ahora con Hudon en plan chivato intervengo mucho menos.
  • Mejores tests. El hecho de tener que arreglar los tests ha servido para comprobar de primera mano la importancia de programar tests repetibles e independientes.
  • Mayor sentido de la responsabilidad del código. Poco a poco se va notando que cada programador cuida más su código y el proyecto en general. Nadie quiere romper una build y empieza a verse en los comentarios de los commits como toman la iniciativa para reducir las faltas de las revisiones de código.

Y, por qué no decirlo, también está la satisfacción de estar creando un verdadero modelo de construcción de software moderno, ágil y que cuida la calidad.

6 comentarios :: 2 meses después de Hudson

  1. No puedo estar más de acuerdo con esta descripción de beneficios de Hudson. Hudson ya se ha convertido en un must-have haya donde me toque trabajar.

    El próximo paso será el uso de sonar (http://sonar.codehaus.org/) ya que en mi próximo proyecto parece que usaremos maven. Te recomiendo que le eches un vistazo porque en una sóla pantalla puedes tener resumidas un montón de métricas de tu proyecto, y "parece" que gracias a maven no necesita excesiva configuración tampoco.

    Salu2

  2. Muy buen resumen Julio. Por cierto, Sonar me parece excelente.

  3. Hola Ibon y Martin. Muchas gracias por vuestros comentarios.

    Sonar ya lo conocía, me gusto mucho tu revisión Martin y me parece una gran herramienta, diseñada con mucho estilo. Pero tengo mis dudas respecto al valor añadido que puede aportar si ya tienes un servidor de integración continua que hace revisiones de código. Me explico.

    Hudson puede calcular la mayoría de las métricas de Sonar, sólo hay que usar los plugins respectivos, aunque no hace los mismos informes. La ventaja es que tendriamos toda la información en la misma aplicación y no habria que usar una segunda aplicación.

    Sonar añadiría unos informes muy gráficos sobre los globales del código del proyecto. Pero realmente a un programador ¿le interesa saber, pej, el global de la complejidad de todo el código del proyecto o que de todo el código que acaba de subir hay 1 método que supera la cota máxima de complejidad fijada? Y lo mismo para el resto de métricas.

    Yo como jefe de equipo sí que me veo mirándolo un par de veces al mes, sobretodo porque me encantan las gráficas de tendencias. Pero al programador medio no lo veo. Entonces ¿qué extra aporta Sonar al equipo de desarrollo si además para consultarlo tengo que irme a otra url? No se, a lo mejor se me escapa algo...

    Sin embargo donde le veo muchísima utilidad es en organizaciones cliente para controlar la calidad de los proyectos que les entregan o como cuadro de mandos del departamento de desarrollo.

  4. Claro, es que lo tienes que mirar como una herramienta para ti. A un programador no le interesa, pero a ti te interesa saber si un programador ha creado una clase de 5000 lineas y que nadie se haya enterado.

  5. Pero eso ya lo hace Hudson con el plugin Checkstyle. Eso y otras muchas más cosas, pej. si hablamos de tamaños puedes definir unos maximos para el numero de parametros, longitud de metodos, clases, clases internas, número de métodos, atributos, longitud de linea y algún otro que se me olvidará. Este tipo de alarmas sí que son útiles para el programador y cuanta más iniciativa demuestre en consultar Hudson sin que tenga que hacer yo de intermediario mejor.

    Lo que Hudson no hace (o yo no se cómo) es decirte pej. que el tamaño medio de todas las clases es 1247. Esta última información es la que creo que a un programador no le dice mucho pero en plan cuadro de mandos para un mando intermedio sí que puede interesarle.

  6. La razón de que me interese Sonar para mi nuevo proyecto es que estoy inmerso un un I+D, y Sonar puede ser la herramienta perfecta cuando desde gerencia nos hagan la pregunta "¿Que tal va eso?".

    Aunque no entiendan ni la mitad de las métricas que se proponen en sonar, sus informes son gráficamente atractivos, no tengo que explicar a nadie lo que es un servidor de integración continua, y da cierta tranquilidad al neofito sobre si lo que se está haciendo tiene la calidad suficiente (sin que tenga que meterse demasiado en el proyecto).

    No es nada que no se pueda arreglar creando un informe, pero psicológicamente yo creo que puede dejar al de arriba más tranquilo sobre lo que se está haciendo (y sobre las preocupaciones que se están tomando para hacerlo correctamente)

    Salu2

Publicar un comentario