Caso práctico: Configuración de la fase beta.

Enunciado

Se pretende crear una tarea nueva en Jenkins de manera que cada vez que se detecten cambios en nuestro repositorio, se baje el código que existe en la rama develop actualmente, ejecute las acciones clean(borrar carpeta /target) compile(compilar) y war:war(empaquetar el proyecto en un archivo .war) y que seguidamente lo despliegue a un servidor en Tomcat.

Solución

Vamos a ir explicando paso a paso desde la creación de la tarea en Jenkins con imágenes:

1. Creación de la tarea

Para crear la tarea, lo primero que haremos será iniciar sesión en Jenkins y seguidamente en la parte izquierda de la pantalla veremos una opción en la que dice "Nueva tarea".

Seguidamente se nos abrirá una ventana como la siguiente en la que tendremos que especificar el nombre para la tarea, en este ejemplo usaremos "Agora US - Visualización G28 - Beta".

Una vez hayamos rellenado el nombre que queramos haremos clic en "Ok" más abajo.

2. Configuración de la tarea

2.1. Configuración general

Jenkins nos redirigirá automáticamente a la página donde configuraremos nuestra nueva tarea. Lo primero que podremos hacer será rellenar alguna información general para ésta, como por ejemplo una descripción y algunas opciones más. ::Nosotros hemos decidido activar las opciones de desechar ejecuciones antiguas para que no llegara el punto en el que se nos pueda ir de las manos con los logs. También tenemos activada la opción de GitHub project, que no es más que mera información para nuestra tarea, aquí no se especifica de donde se descargará el código.

2.2. Configurar el origen del código fuente

Seguidamente, en el apartado "Configurar el origen del código fuente" es donde le detallaremos a Jenkins de dónde se descargará nuestro código fuente. En nuestro caso le definimos nuestro repositorio y le indicamos que la rama que se va a descargar va a ser la develop, ya que estamos creando la tarea para automatizar una versión beta.

2.3. Disparadores de ejecuciones

Este apartado es importante, ya que definimos la manera en la que la tarea se va a ejecutar. Nosotros hemos montado un servidor casero redirigiendo el tráfico de nuestro router a nuestra máquina virtual, de manera que sea accesible desde Internet, de esta manera hemos podido hacer que GitHub nos pueda escuchar, y de esta manera, configurar la tarea para que se ejecute cada vez que vea cambios en nuestro repositorio en GitHub.

Para que esto funcione, también tendremos que tocar en nuestro repositorio en GitHub, de manera que cuando GitHub detecte un cambio, envíe una petición a nuestro Jenkins para ejecutar la tarea.

Nos dirigiremos a nuestro repositorio en GitHub, y nos iremos al apartado Settings

Seguidamente, en el menú de la izquierda haremos clic en Integrations and services y haremos clic en Add service. Se nos abrirá un deplegable en el que buscaremos Jenkins (Git plugin) y haremos clic sobre él.

Por último colocaremos la URL de nuestro Jenkins terminada en /github-webhook/ y listo.

2.4. Ejecutar

En nuestro caso, no usamos herramientas como Docker que nos permitirían tener en un contenedor propio cada entorno de ejecución en una misma máquina, con lo que haciendo uso de la externalización de la configuración con Spring vamos a poder tener una base de datos distinta para nuestras versiones beta y stable en el mismo MySQL.

También nos hacía falta automatizar primero la eliminación y seguidamente de nuevo la creación de la base de datos, usuarios, permisos y populación de la misma para cada vez que se ejecute nuestra tarea, ya que podría ser que hubieran habido cambios en nuestra base de datos y necesitamos hacer esto. Para estas tareas, nos ayudamos con un script en bash, por eso lo que necesitaremos definir será una acción de tipo Ejecutar linea de comandos (shell).

Por último, definiremos en este apartado otra acción más, la cual será Ejecutar tareas 'maven' de nivel superior, en la que le diremos a Maven que por favor compile y genere el war de nuestro proyecto para posteriormente poder desplegarlo en nuestro entorno beta. Este war generado se guardará dentro de la carpeta /target, lo que posteriormente nos servirá para señalárselo a Jenkins.

2.5. Acciones para ejecutar después

Por último lo que queremos es que automáticamente nos despliegue nuestro Tomcat, para ello necesitaremos definir una acción de tipo Deploy war/ear to a container. Este tipo de acción nos viene dada de un plugin que hemos instalado llamado Deploy to container Plugin.

Para que esto funcione, en nuestro Tomcat tendremos que tener creado un usuario con el rol manager-script el cual le indicaremos el usuario y la contraseña para que Jenkins pueda desplegar el war.

• NOTA: la tarea para la automatización de nuestro entorno stable sería replicando lo mismo quitando la parte de Disparadores de ejecuciones, ya que la tarea stable la ejecutaremos manualmente por temas de estabilidad.

Volver a página del grupo: Visualización y Gestión de Resultados (G28)