Jira plug-in entorno de integración continua (2)

Montamos el entorno de CI para programar de una manera limpia y segura

Mi objetivo es construir una aplicación siguiendo un orden lógico y una metodología de trabajo adaptada a mis necesidades. Es por esto que he decidido montar un entorno de integración continua. Al tener conectado el código con una herramienta de CI y testear cada vez que voy cambiando y evolucionando el código, me aseguro tener en master siempre una versión estable.

No vamos a practicar TDD en este caso, a esto me refiero con una “metodología adaptada a mis necesidades”, pero sí vamos a realizar algunos tests iniciales para tener el core de la aplicación siempre asegurado y testeado. No es necesario utilizar TDD puro para realizar una buena práctica de programación. Gracias a esto nos aseguraremos de no dañar el núcleo de la aplicación.

Resumidamente: El TDD (Test Driven Development/Desarrollo Guiado por Test) es una metodología de trabajo cuya principal diferencia con respecto a las demás radica en crear los tests antes que el propio código y, por lo tanto, desarrollar el código directamente para pasar esos tests.

Para empezar…

Lo primero que debemos hacer es subir nuestro proyecto a GitHub.

Se puede ver mi proyecto en la siguiente dirección:

jira-bdd-plugin

Ahora vamos a crear los tests. Para empezar crearemos uno muy sencillo de ejemplo para comprobar que funciona nuestro entorno de CI.

Debemos instalar Mocha en nuestro proyecto:

npm install — global mocha

Mocha busca los archivos de test en la carpeta “test” por defecto, y si creamos logs se alojarán también ahí por defecto. Por lo que crearemos la carpeta test en la raíz de nuestro proyecto y dentro crearemos el archivo test.js y escribiremos una sencilla función de ejemplo:

Test de ejemplo

Para lanzar el test debemos utilizar el comando “mocha”. Nos aparecerá en la consola un mensaje de confirmación si pasamos el test satisfactoriamente.

Una vez que tenemos los tests, debemos elegir una herramienta de integración continua. Como mencioné en el primer post, utilizaré Bamboo
¿Por qué no Jenkins? 
Porque Bamboo es un producto de Atlassian y hay mucha documentación sobre cómo integrar plug-ins de Jira con Bamboo, por lo que, si tenemos problemas a la hora de integrar nuestro proyecto, lo más seguro es que encontremos la solución con una rápida búsqueda en Google. Además, ya conocía Jenkins y quería ver lo que ofrecía Bamboo (no está nada mal).

Para usar Bamboo debemos descargarnos el software desde su propia página y lanzar su servidor. Para ello vamos al directorio raíz donde hemos instalado Bamboo y corremos el siguiente comando:

bin/start-bamboo.bat

Con esto iniciaremos el tomcat que trae configurado. Al entrar en el servidor nos encontramos con nuestro Dashboard (como en Jenkins):

Bamboo Dashboard

Lo primero que debemos hacer es crear un proyecto nuevo y configurar un plan para el proyecto (las tareas o tasks). Dentro de un plan podemos agrupar varias tareas en Jobs. Por lo tanto, creamos un Job y, dentro de este, vamos creando las tareas.

Podemos crear distintos tipos de tareas, desde tareas de tipo comandos en la shell hasta de tipo Node e incluso Mocha, Maven, npm o Grunt.

Para crear las tareas, lo primero que debemos saber es que, al correr el plan, Bamboo copiará el código del repositorio a una carpeta que tendremos en local llamada bamboo-home (se crea al instalar Bamboo en el directorio que le asignemos).
Sabiendo esto, las tareas que he configurado han sido la instalación de los módulos propios de node, la instalación de Mocha y el lanzamiento de los tests.

Una vez configuradas las tareas, lanzamos el plan y, si todo ha ido bien, nos dará un mensaje de confirmación. Sino, tendremos que mirar el log que genera y buscar los errores que hayan saltado e ir solventándolos.

Al crear el proyecto lo habremos enlazado con nuestro repositorio de GitHub. Ahora que sabemos que nuestro plan funciona, podemos configurar un trigger para que corra el plan cada vez que hacemos un pull a una rama concreta de nuestro repositorio. En mi caso será la rama test. Mi estructura de ramas es la siguiente: De master sólo nace una rama: test. De la rama test nace la rama en la que habitualmente subiré el código: production. Desde production sólo pulleo a test, y de test (una vez pasados los tests) a master. Con esto tendremos siempre asegurada una versión estable y testeada en master.

Terminando…

Una vez hecho un pull de prueba a test y comprobado que se lanza el plan automáticamente ya podremos decir que hemos terminado de montar nuestro entorno de integración continua.

En el próximo post comenzaremos a realizar tests que nos sirvan para nuestra aplicación, para lo que debemos tener muy claras las historias de usuario (al menos las iniciales). También comenzaremos a programar el propio código de la aplicación y ver cómo va evolucionando en Jira.