Integración continua en entornos Java (1ª parte)

Requisitos iniciales

Hace unos días, mi colega Fran Reyes y yo, hicimos una charla/taller sobre integración continua en la 3ª reunión del grupo Agile-Canarias y como allí prometimos que íbamos a mostrar en el blog los pasos a seguir para montar tu propio servidor de integración continua, y como lo prometido es deuda, aquí va la primera entrega, los requisitos iniciales para comenzar :-)

Damos por hecho que todo el mundo tiene instalado en su máquina el entorno de desarrollo de Java (JDK 1.5 o superior) y un servidor Apache Tomcat, por lo que daremos esos pasos por supuestos. Por lo tanto continuaremos con las herramientas necesarias para poder avanzar en los siguientes capítulos.

Cliente SVN

Aunque no utilizaremos SVN como repositorio de código, es necesario tener instalado un cliente SVN para poder descargar el proyecto de prueba con el que trabajaremos. En casi todos los sistemas existe un cliente SVN de fácil instalación, por lo que continuaré explicando como descargar el código que vamos a utilizar en los ejemplos.

Crearemos una carpeta que utilizaremos como espacio de trabajo para montar el servidor de integración y en dicha carpeta haremos lo siguiente para obtener los fuentes de la aplicación Petclinic de Spring Source.



svn export https://src.springframework.org/svn/spring-samples/petclinic/trunk petclinic


Ahora deberíamos tener una carpeta en el directorio que hemos creado anteriormente cuyo nombre es petclinic y que contiene el proyecto que he comentado.

Apache Maven 2

Para todos aquellos que no conozcáis Maven basta resumir sus ventajas en unos pocos puntos.

  • Ayuda a gestionar el ciclo de vida de la aplicación, de forma que nunca se nos olvidará algún paso en la construcción de la aplicación a partir de los fuentes, como por ejemplo ejecutar los tests.
  •  Gestiona las dependencias por sí solo, de forma que no es necesario que nos estemos ocupando de mantener una carpeta llena de .jars, el solo se los descargará cuando los necesite, en base a un fichero de configuración especificado por los desarrolladores.
  • Permite automatizar muchos pasos que hasta ahora generalmente se hacían de forma manual, como por ejemplo el despliegue de la aplicación en el servidor.
  • Permite tener distintos perfiles en función de si estamos en desarrollo o queremos generar una release para el cliente, entre otros.

Pero lo mejor será que busquéis información en la página oficial o en Google si estáis interesados.

El siguiente paso será proceder a la instalación de la última versión (estable claro) de Maven en nuestro sistema. En general basta con descargar el fichero de la página oficial y descomprimirlo en algún lugar de nuestra máquina (así de sencilla es la instalación de Maven). Si queremos disponer de Maven en la consola, que es lo normal, basta con incluir en el path del sistema la ruta hasta la carpeta bin de la instalación de Maven y listo.

Antes de continuar y para asegurarnos que Maven está instalado, se puede teclear en consola el siguiente comando.



mvn --version


Lo normal es que se obtenga una salida en consola similar a la siguiente. En caso contrario volved a leer el manual de instalación de Maven antes de seguir con el resto.



Apache Maven 2.2.0 (r788681; 2009-06-26 14:04:01+0100)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: es_ES, platform encoding: UTF-8
OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac"


Ahora que tenemos Maven instalado, podemos comprobar que la aplicación que nos hemos descargado de Spring Source funciona correctamente, para ello basta con teclear en la consola (posicionados en la raíz del proyecto) mvn clean package. Si todo va correctamente la consola se irá llenando con un montón de texto que ahora mismo no nos interesa (puede tardar un rato porque tiene que descargar las dependencias, a menos que ya las haya descargado anteriormente), hasta concluir con el mensaje BUILD SUCCESFUL :-) Como doy por sentado que ha ido todo bien, en la carpeta petclinic/target debe existir el fichero petclinic.war que es la aplicación compilada y lista para el despliegue. Por lo tanto ya hemos finalizado este punto y podemos continuar al montaje del repositorio de código. Antes de continuar es conveniente ejecutar mvn clean para no llevar basura hasta el repositorio de código.

Mercurial

Ya estamos en el penúltimo punto de los requisitos previos, el repositorio de código, que en este caso será Mercurial. En principio Mercurial nos permitirá tener un repositorio de código configurando unos pocos pasos, pero para todos aquellos que quieran aprender un poco más y conocer sus ventajas (que las tiene), les recomiendo los siguientes enlaces.

Mercurial: The Definitive Guide by Bryan O'Sullivan

Hg Init: a Mercurial tutorial by Joel Spolsky

La instalación de Mercurial es dependiente de cada sistema, pero en general es muy sencilla y la página oficial tiene toda la información. Una vez instalado podemos hacer una prueba como en el caso de Maven.



hg --version


Con lo que deberíamos obtener la información de Mercurial que debe ser algo parecido a lo siguiente.



Mercurial Distributed SCM (version 1.5.2+20100502)

Copyright (C) 2005-2010 Matt Mackall  and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


No es muy complicado ¿verdad?, pues ahora vamos a convertir la carpeta petclinic que hemos creado al inicio, en un repositorio de código Mercurial, para ello basta seguir los siguiente pasos. Aunque antes es necesario configurar en nuestra carpeta home el fichero .hgrc con el siguiente contenido (para los usuarios de Windows CREO que el fichero es mercurial.ini, lo podéis comprobar en el manual).



[ui]
username = yeray



Ahora Mercurial sabe quien es el usuario que está haciendo estas operaciones sin necesidad de especificarlo, por lo que ahora si que podemos iniciar el repositorio de código :-)



hg init

hg add

hg commit


Cuando hayamos completado la operación de commit (que requiere necesariamente un comentario) nuestro repositorio de código estará listo y podemos publicarlo mediante hg serve -n petclinic. Para comprobar que está publicado podemos abrir en nuestro navegador favorito la siguiente URL http://localhost:8000/ y debería aparecer la información del repositorio.

Por si hay algo que no se haya entendido hasta este punto, en el siguiente enlace podéis ver un video de los pasos que he explicado hasta el momento.

Vaya, ya está casi todo listo, ahora tan solo tenemos que instalar Hudson en nuestro servidor Tomcat y ya habremos terminado el capítulo de los requisitos previos.

Hudson

Es posible que esta sea la parte más sencilla de todas, porque Hudson viene directamente empaquetado en un fichero .war que podemos desplegar en nuestro servidor Tomcat sin necesidad de hacer nada más :-)

Cuando tengamos el Tomcat iniciado con Hudson corriendo podemos acceder a http://localhost:8080/hudson y configurar los siguientes puntos de Hudson.
  • Ruta del JDK en el sistema.
  • Ruta de Maven en el sistema.
Para acceder a ellos, basta con hacer click en la opción Adminstrar Hudson en el panel de opciones de la izquierda y luego en Configurar el sistema, con lo que deberíamos tener una pantalla similar a la siguiente, en donde configuraremos  la información de nuestro sistema, de forma similar a como aparece en la imagen (otra opción aunque no es la que yo he seguido, es dejar que sea Hudson quien instale estas dependencias por sí solo como se puede ver en el menú cuando seleccionamos añadir).



Con configurar las opciones de Maven y el JDK nos vale, aunque para finalizar y dejar nuestro sistema listo, tendremos que acceder a la opción de Administrar Plugins en la pantalla de administración de Hudson e instalar el plugin de Mercurial. Es muy sencillo tan solo tenemos que seleccionar el plugin que deseamos y hacer click en instalar. Este plugin no requiere configuración especial por lo que hemos terminado por ahora :-P

En el siguiente post (que espero publicar en breve) hablaré de como configurar el proyecto en Hudson para construirlo de forma automática, y de los pasos para tenerlo enlazado con Mercurial y que se construya el proyecto en cada nueva revisión del código.

Comentarios

Gregorio Mena ha dicho que…
Muchas gracias Yeray. El taller estuve muy bien, y tener esto de respaldo está genial. También ha quedado bien el cambio de look ;)
Yeray Darias ha dicho que…
Gracias Gregorio. El cambio de look gracias a Blogger que ha metido estos nuevos estilos :-P Seguiré trabajando en este material para mejorarlo lo máximo posible.

Entradas populares de este blog

Log4j - JMS Appender con ActiveMQ

¿Cómo hacer uso de SASS en proyectos Java?

#informáticaSoluciónYA