Cómo instalar Hudson en Apache Tomcat

2
22913

Creación: 25-10-2009

Índice de contenidos

1.Introducción
2. Entorno
3.Instalación
3.1.Descarga
3.2.Directorio de trabajo
3.3.Securizar el Hudson
3.4.Desplegar el war en el Tomcat
4.Configuración
5.Creando nuestro primer trabajo
6.Lanzando manualmente el trabajo
7.Conclusiones
8.Sobre el autor


1. Introducción

Hudson es una herramienta de integración continua que nos permite estar continuamente integrando nuestro código, valga la redundancia 😉

Es decir, Hudson se va a encargar, de forma automática, de compilar, probar, empaquetar, … nuestros proyectos cada cierto tiempo.

Ya hay otro tipo de herramientas de integración continua, y de hecho a Hudson muchas veces se le hace referencia como «el chico nuevo del barrio», pero Hudson esta demostrando y se está posicionando como uno de los mejores, ya que permite hacer gran
cantidad de cosas con muy poco esfuerzo (y además las hace bien). Esto es en parte gracias a que Hudson es bastante completo y usable, y a que trae gran cantidad de plugins que aumentan su funcionalidad con sólo pinchar un botón.

Aunque Hudson puede ejecutarse directamente sin necesidad de usar un servidor de aplicaciones, en este tutorial vamos a ver como podemos ejecutarlo dentro de un Apache Tomcat que ya tengamos instalado.

2. Entorno

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 17′ (2.93 GHz Intel Core 2 Duo, 4GB DDR3 SDRAM, 128GB Solid State Drive).
  • NVIDIA GeForce 9400M + 9600M GT with 512MB
  • Sistema Operativo: Mac OS X Snow Leopard 10.6.1
  • JDK 1.6.0_14
  • Maven 2.2.1
  • Hudson 1.330


3. Instalación

3.1. Descarga

Lo primero que tenemos que hacer es descargarnos el war con el Hudson. Para ello nos dirigiremos a su página web: http://hudson-ci.org/ donde encontraremos un enlace directo (normalmente http://hudson-ci.org/latest/hudson.war, en estos momentos la versión 1.330).

3.2. Directorio de trabajo

Ahora vamos a preparar un directorio de trabajo para el Hudson. Este directorio será el que Hudson va a utilizar para hacer las compilaciones, guardar la configuración, los logs, …

Una vez creado el directorio se lo tenemos que indicar al Hudson mediante la variable HUDSON_HOME. La mejor opción es dárselo al Tomcat como una opción. Por ejemplo:

$ export CATALINA_OPTS="-DHUDSON_HOME=/path/to/hudson_home/ -Xmx512m"

¡¡¡Ojo!!! no nos olvidemos de darle los permisos correctos al directorio que acabamos de crear para que el Tomcat pueda escribir en él.

3.3. Securizar el Hudson

Este paso no es imprescindible, pero si muy recomendable. De lo contrario cualquier usuario podría editar la configuración del Hudson, o cambiar los trabajos programados (y esto no suele ser lo que queremos).

Este paso va a depender de como ya tenemos configurado nuestro Tomcat. Lo normal es que Tomcat guarde los usuarios en un fichero XML conf/tomcat-users.xml, dentro de nuestro Tomcat.

Para crear un usuario administrado añadiremos las siguientes líneas:

<role rolename="admin"/>
<user username="hudson-admin" password="secret" roles="admin"/>

¡¡¡Ojo!!! Este fichero sólo debería tener permiso de lectura para el usuario con el que se ejecuta el Tomcat. Es más que recomendable que ningún otro usuario pueda leer el contenido de este fichero.

3.4. Desplegar el war en el Tomcat

Este paso es tan sencillo como copiar el archivo war que nos hemos descargado en el directorio webapps de nuestro Tomcat.

Ahora basta con que reiniciemos nuestro Tomcat. Y si todo ha ido bien, deberíamos entrar con el navegador en la dirección http://localhost:8080/hudson, y ver la pantalla principal:

Antes hemos creado un usuario para administrar Hudson, sin embargo no ha dejado entrar tranquilamente y podemos crear nuevos trabajos y cambiar lo que queramos. Esto es porque todavía no hemos activado la seguridad. Esto lo veremos en el siguiente punto, donde aprenderemos como hacer la configuración básica de Hudson.

4. Configuración

En la pantalla principal (la que hemos visto antes) pinchamos sobre «Manage Hudson«. Ahora pinchamos sobre la primera opción: «Configure System«.

Nos aparecerán las opciones para la configuración global de Hudson. Vamos bajando hasta localizar el check «Enable security«. Lo activamos y vemos como nos aparecen nuevas
opciones. Marcamos «Delegate to servlet container» de forma que será Tomcat, con el usuario que dimos de alta anteriormente, el que gestione la autenticación. En cuanto a la
autorización, marcamos la opción «Legacy mode«, con esto conseguimos que los usuarios con el rol «admin» puedan hacer todo, y el resto de usuario (anónimos o no) sólo tengan permisos de lectura (vemos como Hudson nos deja más posibilidades, pero por ahora vamos a empezar con este sistema de autenticación y autorización básico).

Ahora, si seguimos bajando un poco en la misma pantalla, vamos a dar de alta nuestro entorno: Maven, Ant, JDK, … (vemos como el propio Hudson nos proporciona facilidades para instalar algunas de estas aplicaciones automáticamente o para definir manualmente donde se encuentran). Al final tendremos que configurar el servidor de correo, muy importante para que lleguen correctamente las notificaciones.

Al final encontraremos un botón «Save» para guardar todos los cambios realizados.

5. Creando nuestro primer trabajo

Ahora ya estamos listos para empezar a crear trabajos. Vamos ha hacer un ejemplo para ver un poco el proceso.

Volvemos a la pantalla principal de Hudson (si lo último que hicimos fue pulsar el botón «Save«, habremos vuelto automáticamente). Ahora pinchamos sobre «New Job» y accederemos al pantalla que nos permite crear nuevos trabajos.

Lo primero que nos pregunta es el nombre del trabajo y el tipo de trabajo. Para el ejemplo vamos a elegir un proyecto de tipo Maven2.

Al dar al botón «OK» accedemos a la pantalla de propiedades del producto. Sólo vamos a comentar las opciones que hemos cambiado, ya que vamos a usar la mayoría de las opciones por defecto.

En primer lugar le decimos el tipo de «Source Code Management«. En nuestro caso es «Subversion«. En cuanto lo marquemos podremos indicar la URL para acceder al proyecto.
Al indicar esta URL, Hudson intentará conectarse al Subversion inmediatamente para comprobar si puede acceder. Si necesitamos usuario y clave para acceder nos aparecerá un mensaje de error y tendremos que introducir las credenciales.

Pinchamos sobre el enlace «enter credential«, e introducimos el usuario y la contraseña en la nueva ventana que se nos abre.

Ahora configuramos cuando queremos que se haga la build del proyecto. En este punto activamos la opción la opción «Poll SCM«. Esto quiere decir que Hudson ira comprobando cada cierto tiempo el Subversion para ver si ha cambiado el código, y en tal caso, lanzar la build. Con «@hourly» conseguimos que esto se haga cada hora. En vez de esta opción existe una integración mejor que consiste en añadir un hook al Subversion para que sea este el que notifique el cambio al Hudson, de esta forma no hace falta estar comprobando continuamente si ha habido cambios. No se muestra esta opción por simplificar el tutorial (sería especialmente útil en caso de usar CVS en vez de Subversion, ya que es bastante más costoso para el CVS saber si ha habido cambios en el repositorio).

Por último podemos activar las notificaciones por correo electrónico que nos parezcan oportunas.

Una vez hechos todos los cambios pulsamos el botón «Save» que encontramos al final de la página.

Ahora estaremos en la página del proyecto que acabamos de crear.

Si volvemos a la página inicial («Back to Dashboard«), veremos la lista de proyecto planificados y su estado. En este caso el estado nos sale como una bola de color gris, ya que todavía no se ha lanzado ninguna build.

6. Lanzando manualmente el trabajo

Vamos a lanzar manualmente el trabajo para forzar a Hudson a que haga la compilación. Para ello basta simplemente con dar sobre el último icono que tenemos en la fila del proyecto, ese que parece un reloj con una punta de flecha verde. En ese momento veremos como el icono del estado comienza a parpadear indicando que la build está en
progreso.

Si la build falla nos aparecerán unos significativos iconos a modo de mapa del tiempo, y la bola se pondrá de color rojo.

Para ver porque ha fallado la build entramos en la página del proyecto (enlace «autentia wuija«).

En la parte inferior vemos enlaces a la última build, si pinchamos sobre alguno de ellos accedemos a una página con la info de la build. Aquí podremos encontrar un enlace a la consola «Console Output» donde podremos ver los errores (jeje, en mi caso porque me falta configurar el Maven para acceder a nuestro repositorio, y no consigue bajarse algunas dependencias 😛 )

Una vez solucionado el tema de las dependencias del Maven volvemos a lanzar la build y obtenemos mejores resultados. Se puede ver como ahora la bola es amarilla, esto es porque tenemos algún test que falla; y vemos como el clima va mejorando 😉

7. Conclusiones

Vemos como conseguimos un estupendo panel de control sobre todos nuestros proyectos. Con un sólo vistazo vamos a ser capaces de identificar lo que va bien y lo que no va tan bien. Y sabemos que esto se está haciendo cada poco tiempo y que además se nos mandan
correos automáticamente si hay desastres.

De esta manera los sistemas de integración continua deberían ser algo obligatorio si queremos tener procesos de desarrollo de calidad. En este caso hemos visto paso a paso como instalar y hacer las primeras cositas con Hudson. Ahora yo no tenéis excusa para no
montarlo 😉

Desde Autentia (www.autentia.com) os recomendamos fervientemente el uso intensivo de este tipo de herramientas.

8. Sobre el autor

Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software) y Certified ScrumMaster

Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)

mailto:alejandropg@autentia.com

Autentia Real Business Solutions S.L. – «Soporte a Desarrollo»

http://www.autentia.com

 

2 Comentarios

  1. buenas tardes. tengo un problema a laprimera ingrese a hudson con todos los privilegios despues siempre me muestra acceso denegado como si me quitaran los prvilegios.A pesar que otros usuarios del equipo pueden ver que tengo asignado todos los privilegios.

Dejar respuesta

Please enter your comment!
Please enter your name here