Continuum Screencast

He preparado un pequeño video que ilustra la configuración de un proyecto en integración continua con Apache Continuum (además de unos sencillos pasos de instalación). La calidad del video no es la que hubiera deseado, pero si tienes una cuenta en Vimeo puedes descargar el archivo original (.mov) y visualizarlo con QuickTime.

Seguiré preparando pequeños video-tutoriales que muestren cómo obtener el máximo de las funcionalidades que Continuum (a través de Maven, en algunos casos) proporciona.

Por último dar las gracias a Manuel Recena, por la idea y toda su colaboración.

Segundo día en expo:QA

El segundo (y último) día de conferencias en expo:QA, al igual que el primero, no me ha defraudado. Me vuelvo a Sevilla muy satisfecho. De las conferencias de hoy destaco dos:

Integración Continua (Eric Pugh, Open Source Connections)

Eric Pugh nos ha contado cómo implantar un sistema de integración continua teniendo en cuenta los contratiempos que encontraremos (tanto técnicos como «sociales»), entendiendo como contratienpos sociales por ejemplo el hecho de que los programadores vean el sistema de IC como una herramienta que sólo resalta los errores que se cometen, cuando en realidad es todo lo contrario, les ayuda a realizar mejor su trabajo. Incluso les ahorra tiempo cuando hay que preparar una demo al cliente, todo se reduce a lanzar un build en IC.

Eric comentaba que la IC será un «radiador de información útil para todo el equipo del proyecto». Por último vimos una demostración con Hudson. Destacar el esfuerzo de Eric por hacer la exposición en español.

Methodology for performace testing (Edgardo Greising)

En esta charla Edgardo ha compartido la metodología usada en el laboratorio de Ensayos de Plataformas del CES. Esta metodología consiste en:

• Definición de escenarios: infraestructura, datos de prueba, número de usuarios concurrentes, etc
• Automatización: determinar el guión de ejecución
• Reproducción del entorno de producción: hardware, software, red (en caso de que queramos medir tiempos)
• Monitorización: a nivel software y a nivel humano (usuarios reales interactuando con la aplicación en paralelo con cientos de usuarios virtuales)
• Reportes: recomendando el uso de gráficas para encontrar patrones de comportamiento

Estrategias de integración continua

Desde mi punto de vista las tareas de integración continua en un proyecto deben seguir estrategias diferentes en función del momento en que se encuentre el proyecto.

En fases tempranas del desarrollo los tests suelen fallar, porque el test no es totalmente estable, porque los desarrolladores han modificado algo que afecta a algún test, o simplemente porque en estas fases se producen cambios de rumbo más o menos importantes en cuanto a desarrollo. En esta fase temprana nos interesa que la integración continua genere reportes y documentación con una frecuencia alta (por ejemplo, cada hora) de forma que pueda consultarse el estado de las pruebas, pero que solo «avise» (fallo en una tarea) cuando falla la compilación, y no cuando fallan las pruebas. Es normal que las pruebas fallen, están para eso, si no fallaran nunca no tendrían sentido (o estamos dejando pruebas en el tintero).

Ahora bien, una vez alcanzado aproximadamente el 60% del tiempo total del proyecto se supone que la aplicación es bastante estable y las pruebas deben satisfacerse con pulcritud, ya no es aceptable que se produzcan fallos, y si se producen, debe ser motivo de alerta. En este punto la estrategia de integración continua debe cambiar, la frecuencia de ejecución de pruebas y generación de reportes puede disminuir (por ejemplo, cada noche), la compilación debe mantenerse cada hora, y si una prueba falla sí debe generarse un error en integración continua y notificarlo debidamente.

Sonar y Continuum (La calidad bajo control II)

Hace algún tiempo comentaba cómo Sonar proporciona una serie de medidas de calidad del software. Integrar esta herramienta en el proceso de integración continua modelado con Apache Continuum no ha sido tan fácil como esperaba, sin embargo el resultado merece la pena.

En primer lugar tenemos que instalar y configurar Sonar 1.4RC1. La configuración por defecto hace que la aplicación use una base de datos en ficheros (derby). Dada la restricción impuesta para la configuración con derby haremos que Sonar utilice una base de datos MySQL, esta configuración será necesaria si Sonar y Continuum están en hosts distintos. Debemos comentar en el fichero sonar.properties las lineas:

#sonar.jdbc.url:  jdbc:derby://localhost:1527/sonar;create=true
#sonar.jdbc.driver:  org.apache.derby.jdbc.ClientDriver

y descomentar (sustituyendo <host> y <port> por el host y el puerto de la base de datos):

sonar.jdbc.url:  jdbc:mysql://<host>:<port>/sonar?autoReconnect=true&useUnicode=true&characterEncoding=utf8
sonar.jdbc.driver:  com.mysql.jdbc.Driver

En el fichero sonar.properties también podemos configurar el puerto y el path de la aplicación:

sonar.web.port:  80
sonar.web.context:  /sonar

Para terminar con la configuración debemos crear una base de datos llamada «sonar» y un usuario con permisos que pueda conectarse desde cualquier host.

Ahora debemos configurar nuestro proyecto Maven para ser desplegado en Sonar. Para ello incluiremos un perfil en el fichero POM:

<profile>
    <id>sonar</id>
    <activation>
        <property>
            <name>env</name>
            <value>sonar</value>
        </property>
    </activation>
    <properties>
        <!-- URL de la instancia de Sonar -->
        <sonar.host.url>http://<sonar_host>:<port>/<path></sonar.host.url>
        <!-- URL de la base de datos -->
        <sonar.jdbc.url>jdbc:mysql://<db_host>:<port>/sonar</sonar.jdbc.url>
        <!-- Driver para MySQL -->
        <sonar.jdbc.driver>com.mysql.jdbc.Driver</sonar.jdbc.driver>
        <!-- Usuario de base de datos con permisos sobre la BD "sonar" -->
        <sonar.jdbc.username>username</sonar.jdbc.username>
        <!-- Password el usuario anterior -->
        <sonar.jdbc.password>password</sonar.jdbc.password>
    </properties>
</profile>

Para desplegar el proyecto en Sonar ejecutaremos:

mvn -Psonar org.codehaus.sonar:sonar-maven-plugin:1.4RC1:sonar

En este se ha usado el plugin para la versión 1.4RC1 de Sonar, la versión del plugin debe ser la misma que la del servidor.

Si incluimos esta tarea en Continuum para que se ejecute cada noche entonces cada mañana tendremos un reciente análisis estático del código de nuestro proyecto.

Incluir tarea en Continuum

Procesos de integración continua en Java

Cuando un proyecto Java se incluye en un proceso de integración continua hay una decisión que tomar: ¿qué «builds» definir?.
En principio parece lógico que el proyecto debe, al menos, compilar correctamente. Por tanto tenemos nuestro primer «build», compilación.

En segundo lugar, la ejecución de las pruebas unitarias, indispensables en cualquier proyecto el que se sigue un proceso de QA básico. Segundo «build», ejecución de pruebas unitarias.

Tercero, generación de reportes estáticos. Recopilar la información obtenida de un análisis estático del código. Tercer «build», análisis estático (JavaNCSS, FindBugs, CheckStyle, PMD)

Cuarto, centralización de la información. Recopilar toda la información anterior y colocarla de forma ordenada y accesible. Cuarto «build», ordenar la información (Maven Site).

Quinto, despliegue de la aplicación en caso de ser una aplicación web. De esta forma siempre habrá una instancia de la aplicación desplegada que contiene los últimos cambios sobre el código. Quinto «build», despliegue del proyecto (Cargo).

Evidentemente, la clave para la automatización de todo lo anterior es Maven (con los correspondientes plugins) y una herramienta de integración continua (Continuum, Gump, CruiseControl, …)