Guía de Integración Continua - Jenkins

¿Qué es Jenkins?

Jenkins es un servidor de integración continua Open Source. Esencialmente es una plataforma sobre la cual se pueden automatizar ciertos procesos.

Su uso más difundido es en la generación de builds de aplicaciones a intervalos de tiempo para ejecutar una serie de pruebas sobre los mismos de forma automática. Se lo llama de integración continua porque permite que el código nuevo se vaya integrando y probando de a poco. Esto permite detectar temprano fallos en las aplicaciones de manera que sea más fácil y menos costoso solucionar problemas. De esta manera, podremos contar con una aplicación de mejor calidad a diferencia de las que siguen el esquema tradicional de versiones de desarrollo en hitos alejados en el tiempo, porque acumulan muchas modificaciones de código que luego insumen más tiempo de testing y corrección de los errores.

Requisitos e instalación de Jenkins

Jenkins se presenta como una aplicación Web y, por ende, cuenta con un archivo WAR que requiere de un servidor de aplicaciones para desplegarse, por ejemplo Tomcat o Jboss.

Al ser open source, es gratuito y se puede descargar desde la página oficial del aplicativo dónde encontraremos la última versión disponible.

Es importante resaltar que no requiere de una Base de Datos para funcionar sino que escribe todos los archivos en el disco rígido de la máquina donde este desplegado. Por ello, es necesario reservar suficiente espacio en disco ya que a medida que se configuren nuevos procesos, éstos también harán uso del disco rígido. De todos modos, todas las ubicaciones son configurables.

Una vez instalado el servidor de aplicaciones y desplegado el WAR de Jenkins, la aplicación está lista para ser utilizada, sólo resta ingresar a la URL desde un navegador.

Configuración

Jenkins está configurado por defecto; sin embargo, hay algunas configuraciones que vale la pena tener en cuenta para sacarle un mejor provecho a la aplicación.

Si se dirige al lateral izquierdo de la pantalla, encontrará un menú. En Administrar Jenkins podrá visualizar información acerca de las variables de entorno y el manejo de usuarios, entre otros. No obstante, dentro de Configuración del sistema encontrarán algunas opciones esenciales. A continuación destacaremos algunas de ellas:

• Activar Seguridad: Conviene activar esta opción y establecer una política de usuarios ya que Jenkins está pre-configurado para que cualquier usuario pueda ingresar y acceder a todas las funciones del servidor. Una vez seleccionada, aparecerán nuevas opciones de seguridad, por ejemplo:

- Integración con LDAP

- Esquema de permisos por tabla

- Usuarios registrador tienen acceso global

- Etc.

Adicionalmente, se activa la posibilidad de crear usuarios que puede ser controlada por un administrador que dé de alta los usuarios (desde Gestión de Usuarios) o bien, mediante una opción que permite que los usuarios se den de alta ellos mismos, mediante un formulario de registro.

• Luego encontrarán una serie de opciones para configurar las instalaciones de las distintas herramientas con las que puede trabajar Jenkins. Ellas son:

- JDK: en caso que desee introducir una o varias JDK específicas con las cuáles luego podrá configurar las distintas Tareas.

- Maven: para configurar una o varias instalaciones de Maven que luego pueden ser utilizadas para tareas de build mediante Maven.

- Ant: para instalaciones de Ant con el mismo fin que las de Maven.

- También cuenta con opciones para la configuración global de servidores CVS o SVN como centrales de código.

- Se puede configurar el servicio de correos para que informe en caso de que alguna tarea falle. Para esto último, también existen plugins más avanzados.

Crear nuevas Tareas

Para poder realizar cualquier acción en Jenkins, ya sea un build, ejecutar un script batch o borrar carpetas, debe crear una tarea o proyecto.

Para ello, desde el menú izquierdo, debe seleccionar Crear nueva Tarea, ingresar un nombre para dicho proyecto (que puede ser referenciado a lo largo y ancho de Jenkins) y seleccionar el Tipo de proyecto:

• Estilo Libre: Esto quiere decir que no hay nada pre-configurado y podemos armar el proyecto de acuerdo a nuestras necesidades.

• Maven 2/3: Proyectos basados en Maven que en función de un Pom hace lo que el mismo le indica.

• Copiar un proyecto Existente: Copia el proyecto indicado, pero le asigna el nuevo nombre. Esto es particularmente útil para ahorrar tiempo si debemos crear varios proyectos similares. Obviamente, esta opción no estará disponible hasta que no se haya creado al menos un proyecto.

Después de seleccionar el tipo, la aplicación nos redirigirá a la pantalla del proyecto. En la imagen a continuación, se puede ver la configuración de un proyecto de tipo Libre que ejecuta una tarea de Ant utilizando SVN, con programación por período de tiempo (una vez por semana, todas las semanas) y notificación vía e-mail en caso de fallo.

Configuraciones avanzadas

Los puntos que debe tener en cuenta son los siguientes:

• Una de las opciones es la de “Utilizar un directorio de trabajo personalizado”. Es importante separar los entornos de trabajo de las distintas tareas para así evitar que entren en conflicto. Aquí es donde se descargaran todos los artefactos necesarios para la ejecución de la tarea.

• La configuración del origen del código fuente indica el SVN/CVS de dónde se descargará el código o artefactos que se van a utilizar para el trabajo. La opción de “Utilizar actualización” es importante ya que, de este modo, sólo descargará los cambios si detecta que hubo alguno. Con ello evitamos que esté continuamente descargando elementos del SVN/CVS y reducimos la utilización de recursos.

• Los disparadores de ejecución, como su nombre lo indica, son las distintas opciones disponibles para que la tarea que se está configurando se ejecute. Estos pueden ser:

- Manuales: un usuario presiona sobre botón Lanzar la ejecución. En este caso no se seleccionada nada en disparadores.

- Ejecutar luego de que otros proyectos se hayan ejecutado: en este caso, dispara la tarea luego de que hayan finalizado de ejecutarse uno u varios proyectos que deberá indicar en la caja de texto por nombre de proyecto.

- Ejecuciones remotas mediantes scripts: Consulta el repositorio SCM (SVN/CVS) que dispara la ejecución de la tarea cuando detecta cambios.

- Ejecuciones periódicas: dispara la tarea según el intervalo de tiempo que le indiquemos. Para esto utiliza una nomenclatura de tipo cron (puede ver el detalle de la misma haciendo click en el ícono). En este ejemplo, lo configuramos para que se ejecute todos los sábados a las 21 hs.

• En el apartado “Ejecutar” deberá indicar qué es lo que tiene que realizar la Tarea mediante “Pasos”. Estos pueden ser tareas de Ant, de Maven, procesos batch de Windows u otros procesos Shell. Cada vez que se agrega un nuevo paso, la pantalla muestra las opciones de configuración para cada uno. En este ejemplo, tenemos un único paso que ejecuta una tarea de Ant.

- Versión de Ant: Dejamos la opción Por defecto ya que está configurada de manera global en la configuración de Jenkins.

- Destinos: es el target del archivo de build de Ant, es decir, qué target va a ejecutar dentro de ese xml.

- Fichero Ant: es el nombre del archivo que debe ejecutar. Se especifica únicamente el nombre ya que en la configuración del SVN se indicó el proyecto que se debe descargar y el archivo se encuentra en el root del mismo. Caso contrario, se debe especificar la ruta al mismo.

- Propiedades: aquí podemos indicar valores que le queremos enviar al build de Ant, que luego son referenciados en el mismo. En este ejemplo no le indicamos nada.

• Finalmente tenemos opciones para realizar una tarea luego de que finalice la ejecución otra. Pueden ser todo tipo de tareas como enviar correos, publicar el JavaDoc y/o el resultado de los tests de JUnit, entre otras. Hay una opción particularmente interesante que es la de Ejecutar otros proyectos. Con esta opción, cuando tenemos proyectos que dependen unos de otros, se disparan en cadena.

Por último deberá guardar el proyecto y volver a la pantalla inicial de Jenkins. Allí, podrá ver al proyecto en la lista de tareas y ejecutarlo si lo desea haciendo click en el botón que se encuentra en la última columna.

Cuando termine de ejecutarse, se mostrará cómo ha finalizado con un ícono de color en la columna “S”:

- Azul: si la ejecución fue exitosa.

- Gris: en caso de nunca se haya ejecutado o bien haya sido cancelado por el usuario.

- Rojo: si la ejecución falló.

En la columna “W” se despliegan los siguientes estados de acuerdo con las estadísticas de las últimas 5 ejecuciones:

- Sol: las últimas 5 ejecuciones fueron exitosas.

- Sol con Nubes: 1 o 2 de las últimas 5 ejecuciones fallaron.

- Nubes con Lluvia: 3 o 4 de las últimas 5 ejecuciones fallaron.

- Tormenta Eléctrica: Todas las ejecuciones recientes fallaron.

Es útil para identificar rápidamente el estado de las ejecuciones y tomar medidas correctivas en caso de ser necesario.

Jenkins en Thuban

En nuestro caso particular, se montó una estructura que cuenta con los siguientes componentes:

- Servidor virtual con Windows Server 2003

- Una base de datos Microsoft SQL Server 2005 con datos de prueba configurados (Partición de Disco Propia).

- Una base de datos Oracle 9i (Partición de Disco Propia).

- Una base de datos PostgreSQL 9 (Partición de Disco Propia).

- Una instancia de Tomcat como servicio con Thuban desplegado apuntando a la base de SQL Server.

- Una partición de disco rígido exclusivamente para Jenkins.

- Una instancia de Jenkins configurada con autenticación de usuarios, instalación de Ant y accesible desde internet.

Nuestro Jenkins cuenta con los siguientes proyectos configurados:

• El proyecto Power Desk Web es quien inicia la cadena. Tiene un disparador periódico que ejecuta una tarea Ant encargada de generar el WAR de Thuban Web. Éste proyecto descarga el proyecto ThubanAll del repositorio y utiliza sus correspondientes archivos build xml que son los que tienen configuradas todas las tareas que se deben de realizar para generar los WARS. Todos los WARS generados quedan en una carpeta de accesible en la red.

• Cuando finaliza el “PowerDesk Web”, se lanza la ejecución del proyecto Liquibase-Update-SQL que se ejecuta en base a una tarea de Ant que se encuentra en el proyecto Liquibase. Particularmente lo que hace es ejecutar Liquibase contra los tres motores de base de datos mencionados anteriormente con target Update-SQL y generar los scripts de cambios de base de datos para los 3 motores. Estos cambios son los que ocurrieron entre el build del día anterior y los del día de la fecha y los deja en una carpeta accesible en la red. Además está misma tarea se encarga de detener el servicio del Tomcat que aloja las aplicaciones de Thuban.

• Al finalizar dicho proyecto, se ejecuta el Restore-DB-IC que, a diferencia de los anteriores, no requiere descargar nada del SVN ni tampoco ejecuta Ant, sino que ejecuta un comando de Windows (comando de SQL Server) que se encarga de restaurar la base de datos que se encuentra en SQL Server utilizando un backup de la misma para restaurarla a un estado conocido. Los archivos necesarios para ello se encuentran en la partición de Jenkins.

• Luego se ejecuta el proyecto Liquibase-Update que es igual al anterior, pero con la diferencia que este se ejecuta en modo Update contra las 3 bases de datos actualizándoles la estructura a la última versión.

• Cuando finaliza Liquibase-Update, se ejecuta el Deploy-Daily-Builds. Esta tarea de Ant se encarga de tomar los WARS de Thuban Web, renombrarlos y copiarlos en la carpeta “webapps” de la instancia de Tomcat. Luego inicia el proceso del Tomcat y espera dos minutos hasta que se termine de desplegar.

• Al finalizar todas las tareas, quedan los WARS disponibles para quienes los quieran probar. Además, se dispone de una instancia de los mismos ya desplegados y accesibles para probarlos sin necesidad de generar un nuevo entorno.

Todo este proceso comienza a las 5 AM de lunes a viernes. Por eso se generan carpetas con la fecha y, dentro de ellas, subcarpetas para los WARS y scripts de base de datos.

De todos modos, nos queda pendiente la incorporación de ejecución de tests automáticos sobre las aplicaciones. Por ello, se incorporará Selenium para que se ejecuten test gráficos sobre los circuitos de funcionalidad básica del sistema.

• Finalmente, el proyecto CleanDailyReleases se encarga de eliminar todas los builds que se generaron durante la semana y así dejar lugar para las que se van a crear durante la semana siguiente. Este proceso se ejecuta todos los sábados a las 21hs con una tarea ANT.

Por otra parte, todos los proyectos tiene configurados el envió automáticos de e-mails en caso de que alguno de los builds falle. Para ello, se instaló el “Jenkins Email Extension Plugin” que otorga un espectro más amplio de configuración que la funcionalidad incluida por defecto en Jenkins.