Sep 23

Sonar: viene … y se va.

 

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.

Sep 11

Nodos esclavos en Hudson

 

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.

Sep 09

Kanban explicado en comic

 A través de javahispano, (original de One day in Kanban land ), encuentro un post de astracanada en el que cuentan un dia de Kanban en una tira de comic. Leyendo el comic que copio a continuación, se entiende bastante bien la filosofía de Kanban. De todas formas, después de la imagen pongo las mil palabras que valen menos.

comic-camban-1

kanban comic

En Kanban la idea es centrarse en tareas concretas, bajo demanda y no abordar demasiadas cosas a la vez. En la primera columna del tablero están todas las tareas a hacer. El responsable del proyecto pasa las que considera más importantes a la columna "selected" con una restricción: nunca puede tener en esa columna más de dos tareas (el 2 que aparece debajo de selected).

Los desarrolladores, en su columna "Develop", pueden tener un máximo de dos tareas. La columna se subdivide en dos: las que están haciendo en ese momento "Ongoing" y las que ya han acabado "Done". No puede nter más de 2 tareas en la columna "Develop".

Los de pruebas "Deploy", sólo pueden tener una tarea. Una vez probada, se pasa a la columna "Live", que es definitivamente acabada.

Cuando cualquiera se queda sin trabajo porque los límites de las columnas le impiden coger alguna o añadir más, deben intentar ayudar a los del tapón. Es el ejemplo, hacia la mitad del comic, en que un grupo de desarrolladores no pueden coger una nueva tarea puesto que hay un taón en la parte de pruebas. Su misión es ir a ayudar en las pruebas. Incluso el jefe, cuando ve el atasco, intenta ayudar como puede (llevando más café).

La verdad es que es una metodología bastante interesante para fases finales de proyecto, donde básicamente lo que hay son bugs, modficaciones y pequeños añadidos.

Sep 08

Jueguecitos con 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.

Sep 06

Travian y las micro-esperas

 

Hace unos días descubrí Travian, un jueguecito de estrategia on-line. En el juego hay romanos, galos y germanos. Cuando te das de alta, te permiten elegir que pueblo quieres y te dan una aldea de ese pueblo. Tu misión, como en todos los juegos de estrategia, es gestionar los escasos recursos para producir más recursos, edificios y tropas. Por supuesto, puedes dedicarte al comercio y a atacar/defenderte de todo bicho viviente que esté en las cercanias. El objetivo final no lo tengo muy claro, pero creo que es hacer una alianza con otros jugadores y entre todos construir una maravilla.

Aunque el juego es entretenido, tiene una pequeña pega que te hace pasarte la tarde entera sin hacer nada: las micro-esperas. Cuando constuyes algo, debes esperar diez minutos a que esté hecho. Te dan recursos poco a poco, de forma que puedes tardar una o dos horas en conseguir los recursos para construir algo. Cuando mandas tropas a algún sitio, tardan un mínimo de diez minutos en ir y otro tanto en volver. Una partida completa creo que dura del orden de 13 meses.

En fin, que haces una cosa y esperas un cuarto de hora, haces otra y esperas otro cuarto de hora y así sucesivamente. Y claro, entre cuarto de hora y cuarto de hora, no te vas a poner a hacer algo de otro tema (un tutorial, descargar un programa para probar, probar algo). Bueno, sí, entre cuarto de hora y cuarto de hora, escribo este post….

A ver lo que me dura la afición por el jueguecito este. Por cierto, si alguien juega estoy en el server 2 como chuidiang. Y si alguien quiere apuntarse, me hace un favor haciéndolo a través de este enlace http://www.travian.net/?uc=net2_18520&signup