Exprimiendo a Hudson - Parte 3 (Creando un Job)

Por fin vamos a crear nuestro primer job. En ésta ocasión vamos a suponer que contamos en nuestra Software Factory con un proyecto Java que se construye (compila, distribuye, genera javadoc, etc) desde un script ant. Si usamos un IDE como NetBeans este script es generado automáticamente segun las propiedades del proyecto, no es la finalidad de este tutorial explicar como modificar estos script desde Netbeans, solo comentar que podemos modificar/agregar task ant facilmente sin tocar lo generado por el ide en el archivo build.xml del directorio raiz del proyecto. Aquí un pequeño tutorial que explica como hacer esto.

Retornando a Hudson, podemos definir un Job como una tarea con acciones y triggers a realizar sobre un proyecto de software. Normalmente tendremos definido un job por cada proyecto que tengamos que integrar, pero no hay un límite sobre la cantidad de jobs que podamos definir sobre un proyecto particular, todo depende de las acciones que quisieramos ejecutar en el job.

Para crear un job nuevo hacemos click sobre New Job. Como dijimos que la construcción del proyecto esta basada en un script ant, entonces de las distintas posibilidad que disponemos, seleccionamos la opción Build a free-style software project y dejamos la opción de maven2 para otra ocación. Ya que estamos aquí, Copy existing job será muy útil para copiar una configuración de un job ya existente al job nuevo ( que deducción! XD ) y ahorrarnos trabajo repetitivo. Le asignamos un nombre al job y le damos al ok.

La configuración del job se divide en 5 secciones donde Hudson nos pide lo siguiente:

1. Dame información básica.
2. ¿De donde obtengo el proyecto?
3. ¿En que momento construyo el proyecto?
4. Dame una herramienta para la construya.
5. ¿Que quieres que haga después de construir el proyecto?

Vamos a repasar cada una de las secciones:

Si nos concentramos en la sección superior, observamos que podemos llenar un campo de comentario con una descripción de la finalidad del job. Tambien existe un checkbox para indicar si queremos que los builds antiguos se vayan descartando, podemos definir esto por cantidad de días y/o por cantidad de builds. Esta última opción es la que siempre uso, manteniendo los últimos 10 builds. También disponemos de otro checkbox que deshabilita la ejecucion del job.

En la próxima sección Source Code Management, básicamente debemos elegir el sistema gestor de código fuente que posee nuestro repositorio de proyectos y definir la conexión al servidor. En principio solamente veremos las opciones CVS y Subversion ya que Hudson por defecto trae instalado y listo para usar plugins para conexión a estos dos servidores. Aunque además disponemos de plugins para Mercurial entre otros.

En la sección Build Triggers debemos definir el momento en que Hudson realizará el build. Por defecto existen tres formas distintas de realizar hasta acción (cuatro si incluimos el build now manual).
Una de las posibilidades es definir que se haga luego de finalizar otros build de proyectos, indicando el nombre de estos. Esto es muy útil si estamos definiendo un job para correr una completa bateria de tests pero siempre despues de que otro job complete la construcción de todo el proyecto. La segunda forma es encuestar el repositorio definido en la sección anterior cada cierto intervalo de tiempo, si se detectan cambios, se realizará el build. Por último se puede indicar que el build se haga periodicamente.
Para las últimas dos opciones la forma de indicar el tiempo es mediante cinco valores separados por espacios, siendo estos valores en orden: minuto, hora, dia del mes, mes, dia de la semana. Podemos usar el caracter comodín * para indicar "todos". Por ejemplo si queremos realizar builds nocturnos pasada media hora de la media noche todos los dias del mes, los valores a llenar en el campo Schedule podrían ser 29 23 * * * (los valores para minutos y dias, etc comienzan de 0).

Continuando con la próxima sección build, es aquí donde definimos la herramienta de construcción, en nuestro caso Ant. Especificando el target que queremos que corra o dejando el campo vacío para que corra el target por defecto. Además tenemos la potencia de ejecutar ordenes de un shell script o de batch script de Windows. Por ejemplo, podríamos invocar por shell script a la orden make makefile para construir un proyecto c/c+.

En la última sección podemos pedirle a Hudson que realize varias acciones luego de que finalize el build. Como muestra la imagen es posible retener artefactos indicando cuales son. Como por ejemplo archivos .exe .war . jar .zip o lo que fuese resultado del build. Además podemos hacer que se publique el javadoc (obviamente si es un proyecto Java) indicandole también donde se encuentra. Si lo deseamos, Hudson nos generará un reporte con el resultado de los test JUnit. Todas estas últimas acciones estan basadas en resultados ya generados en la etapa de build, en nuestro ejemplo con el script ant. Otra acción pos-build sencilla de activar es la de notificación por e-mail. Para esta sección disponemos de varios plugins extras sobre todo para reportes.

Con lo visto hasta aquí ya podemos hacer uso de Hudson de forma básica. En el próximo post comenzaremos a exprimir a Hudson. Ya saben... espero sus comentarios.