Tras estos dos años, estos son los datos:

La instalación es la por defecto sobre Linux, junto a un Slave que utilizamos puntualmente para las test sobre Windows.

Respecto a los plugins, aunque le hemos dado una oportunidad a practicamente todos, estos son los más utilizados:

• SVNCopyPlugin (Plugin desarrollado internamente por Viavansi para la sincronización con el SVN del cliente tras despliegues exitosos)
• Hudson SCP Publisher Plugin (desarrollado internamente para publicar en nuestro sistema de descargas )
• ChuckNorris Plugin
• SubversionTaggin Plugin
• Disk Usage Plugin
• Seleniumhq Plugin
• Sonar Plugin
• Dependency Analyzer
• Backup Plugin
• Deploy Plugin
• SCP Plugin
• Jabber Plugin

Algunos artículos relacionados:

Introducción a Hudson: http://www.xnoccio.com/362-hudson-parte-1-introduccion/
Introducción al desarrollo de Plugins: http://www.xnoccio.com/464-hudson-parte-2-crea-tus-propios-plugins/
Comparatíva: http://www.xnoccio.com/368-eligiendo-nuestro-entorno-de-integracion-continua-i/
y conclusiones http://www.xnoccio.com/372-conclusiones-finales-eligiendo-nuestro-entorno-de-integracion-continua-v/

Aún disponiendo de una cantidad considerable de plugins en la red que cubran la mayoría de las necesidades, nos podemos encontrar en la situación de tener que crear uno propio. Si te has planteado desarrollar uno te habrás dado cuenta de que la documentación en Internet sobre cómo crear un plugin es muy escasa, estando el grueso de la información en sólo dos páginas: http://hudson.gotdns.com/wiki/display/HUDSON/Plugin+tutorial y http://javaadventure.blogspot.com/2008/01/writing-hudson-plug-in-part-1.html.

Pues bien, en Viavansi surgió la necesidad de crear un plugin para Hudson que subiera el código fuente de un proyecto a un repositorio de Subversion, de forma que se automatizara esta tarea cada vez que Hudson hiciera un build.

El plugin constará de una parte de configuración en donde el usuario encargado de cada proyecto introducirá la url del repositorio de Subversion donde desea subir el código, los parámetros relativos al repositorio (nombre de usuario y password) así como dos entradas para ficheros que no se quieren subir o ficheros que no se quieren sobreescribir en el destino. Además dispondrá de una opción para habilitar o deshabilitar el plugin en todos los proyectos de forma global.

Creación de la estructura del plugin

Lo primero que vamos a tener que usar para crear el plugin es la herramienta Maven, la cual nos creará la estructura de paquetes, además de algunos ficheros de ejemplos. Esto era de esperar, pues Hudson internamente usa Maven para la creación de los builds de los proyectos.

Empezamos situandonos en una consola sobre nuestro directorio de proyectos y tecleamos:

mvn hpi:create

Después de pedirnos algunos datos como el identificador del grupo y el nombre del plugin, Maven nos creará la siguiente estructura:

+ src

+ main

+ java

+ groupid.name

+- PluginNamePublisher.java

+- PluginImpl.java

+ resources

+ groupid.name.project

+- config.jelly

+- global.jelly

+- index.jelly

+ webapp

+- help-globalConfig.html

+- help-projectConfig.html

Por defecto, se crean unos ficheros de ejemplo (el archiconocido HelloWorld) que podemos usar para ver cómo está implementado un plugin sencillo.

Si queremos tener soporte en nuestro IDE para la implementación del plugin deberemos, en el caso de Eclipse, tendremos que introducir lo siguiente:

mvn -DdownloadSources=true eclipse:eclipse

Si tenemos otros entornos como Netbeans o IntelliJ, existen plugins específicos de Maven para estos IDEs.

Bien, acabamos de crear la estructura de nuestro primer plugin, nos falta decirle a Hudson qué tipo de plugin hemos desarrollado, agregar la lógica y crear los campos visuales para que se añadan a las páginas de configuración de los proyectos.

Creando el plugin

Uno de los aspectos más importantes en la creación de un plugin para Hudson consiste en determinar el tipo de proyecto para el que va a ser utilizado. En nuestro caso utilizamos proyectos de tipo Maven, por lo cual necesitamos publicar el plugin en Hudson a través de un Publisher; en caso contrario (para proyectos de tipo Ant, por ejemplo) necesitaríamos publicarlo usando un Builder. Otra de las características de usar un Publisher frente a un Builder consiste en que la acción se ejecuta cuando un proyecto ha terminado de hacer el build.

Para publicar el plugin mediante un Publisher basta con tocar la clase PlugImp quedando de la siguiente forma:

public class PluginImpl extends Plugin {

public void start() throws Exception {

//Publicamos el descriptor del plugin

Publisher.PUBLISHERS.add(SVNCopyPublisher.DESCRIPTOR);

}

}

En este código podemos ver como se ha modificado la clase inicialmente creada por Maven, añadiendo la línea donde le decimos a Hudson que registre nuestro plugin. Debido a que la funcionalidad que queremos desarrollar consiste en copiar el código fuente de un proyecto a un repositorio de Subversion, el nombre de nuestro plugin será SVNCopyPlugin (original, verdad?), creando así la clase SVNCopyPublisher que será la que contenga el descriptor y la lógica de negocio.

Los elementos más importantes de la clase SVNCopyPublisher son:

• Atributos necesarios para la ejecución de la lógica del plugin. En nuestro caso, url del repositorio, nombre de usuario, contraseña y listas con los ficheros que no queremos subir o que no queremos sobreescribir. Cada atributo deberá tener un método público get y set.

• Un constructor público en el que pasaremos los valores de los campos rellenados por el usuario en la configuración del plugin e inicializaremos los atributos definidos en el punto anterior. Además, este constructor deberá estar anotado con @DataBoundConstructor.

• Un método perform en donde se colocará la lógica de nuestro plugin.

• Un atributo estático y final llamado DESCRIPTOR que será instancia de una clase interna de nombre DescriptorImpl.

A su vez, la clase DescriptorImpl contendrá la configuración global del plugin. En el caso de SVNCopyPlugin hemos usado en la configuración local un checkbox con el cual activaremos el uso del plugin y sólo realizará la copia cuando esté activado.

Además esta clase debe contener:

• Los atributos propios de la configuración global del plugin, con sus gets y sets.

• Un constructor protected sin parámetros.

• El método configure que hará persistente la configuración global.

• Un método newInstance que devolverá una instancia de nuestra clase Publisher con los valores introducidos por el usuario.

Hasta aquí ha sido todo teoría, veamos ahora como queda la clase SVNCopyPublisher y su clase interna DescriptorImpl:

public class SVNCopyPublisher extends Publisher {

private Boolean enable;

private final String urlTarget, nameTarget, passTarget, filesTargetException, filesSourceException;

@DataBoundConstructor

public SVNCopyPublisher(String urlTarget, String nameTarget, String passTarget, String filesSourceException, String filesTargetException) {

this.urlTarget = urlTarget;

this.nameTarget = nameTarget;

this.passTarget = passTarget;

this.filesTargetException = filesTargetException;

this.filesSourceException = filesSourceException;

}

…

//GETTERS y SETTERS de los atributos

…

public boolean needsToRunAfterFinalized() {

return true;

}

/*

* Contiene la lógica del plugin, que se ejecutará cuando termine el build de Hudson

*/

@Override

public boolean perform(AbstractBuild<?, ?> build, Launcher launcher, BuildListener listener) throws InterruptedException, IOException {

if(enable && build.getResult().equals(Result.SUCCESS)){

//Aquí debe ir la lógica de negocio del plugin

…

}

return true;

}

public Descriptor<Publisher> getDescriptor() {

return DESCRIPTOR;

}

public Action getProjectAction(AbstractProject< ?, ?> project) {

return null;

}

/**

* Descriptor should be singleton.

*/

public static final DescriptorImpl DESCRIPTOR = new DescriptorImpl();

/**

* Descriptor for {@link SVNCopyPublisher}. Used as a singleton.

* The class is marked as public so that it can be accessed from views.

*/

public static final class DescriptorImpl extends Descriptor<Publisher> {

 

/**

* If you don’t want fields to be persisted, use transient

*/

private boolean enable;

protected DescriptorImpl() {

super(SVNCopyPublisher.class);

load();

}

/**

* This human readable name is used in the configuration screen.

*/

public String getDisplayName() {

return “SVNCopy Plugin Project Configuration”;

}

/**

* Get the fields from the global configuration form and persist them.

*/

public boolean configure(StaplerRequest req, JSONObject o ) throws FormException {

enable = o.getBoolean(“enable”);

save();

return super.configure(req,o);

}

/**

* Creates a new instance of {@link SVNCopyPublisher} from a submitted form.

*/

@Override

public SVNCopyPublisher newInstance(StaplerRequest req, JSONObject formData) throws FormException {

SVNCopyPublisher pub = req.bindJSON(SVNCopyPublisher.class, formData);

pub.setEnable(enable);

return pub;

}

public boolean isEnable(){

return enable;

}

}

}

Del código de arriba podemos destacar el método perform, que es el encargado de llamar a la lógica del plugin, recibiendo como parámetros una instancia de AbstractBuild (usado para lanzar el plugin si el build ha terminado satisfactoriamente), una de Launcher que contiene datos de la máquina que realiza el build y otra de Listener, que entre otras cosas contiene el logger con el cual podemos imprimir en la consola web de Hudson nuestra salida del plugin. Otros métodos importantes son configure y newInstance que reciben como parámetros la petición del formulario de configuración y los datos introducidos por el usuario en forma de JSON. El parámetro StaplerRequest forma parte del framework Stapler utilizado por Hudson para la aplicación web y es útil si queremos obtener datos de la petición usando getParameter.

Generando los formularios y uniéndolos al código del plugin

Para terminar con el desarrollo de nuestro plugin nos falta crear los formularios de entrada en la parte de configuración global de Hudson, así como en la configuración particular de cada proyecto. Maven nos crea por defecto los ficheros global.jelly y config.jelly, además de unos htmls de ayuda. Estos ficheros siguen un esquema XML basandose en un framework ligero llamado Jelly http://commons.apache.org/jelly/.

Para comenzar, tenemos que incluir en la configuración global de Hudson el checkbox que habilitará de forma general el uso del plugin para todos los builds que se hagan (además se dispone de otro checkbox que habilita el plugin para cada proyecto). Dentro de la carpeta resources se encontrarán como mínimo tres ficheros .jelly: index, global y config. El primer fichero contiene una descripción del plugin y en los otros dos se deberá colocar los elementos htmls para la configuración global y específica del mismo.

En el fichero global.jelly queremos colocar el checkbox que hará que se active el plugin para todos los proyectos. Para ellos basta con colocar las siguientes lineas:

<j:jelly xmlns:j=”jelly:core” xmlns:st=”jelly:stapler” xmlns:d=”jelly:define” xmlns:l=”/lib/layout” xmlns:t=”/lib/hudson” xmlns:f=”/lib/form”>

<f:section title=”SVNCopyPlugin Global Configuration”>

 

<f:entry title=”Enable”

description=”Check if you want to perform a copy of your project from your repository to another one”>

 

<f:checkbox name=”enable” checked=”${descriptor.isEnable()}” />

 

</f:entry>

</f:section>

</j:jelly>

Como se puede apreciar el código es bastante autoexplicativo. Se usan unos tags propios de Jelly para añadir el checkbox a la configuración de Hudson (Manage Hudson / Configure System). El valor del checkbox estará bindeado al atributo enable ya visto en el descriptor.

Por otra parte el fichero config.jelly contendrá la configuración específica del plugin para cada proyecto. Su contenido será el siguiente:

<j:jelly xmlns:j=”jelly:core” xmlns:st=”jelly:stapler” xmlns:d=”jelly:define” xmlns:l=”/lib/layout” xmlns:t=”/lib/hudson” xmlns:f=”/lib/form”>

<!–

Cajas de texto para introducir las url de los dos repositorios, los nombres y los passwords

–>

<f:entry title=”URL del repositorio destino”>

<f:textbox field=”urlTarget” value=”${descriptor.urlTarget}”/>

</f:entry>

<f:entry title=”Nombre de usuario del repositorio destino”>

<f:textbox field=”nameTarget” value=”${descriptor.nameTarget}”/>

</f:entry>

<f:entry title=”Password del repositorio destino”>

<f:password field=”passTarget” value=”${descriptor.passTarget}”/>

</f:entry>

<f:entry title=”Ficheros y carpetas que no se desean sobreescribir en el destino”>

<f:textbox field=”filesTargetException” value=”${descriptor.filesTargetException}”/>

</f:entry>

<f:entry title=”Ficheros y carpetas que no se desean subir al destino”>

<f:textbox field=”filesSourceException” value=”${descriptor.filesSourceException}”/>

</f:entry>

</j:jelly>

Gracias a este fichero se incluirá en la configuración del proyecto las cajas de texto para que cada usuario introduzca sus datos sobre el repositorio. Cada elemento f:textbox leerá/escribirá su valor en un atributo del descriptor.

Ejecución y debug

Con todo esto ya hemos terminado de programar el plugin, ahora sólo queda ejecutarlo y ver que todo va como deseamos. Para ello usaremos el comando mvn hpi:run desde la carpeta del plugin, el cual nos montará un Hudson en nuestra máquina y con el que podremos trastear antes de instalarlo en el Hudson de la empresa.

También es interesante la opción de debuguear para seguir la traza y ver qué valores van tomando cada uno de los elementos que intervienen en la ejecución del plugin. Para tener la posibilidad de debuguear antes de llamar a mvn hpi:run tendremos que setear las variables de entorno con los comandos:

export MAVEN_OPTS=”-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000,suspend=n”

si usamos Unix o

set MAVEN_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000,suspend=n

si usamos Windows.

Empaquetando y exportando el plugin

Para finalizar sólo queda crear el fichero .hpi para importarlo desde el Hudson instalado en uno de los servidores de la empresa, algo tan sencillo como ejecutar mvn hpi:package y coger el fichero con esta extensión creado en la carpeta target.

Con esto ya tienes para empezar a customizar tu Hudson añadiendole la funcionalidad que necesitas y no te la dan otros plugins. Ya se sabe, si no está: hazlo tu mismo.

Próximamente…

En breve pondremos una entrada explicando cómo sacarle más partido a los plugin de Hudson, añadiendo interacción con el usuario, generación de informes del plugin por cada build, etc.

• Tabla resumen

A modo de resumen hemos agrupado en una sola tabla todos las parámetros evaluados en la comparativa, para permitirnos una comparación rápida entre las diferentes herramientas.

• Conclusiones finales.

Sin duda nuestra propuesta se inclina por Hudson. Brevemente vamos a enumerar y resumir (de entre los detalles de esta comparativa) ciertos aspectos que hacen inclinar la balanza hacia este software:

• Extensibilidad. La posibilidad de desarrollar plugins que permitan adaptar e inyectar funcionalidad de forma personalizada es una característica casi imprescindible.  Apache Continuum no dispone de esta posibilidad de integrar plugins (deben ser plugins Maven, utilizados específicamente en cada uno de los proyectos Java), lo cual prácticamente hace descartar esta plataforma. LuntBuild dispone de ciertas opciones de inyección de código, si bien a este respecto las mejores características las tiene Hudson.

• Calidad de la documentación. En esta materia Hudson también dispone de la mejor documentación, por delante de LuntBuild y Continuum.

• Integración de resultados de plugins (centralizados o Maven) en pantalla. Un aspecto de interés es que el resultado de los diversos plugins pueda verse en la interfaz web de la aplicación. Tan sólo Hudson proporciona este nivel de integración por defecto.

• Sistema de seguridad y permisos. En esta funcionalidad tan importante lideran la comparativa Hudson y Continuum. Ambas disponen de la posibilidad de gestión de permisos basados en perfiles, y posibilidad de personalizar los permisos por proyectos. Continuum puede requerir modificaciones en ficheros de configuración y reinicio del sistema, mientras que Hudson permite configuración integral en pantalla.

• Estabilidad. Las tres plataformas disponen de buenas características de estabilidad, si bien destacan Hudson y LuntBuild, que permiten la gestión multihilo y compilación distribuida.

• Soporte de la comunidad. A este respecto lideran la comparativa tanto Hudson como Continuum, desarrollos de Sun y Apache respectivamente.

Como se puede observar, Hudson auna las principales características que nosotros esperabamos de un sistema de Integración Continua, y por ello es nuestra propuesta y elección para servir de plataforma base en la infraestructura de desarrollo.

• Instalación

La instalación de Hudson es extremadamente sencilla, pudiéndose realizar una evaluación del software utilizando un instalador Java Web Start desde la web del producto. Así mismo, se puede descargar e instalar la aplicación de forma standalone, o se puede desplegar sobre un servidor de aplicaciones mediante el fichero empaquetado hudson.war.

El sistema está pensado para que nunca sea necesario editar ningún fichero de configuración externo, ofreciéndonos una administración web sencilla pero que contempla una configuración visual integral (incluyendo por ejemplo la parametrización de SMTP, base de datos, seguridad, etc.).

La documentación de instalación oficial del producto es buena, e incluye incluso algunos vídeos screencasts. Por otro lado, si en algún momento nos sentimos confundidos con la configuración, el sistema ofrece una completa ayuda en linea y contextual que facilita mucho la tarea de configuración para personas no familiarizadas a priori con este tipo de sistemas.

• Administración, gestión de proyectos

La herramienta ofrece una interfaz muy intuitiva para su administración, por lo que como hemos comentado antes, no será necesario personal especializado para su administración, pudiéndose realizar todas las tareas desde la propia consola web.

La herramienta permite la definición de tareas periódicas desde su interfaz web mediante un editor similar a cron dotado de una completa ayuda contextual.

Por otro lado, durante las pruebas, la migración de los proyectos a Hudson ha resultado ser muy rápida y sencilla, consiguiendo un entorno totalmente configurado y funcional en poco tiempo.

Respecto a su mecanismo de actualización, Hudson es el mejor de los sistemas analizados, ya que sólo es necesario descargar el nuevo empaquetado .war y sustituir el existente, asegurándose la plataforma de mantener la compatibilidad de forma automática. Por otro lado, es el propio Hudson el que nos avisará de la existencia de nuevas versiones, tanto del sistema completo como de sus plugins.

• Seguridad

El sistema ofrece un sistema de seguridad completo y muy flexible, y totalmente configurable desde la consola web, permitiéndonos o bien integrarnos con sistemas externos de autenticación (LDAP, bases de datos externas) o delegar la seguridad en el propio Hudson.

Si optamos por que Hudson gestione la seguridad, dispondremos de múltiples opciones que cubren todo el abanico de necesidades, como seguridad basada en perfiles, asociación de permisos por proyectos o por matriz de acciones.

• Integración con sistemas externos

Hudson ofrece un mecanismo de extensión muy completo, que junto con el gran número de plugins ya existentes le permiten su integración con un gran número de sistemas y herramientas. Por otro lado, aunque está preparado (al igual que Continuum o LuntBuild) para utilizar directamente los plugins Maven, proporciona los mecanismos adecuados para no depender de una correcta configuración de estos plugins en el fichero pom.xml de los proyectos. Esta centralización de la configuración constituye una ventaja muy importante respecto a sus competidores, ya que garantiza que, independientemente de lo contenido en el pom.xml, se puedan ejecutar los procesos de chequeo y validación deseados.

Por otro lado, existe una integración plena entre Hudson y sus plugins. Los resultados de éstos podrán ser visualizados en la herramienta web, incluyendo tanto conclusiones de testeo, estilos, pruebas unitarias, etc… como los resultados de los procesos de despliegue. Nuevamente Hudson es la única plataforma en permitir este tipo de funcionalidad avanzada.

Por otro lado, permite la integración con la mayoría de sistemas de control de versiones (SVN, CVS, etc.), ya sea de base, o mediante la inclusión de los plugins necesarios.

Es de especial interés el mecanismo de instalación y gestión de plugins, ya que la herramienta nos permite la descarga e instalación automática desde su interfaz web, avisándonos incluso de la aparición de nuevas versiones de los mismos de forma automática.

Otro factor muy importante es la completa documentación para poder desarrollar nuestros propios plugins, que nos permitirán adaptar el sistema a las particularidades propias de cada entorno.

También resulta curiosa la integración con sistemas como Twitter, Jabber, etc., que nos permiten hacernos una idea del avanzadísimo nivel de los mecanismos de integración incorporados en la plataforma. Sin duda, esta es la característica en la que más se destaca Hudson frente a Continuum o LuntBuild.

• Tipos de proyectos

Aunque la herramienta esta principalmente enfocada a proyectos Java, gracias sus plugins tiene soporte para gran multitud de formatos como por ejemplo Ivy, Nant, Rake, Ant, Maven, Phing, Shell scripts, y para lenguajes como .Net, Groovy, Rails, PHP.

• Facilidad de uso

La herramienta ofrece una interfaz potente y muy usable, que permite que personal no cualificado o con poca experiencia en este tipo de herramientas se adapte a su uso con facilidad.

La documentación oficial es completa, y junto con la ayuda contextual en todos los elementos de la interfaz hace que la curva de aprendizaje sea muy rápida.

• Estabilidad

Nos encontramos ante un software muy estable, al igual que ocurría con sus dos competidores directos. Prueba de ello es que está siendo utilizado para todos sus proyectos en grupos de desarrollo como JBoss. Como sistema de Integración Continua, tiene una política de publicación de actualizaciones muy dinámica que hace que se liberen versiones cada pocas semanas, lo cual podría ser un inconveniente de no ser por las posibilidades de actualización automática comentadas. A continuación se indican las principales versiones liberadas:

En lo referido al rendimiento, el sistema permite la gestión de hilos de ejecución dedicados a tareas de compilación y la ejecución de compilación distribuidas, lo que le confiere excelentes características de escalabilidad y adaptabilidad al entorno disponible.

Hudson 1.256	Julio 2008
Hudson 2.00	Marzo 2008
Hudson 1.100	Abril 2007

• Conclusiones sobre Hudson

La herramienta, gracias a su sistemas de plugins, ha resultado ser muy versátil y fácilmente adaptable a necesidades particulares. Por otro lado, su sencilla interfaz la hacen ideal para su uso por personal no especializado en este tipo de herramientas.

Aunque la herramienta es la más joven de las estudiadas, está teniendo una rápida aceptación y divulgación en el mercado, y ha demostrado completamente su fiabilidad.

Próximamente: Conclusiones finales. Eligiendo nuestro entorno de Integración Continua (V).

En entornos en los que el desarrollo de software se realiza por un equipo o equipos en los que la evolución y mantenimiento del código se subdivide,  el coste de la integración entre las diferentes piezas de software tiende a aumentar, apareciendo conflictos y haciendo de la generación de distribuibles una ardua tarea.  Con idea de rebajar los costes adicionales provocados por la gestión del proceso de compilación, integración, empaquetado y generación de entregarles, aparecen herramientas de Integración Continua (CI) como Hudson.

¿ Por qué elegir Hudson?

Aunque es un productor reciente ha evolucionado rápidamente y actualmente es uno de los productos de referencia en el sector de las aplicaciones para Integración Continua de software, gracias a la simplicidad de su interfaz y lo sencillo que resulta el desarrollo de nuevos plugins. Prueba de este crecimiento es que actualmente es utilizado por un gran numero de proyectos entre los que se encuentra por ejemplo JBoss.

Para hacernos una idea los principales motivos que en nuestro caso nos hicieron elegir Hudson son:

• Fácil instalación y uso. Como buen producto cuya utilidad es la de simplificarnos la vida, la instalación y ejecución de Hudson es realmente trivial. Es suficiente con descargar el  fichero hudson.war y ejecutarlo con “java -jar hudson.war” o bien desplegarlo en un servidor de aplicaciones.  Y esto no queda aquí, gracias a su sencilla interfaz, podemos tener nuestros primeros proyectos configurados en pocos minutos.
• Un sistema de plugins fácilmente extensible. Lo que permite la instalación y creación de nuevos plugins de forma sencilla. Esto ha permitido que exista una gran cantidad de plugins disponibles y que sea muy sencilla la creación de plugins específicos. Como ejemplo, gracias a esta simplicidad pudimos crear un plugin específico para adaptar el comportamiento de Hudson a nuestras necesidades en solo unos días.
• Un soporte completo de Maven, lo que nos ha permitido una migración rápida de todos nuestros proyectos al nuevo sistema.
• Soporte para compilación distribuida basada en sistemas esclavos y maestros, para mejorar los tiempos de compilación y evitar la sobrecarga.
• Soporte para múltiples equipos y grupos de proyectos, lo que nos permite la colaboración.
• Es un Sistema completamente Software Libre.
• Nos permite establecer un sistema de alertas a los desarrolladores sobre el estado de sus proyectos.
• Permite la detección de actualizaciones realizadas en el SCM ( en nuestro caso Subversion) para generar de forma automática los nuevos empaquetados o a intervalos regulares.
• Y el principal motivo. Tras estar utilizándolo en el departamento de I+D durante unos meses, el software no nos dio ni un solo problema, por lo que actualmente la mayoría de nuestros proyectos están ya bajo el control de Hudson.

Instalación

Como se comenta arriba, la instalación del software es realmente sencilla, y el único requisito es tener instalada una versión de Java reciente y opcionalmente un servidor de aplicaciones como por ejemplo Tomcat, si no se desea ejecutar sobre el servidor que trae embebido.

Para la instalación, en primer lugar necesitara descargar la última versión estable de  http://hudson.dev.java.net.

Si desea ejecutar Hudson en modo autónomo sera suficiente con ejecutar “java -jar hudson.war”y acceder con el navegador al puerto 8080 (http://localhost:8080) para poder utilizar Hudson.  Si lo desea, en la web oficial tambien puede encontrar los scripts para convertir hudson en un servicio.

Por otro lado la instalación más común de Hudson es su despliegue en un servidor de aplicaciones. Por ejemplo, para su despliegue en un Tomcat, bastara con copiar el fichero hudson.war dentro del directorio webapps.

Hudson utiliza un directorio especial para almacenar toda la configuración propia y de los proyectos que gestiona, por lo que no hay peligro de perdida de datos si posteriormente actualizamos a versiones más recientes del software. Por defecto el directorio es “.hudson”, localizado en el home del usuario, pero  es posible modificar este directorio estableciendo la variable de entorno HUDSON_HOME.

Primeros pasos

En Hudson cada proyecto de desarrollo es una tarea, por lo que para hacer que un proyecto este gestionado por hudson es suficiente con darle un nombre a la tarea y asignarle un tipo entre los disponibles (Build a maven2 project, Build a free-style software project, …)

En adelante a modo de ejemplo vamos a considerar un proyecto de tipo Maven 2. Una vez que tenemos el tipo de proyecto seleccionado, pasamos a la pantalla de configuración, en la que entre otras muchas opciones, tendremos que seleccionar el SCM en el que se encuentra proyecto(en nuestro caso Subversión), el pom.xml asociado al proyecto y el conjunto de goals que deseamos ejecutar. No entraremos en detalle a explicar cada uno de las opciones de configuración, ya que otra de las ventajas de Hudson es que ofrece ayuda en linea para todas sus opciones.

Una vez guardada la nueva tarea, ésta podrá ser ejecutada automáticamente si hemos configurado algún Build Triggers o lanzada de forma manual pulsando sobre Build Now, y una vez que la tarea esta en ejecución podremos ver en todo momento su estado y consola.

Administración

Desde el menú “Manage Hudson”, situado en la página principal, es posible acceder a todas las opciones de configuración. En particular desde la opción “Configure System” podremos acceder a todos los parametros generales como configuración del  SMTP, proxy, rutas a Maven, Ant, …
Y de nuevo para cada opción de configuración dispondremos de ayuda contextual que nos hara la vida mucho más facil.

Como ya hemos comentado, uno de los puntos fuertes de Hudson es su sistema y manejador de plugins, al que podremos  acceder desde la opción “Manage Plugins”. Esta opción nos permitirá añadir nuevas características (como herramientas de control de estilo, nuevos SCM soportados, …) directamente desde su interfaz.

La lista de todos los plugins está disponible en la siguiente dirección:  http://hudson.gotdns.com/wiki/display/HUDSON/Plugins

Conclusión

Hudson es un es un fantastico software para realizar las tareas de Integración Continua, y aunque aquí se han presentado solo las características básicas, a pesar de la simplicidad de su interfaz es un software altamente extensible y con un gran potencial.

Por otro lado, y aunque se enfoca principalmente hacia proyectos Java, Hudson permite gestionar proyectos de cualquier tipo, como por ejemplo proyectos C o Ruby on Rails, lo que lo hace muy recomendable enentorno heterogéneos.

En general, los productos de Integración Continua suelen ser complejos de manejar y gestionar, y como hemos visto, este no es el caso de Hudson, lo que resulta esencial si queremos convertir esta herramienta en una plataforma horizontal en nuestra empresa o grupo de desarrollo. Su facilidad de uso la ha demostrado durante el tiempo que llevamos utilizándolo, ya que no solo no ha requerido de personal especializado en este tipo de tareas para su gestión, sino que tampoco ha necesitado de una compleja explicación para que nuestros grupos de desarrollo empezaran a utilizarlo.

En resumen una herramienta para simplificarnos la vida a los desarrolladores que ofrece lo que promete.

Hudson.  Parde 2. Crea tus propios plugins