Diferencia entre revisiones de «Caso práctico: Configuración de la fase beta.»
De Wiki de EGC
(No se muestran 4 ediciones intermedias del mismo usuario) | |||
Línea 1: | Línea 1: | ||
== Enunciado == | == 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. | + | 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 == | == Solución == | ||
Línea 10: | Línea 10: | ||
: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". | :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". | ||
− | :[[Archivo: | + | :[[Archivo:1 1 G28.png||350px]] |
: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". | :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". | ||
− | : | + | :[[Archivo:1 2 G28.png||750px]] |
Línea 25: | Línea 25: | ||
::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. | ::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. | ||
− | ::[ | + | ::[[Archivo:21 1 G28.png||750px]] |
Línea 31: | Línea 31: | ||
::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. | ::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. | ||
− | ::[ | + | ::[[Archivo:22 1 G28.png||750px]] |
− | :''2. | + | :''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. | ::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. | ||
− | ::[ | + | ::[[Archivo:23 1 G28.png||750px]] |
Línea 43: | Línea 43: | ||
::Nos dirigiremos a nuestro repositorio en GitHub, y nos iremos al apartado '''Settings''' | ::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. | ::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. | ||
− | ::[ | + | ::[[Archivo:23 2 G28.png||750px]] |
::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo. | ::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo. | ||
− | ::[ | + | ::[[Archivo:23 3 G28.png||750px]] |
− | :''2. | + | :''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. | ::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. | ||
Línea 56: | Línea 56: | ||
::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)'''. | ::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)'''. | ||
− | ::[ | + | ::[[Archivo:24 1 G28.png||750px]] |
+ | |||
+ | ::[[Archivo:24 2 G28.png||750px]] | ||
::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. | ::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. | ||
− | ::[ | + | ::[[Archivo:24 3 G28.png||750px]] |
− | :''2. | + | :''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'''. | ::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'''. | ||
− | ::[ | + | ::[[Archivo:25 1 G28.png||750px]] |
::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. | ::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. | ||
Línea 75: | Línea 77: | ||
*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. | *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. | ||
+ | |||
+ | |||
+ | [[Archivo:arrow_left_16x16.png]] Volver a página del grupo: [https://1984.lsi.us.es/wiki-egc/index.php/Visualizaci%C3%B3n_y_Gesti%C3%B3n_de_Resultados_G28 Visualización y Gestión de Resultados (G28)] |
Revisión actual del 23:22 11 ene 2017
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.
- 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)