Wiki de EGC - Contribuciones del usuario [es]

Caso práctico: Integración de Travis con GitHub.

2017-01-11T22:44:50Z

Alemurrod:

== Enunciado ==

Se pretende conectar Travis a nuestra cuenta de GitHub para que construya el proyecto y pase las pruebas de este.

== Solución==
'''''1. Conectar Travis con GitHub'''''
:Lo primero que se debe hacer es acceder a la pagina de Travis https://travis-ci.org/, una vez en la pagina hay que pulsar en el boton de la esquina superior izquierda donde dice registrarse con GitHub, donde se nos pedirá nuestros credenciales de GitHub. A continuación GitHub nos pedirá autorizar a Travis para acceder a nuestra cuenta, una vez autorizado debemos esperar un tiempo para que Travis busque nuestros repositorios de GitHub.
'''''2. Configurar Travis'''''
:[[Archivo:Intrucciones travis.PNG||400px]]
:Una vez accedido deben seguirse las instrucciones que ofrece Travis que podemos ver en la imagen, en nuestro caso añadimos el repositorio del proyecto y añadimos en la raiz del proyecto el fichero de configuración de Travis .travis.yml con el siguiente código:
:<code>
language:
- java
services:
- mysql
jdk:
- oraclejdk8
- openjdk7
before_install:
- mysql -u root < bbdd_Travis.sql
script:
- mvn clean test
cache:
directories:
- $HOME/.m2
dist:
- trusty
sudo:
- false
notifications:
- email: false
:</code>

:Con este fichero estámos indicando que:
:* Se trata de un proyecto java
:* Se usa una base de datos de MySQL
:* Debe funcionar tanto en java 7 como en java 8
:* Antes de comenzar el script cargar el fichero de la base de datos bbdd_Tavis.sql que crea la base de datos y usuarios.
:* Los comandos de maven a ejecutar son clean y test

:'''Fichero bbdd.Travis.sql''':
<code>
start transaction;
DROP DATABASE IF EXISTS `egc-frontend`;
CREATE DATABASE `egc-frontend`;
USE `egc-frontend`;
GRANT ALL ON `egc-frontend`.* TO 'user-frontend'@'localhost' IDENTIFIED BY 'us4r-front4nd';
COMMIT;
</code>
'''''3. Observar funcionamiento de Travis'''''
:A partir de este punto Travis ejecutará las pruebas cada vez que se haga un commit del proyecto en GitHub mostrando en el commit de GitHub un indicador de si las prueba se han pasado correctamente o ha surgido algún problema.
:Si accedemos de nuevo a la página en el instante en el que se haya ejecutado un push en GitHub, podremos observar que Travis está realizando lo indicado e el archivo de configuración (téngase en cuenta que Travis está trabajando en una maquina externa y el tiempo de respuesta puede ser alto).
:[[Archivo:Travis trabajando.PNG||750px]]

:Una vez acabado el proceso aparecerá todo en verde si no ha surgido algún problema durante la ejecución y la consola mostrará el siguiente mensaje
:[[Archivo:Travis finalizado.PNG||500px]]

[[Archivo:arrow_left_16x16.png]] Volver a la 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)]

Caso práctico: Integración de Travis con GitHub.

2017-01-11T22:43:33Z

Alemurrod:

Caso práctico: Integración de Travis con GitHub.

2017-01-11T22:43:16Z

Alemurrod:

== Enunciado ==

Se pretende conectar Travis a nuestra cuenta de GitHub para que construya el proyecto y pase las pruebas de este.

== Solución==
'''''1. Conectar Travis con GitHub'''''
:Lo primero que se debe hacer es acceder a la pagina de Travis https://travis-ci.org/, una vez en la pagina hay que pulsar en el boton de la esquina superior izquierda donde dice registrarse con GitHub, donde se nos pedirá nuestros credenciales de GitHub. A continuación GitHub nos pedirá autorizar a Travis para acceder a nuestra cuenta, una vez autorizado debemos esperar un tiempo para que Travis busque nuestros repositorios de GitHub.
'''''2. Configurar Travis'''''
:[[Archivo:Intrucciones travis.PNG||400px]]
:Una vez accedido deben seguirse las instrucciones que ofrece Travis que podemos ver en la imagen, en nuestro caso añadimos el repositorio del proyecto y añadimos en la raiz del proyecto el fichero de configuración de Travis .travis.yml con el siguiente código:
:<code>
language:
- java
services:
- mysql
jdk:
- oraclejdk8
- openjdk7
before_install:
- mysql -u root < bbdd_Travis.sql
script:
- mvn clean test
cache:
directories:
- $HOME/.m2
dist:
- trusty
sudo:
- false
notifications:
- email: false
:</code>

:Con este fichero estámos indicando que:
:* Se trata de un proyecto java
:* Se usa una base de datos de MySQL
:* Debe funcionar tanto en java 7 como en java 8
:* Antes de comenzar el script cargar el fichero de la base de datos bbdd_Tavis.sql que crea la base de datos y usuarios.
:* Los comandos de maven a ejecutar son clean y test

'''Fichero bbdd.Travis.sql''':
<code>
start transaction;
DROP DATABASE IF EXISTS `egc-frontend`;
CREATE DATABASE `egc-frontend`;
USE `egc-frontend`;
GRANT ALL ON `egc-frontend`.* TO 'user-frontend'@'localhost' IDENTIFIED BY 'us4r-front4nd';
COMMIT;
</code>
'''''3. Observar funcionamiento de Travis'''''
:A partir de este punto Travis ejecutará las pruebas cada vez que se haga un commit del proyecto en GitHub mostrando en el commit de GitHub un indicador de si las prueba se han pasado correctamente o ha surgido algún problema.
:Si accedemos de nuevo a la página en el instante en el que se haya ejecutado un push en GitHub, podremos observar que Travis está realizando lo indicado e el archivo de configuración (téngase en cuenta que Travis está trabajando en una maquina externa y el tiempo de respuesta puede ser alto).
:[[Archivo:Travis trabajando.PNG||750px]]

:Una vez acabado el proceso aparecerá todo en verde si no ha surgido algún problema durante la ejecución y la consola mostrará el siguiente mensaje
:[[Archivo:Travis finalizado.PNG||500px]]

Hoja de tiempos - Visualización y gestión de resultados - 2016-2017

2017-01-11T22:27:10Z

Alemurrod:

Esta es la hoja de tiempos del grupo [[Visualización y Gestión de Resultados G28]]. En ella se muestran los tiempos dedicados por cada uno de los miembros del equipo.

== Dedicación de los miembros del grupo ==

{| border="1" style="border-collapse:collapse;text-align:center" class="wikitable"
|-
! Miembro del grupo
! Grado de implicación (1-5)
|-
| [[Usuario:juacascor|Juan Antonio Castañeda Cortázar]]
| 5
|-
| [[Usuario:alemurrod|Alejandro Murillo Rodríguez]]
| 5
|-
| [[Usuario:abdche|Abdelkader Chellik]]
| 5
|-
| [[Usuario:zaksah2|Zakaria Sahmoudi]]
| 5
|}

== Tabla de tiempos ==

{| border="1" style="border-collapse:collapse" class="wikitable sortable"
|-
! Fecha
! Tiempo (m)
! Miembro(s) del grupo
! Actividad
! Comentarios
|-
| 11/11/16
| 50
| Todos
| Reunión inicial
|
* Presentación de los distintos miembros del grupo
* Elección del subsistema a desarrollar por el grupo.
* Definir el sistema de comunicación dentro del grupo.
* Elección de coordinadores.
* Definir la periodicidad con la que los miembros se reunirán.

|-
| 04/01/17
| 360
| Alejandro Murillo Rodríguez, Abdelkader Chellik
| Investigación e implementación
|
* Preparación de máquina virtual para instalar Jenkins y los entornos para beta y stable.
* Configuración de base de datos y preparación del script.

|-
| 05/01/17
| 120
| Alejandro Murillo Rodríguez, Abdelkader Chellik
| Implementación
|
* Configurar tarea beta de Jenkins.
* Replicar tarea beta para stable.

|-
| 11/01/17
| 60
| Alejandro Murillo Rodríguez
| Documentación
|
* Caso práctico de Jenkins.

|-
| 13/11/16
| 360
| Alejandro Murillo Rodríguez
| Realización de mejora del código.
|
* Acordeón en página de resultados.
|-
| 21/11/16
| 120
| Todos
| Diseño de la interfaz.
|
* Despliegue de manera aislada del subsistema.
* Definir la herramienta de gestión del código del proyecto a usar.
* Comunicación con los coordinadores de los demás subsistemas para informarnos sobre el canal de comunicación existente.

|-
| 13/11/16
| 360
| Alejandro Murillo Rodríguez
| Realización de mejora del código.
|
* Acordeón en página de resultados.

|-
| 15/11/16
| 90
| Juan Antonio Castañeda Cortázar
| Realización de mejora del código.
|
* Cambio en estilo de pagina de encuesta.

|-
| 21/11/16
| 120
| Todos
| Diseño de la interfaz.
|
* Despliegue de manera aislada del subsistema.
* Definir la herramienta de gestión del código del proyecto a usar.
* Comunicación con los coordinadores de los demás subsistemas para informarnos sobre el canal de comunicación existente.
|-
| 29/11/16
| 30
| Juan Antonio Castañeda Cortázar
| Realización de mejora del código.
|
* Cambio en estilo de pagina de encuesta.

|-
| 11/12/16
| 90
| Abdelkader Chellik
| Documentacion Googledrive
|
* Documento del proyecto

|-
| 27/12/16
| 240
| Abdelkader Chellik
| Accordion estadisticas
|
* Poner el Accordion para el boton "ver graficas"

|-
| 29/12/16
| 60
| Juan Antonio Castañeda Cortázar
| Arreglo de issue
|
* Fix de la issue #1 Todas las paginas salen en blanco

|-
| 06/01/17
| 120
| Juan Antonio Castañeda Cortázar, Alejandro Murillo Rodríguez
| Configuración travis
|
* Conectar travis con el repositorio
* Crear fichero de configuración

|-
| 06/01/17
| 120
| Alejandro Murillo Rodríguez, Juan Antonio Castañeda Cortázar
| Arreglo de issue
|
* Fix de la issue #3 Implementación de footer no optima

|-
| 06/01/17
| 120
| Juan Antonio Castañeda Cortázar
| Arreglos en la pagina de encuestas
|
* Cambio estilo en encuestas
* Arreglo de botón de main de la pagina principal

|-
| 05/01/17
| 75
| Alejandro Murillo Rodríguez
| Arreglo de issue
|
* Añadido script para popular, cambiado favicon, y tag base dinámica.

|-
| 07/01/17
| 300
| Alejandro Murillo Rodríguez, Abdelkader Chellik
| Mejora visual parte de estadísticas
|
* Mejora visual de la parte de estádisticas.

|-
| 07/01/17
| 90
| Juan Antonio Castañeda Cortázar
| Cambio de estilo en la visualización del mapa
|
* Aumentar tamaño de mapa
* Añadida cabecera con icono

|-
| 08/01/17
| 90
| Alejandro Murillo Rodríguez
| Programación
|
* Limpieza del código y arreglo de la issue #5

|-
| 09/01/17
| 120
| Alejandro Murillo Rodríguez, Juan Antonio Castañeda Cortázar
| Programación
|
* Fix: tests jUnit

|-
| 21/11/16
| 120
| Todos
| Diseño de la interfaz.
|
* Despliegue de manera aislada del subsistema.
* Definir la herramienta de gestión del código del proyecto a usar.
* Comunicación con los coordinadores de los demás subsistemas para informarnos sobre el canal de comunicación existente.
|-
| 06/12/16
|90
| Zakaria Sahmoudi
| Programación.
|
* cambiar estilo.
* Meter el botón de ver estadística.
|-
| 06/12/16
| 120
| Todos
| Reunión
|
* Creación del repositorio en GitHub.
* Definición de un proceso para la gestión del código.
* Elección de la herramienta a usar para la gestión de incidencias del proyecto.
* Elección de mejoras en el código.
|-
| 08/12/16
|120
| Zakaria Sahmoudi
| Programación.
|
* cambiar estilo.
* Arreglar pie de las páginas.
|-
| 11/12/16
|120
| Zakaria Sahmoudi
| Programación.
|
* cambiar estilo.
*cambiar colores de la pagina principal y botones.
|-
| 12/12/16
| 120
| Todos
| Reunión
|
* Trabajo en las mejoras.
* Puesta en común de las mejoras realizadas.
* Actualización la rama development en github.
* Creación de las ramas locales para nuevas mejores.
* Acordar reunión con grupo de cabina para realizar preparativos para la integración.
|-
| 27/12/16
|60
| Todos
| Reunión
|
* Elección de herramienta de integración continua.
* Reparto de documentación.
|-
| 05/01/17
|150
| Zakaria Sahmoudi
| Documentación Hoja de tiempo.
|
* Hoja de tiempo con todos los reuniones que han hecho el grupo.

|-
| 10/01/17
| 90
| Juan Antonio Castañeda Cortázar
| Documentación wiki
|
* Integración continua Travis
|-
| 10/01/17
|40
| Zakaria Sahmoudi, Abdelkader Chellik
| Documentación wiki.
|
* gestión de comunicación.
* gestión de las tareas.

|}

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

2017-01-11T22:22:08Z

Alemurrod:

== 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".
:[[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".
:[[Archivo:1 2 G28.png||750px]]

: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.
::[[Archivo:21 1 G28.png||750px]]

:''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.
::[[Archivo:22 1 G28.png||750px]]

:''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.
::[[Archivo:23 1 G28.png||750px]]

::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.
::[[Archivo:23 2 G28.png||750px]]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[[Archivo:23 3 G28.png||750px]]

:''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)'''.

::[[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.

::[[Archivo:24 3 G28.png||750px]]

:''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'''.

::[[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.

*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)]

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

2017-01-11T22:21:57Z

Alemurrod:

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

2017-01-11T22:20:40Z

Alemurrod:

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

2017-01-11T22:19:52Z

Alemurrod: /* Solución */

== 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".
:[[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".
:[[Archivo:1 2 G28.png||750px]]

: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.
::[[Archivo:21 1 G28.png||750px]]

:''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.
::[[Archivo:22 1 G28.png||750px]]

:''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.
::[[Archivo:23 1 G28.png||750px]]

::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.
::[[Archivo:23 2 G28.png||750px]]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[[Archivo:23 3 G28.png||750px]]

:''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)'''.

::[[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.

::[[Archivo:24 3 G28.png||750px]]

:''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'''.

::[[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.

*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:25 1 G28.png

2017-01-11T22:19:25Z

Alemurrod:

Archivo:24 3 G28.png

2017-01-11T22:19:11Z

Alemurrod:

Archivo:24 2 G28.png

2017-01-11T22:18:59Z

Alemurrod:

Archivo:24 1 G28.png

2017-01-11T22:18:46Z

Alemurrod:

Archivo:23 3 G28.png

2017-01-11T22:18:28Z

Alemurrod:

Archivo:23 2 G28.png

2017-01-11T22:17:33Z

Alemurrod:

Archivo:23 1 G28.png

2017-01-11T22:17:18Z

Alemurrod:

Archivo:22 1 G28.png

2017-01-11T22:17:07Z

Alemurrod:

Archivo:21 1 G28.png

2017-01-11T22:16:53Z

Alemurrod:

Archivo:1 2 G28.png

2017-01-11T22:16:43Z

Alemurrod:

Archivo:1 1 G28.png

2017-01-11T22:16:31Z

Alemurrod:

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

2017-01-11T22:15:55Z

Alemurrod:

== 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".
:[[Archivo:1 1 G28.png||750px]]

: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]]

: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.
::[[Archivo:21 1 G28.png||750px]]

:''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.
::[[Archivo:22 1 G28.png||750px]]

:''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.
::[[Archivo:23 1 G28.png||750px]]

::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.
::[[Archivo:23 2 G28.png||750px]]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[[Archivo:23 3 G28.png||750px]]

:''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)'''.

::[[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.

::[[Archivo:24 3 G28.png||750px]]

:''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'''.

::[[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.

*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.

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

2017-01-11T22:04:22Z

Alemurrod:

== 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".
:[[Archivo:Usage model G28.png||750px]]

: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.
::[imagen aquí]

:''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.
::[imagen aquí]

:''2.2. 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.
::[imagen aquí]

::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.
::[imagen aquí]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[imagen aquí]

:''2.3. 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)'''.

::[imágenes aquí]

::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.

::[imagen aquí]

:''2.4. 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'''.

::[imagen aquí]

::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.

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

2017-01-11T22:04:13Z

Alemurrod:

== 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".
:[[Archivo:Usage model G28.png||500px]]

: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.
::[imagen aquí]

:''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.
::[imagen aquí]

:''2.2. 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.
::[imagen aquí]

::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.
::[imagen aquí]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[imagen aquí]

:''2.3. 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)'''.

::[imágenes aquí]

::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.

::[imagen aquí]

:''2.4. 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'''.

::[imagen aquí]

::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.

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

2017-01-11T22:03:59Z

Alemurrod:

== 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".
:[[Archivo:Usage model G28.png||300px]]

: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.
::[imagen aquí]

:''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.
::[imagen aquí]

:''2.2. 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.
::[imagen aquí]

::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.
::[imagen aquí]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[imagen aquí]

:''2.3. 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)'''.

::[imágenes aquí]

::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.

::[imagen aquí]

:''2.4. 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'''.

::[imagen aquí]

::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.

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

2017-01-11T22:03:30Z

Alemurrod:

== 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".
:[[Archivo:Usage model G28.png]]

: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.
::[imagen aquí]

:''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.
::[imagen aquí]

:''2.2. 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.
::[imagen aquí]

::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.
::[imagen aquí]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[imagen aquí]

:''2.3. 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)'''.

::[imágenes aquí]

::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.

::[imagen aquí]

:''2.4. 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'''.

::[imagen aquí]

::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.

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

2017-01-11T22:03:22Z

Alemurrod:

== 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".
:[[Archivo:Usage model G28.png]

: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.
::[imagen aquí]

:''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.
::[imagen aquí]

:''2.2. 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.
::[imagen aquí]

::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.
::[imagen aquí]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[imagen aquí]

:''2.3. 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)'''.

::[imágenes aquí]

::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.

::[imagen aquí]

:''2.4. 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'''.

::[imagen aquí]

::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.

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

2017-01-11T22:01:59Z

Alemurrod:

== 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".
:[[Archivo:Usage model G28.png|thumb]]

: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.
::[imagen aquí]

:''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.
::[imagen aquí]

:''2.2. 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.
::[imagen aquí]

::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.
::[imagen aquí]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[imagen aquí]

:''2.3. 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)'''.

::[imágenes aquí]

::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.

::[imagen aquí]

:''2.4. 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'''.

::[imagen aquí]

::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.

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

2017-01-11T22:01:36Z

Alemurrod:

== 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".
:[[Archivo:Usage model G28.png|thumb|alt=Alt|Usage model|upright=3]]

: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.
::[imagen aquí]

:''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.
::[imagen aquí]

:''2.2. 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.
::[imagen aquí]

::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.
::[imagen aquí]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[imagen aquí]

:''2.3. 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)'''.

::[imágenes aquí]

::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.

::[imagen aquí]

:''2.4. 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'''.

::[imagen aquí]

::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.

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

2017-01-11T22:00:40Z

Alemurrod:

== 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".
:[imagen aquí]

: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".
:[imagen aquí]

: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.
::[imagen aquí]

:''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.
::[imagen aquí]

:''2.2. 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.
::[imagen aquí]

::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.
::[imagen aquí]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[imagen aquí]

:''2.3. 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)'''.

::[imágenes aquí]

::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.

::[imagen aquí]

:''2.4. 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'''.

::[imagen aquí]

::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.

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

2017-01-11T22:00:01Z

Alemurrod:

== 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".
:[imagen aquí]

: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".
:[imagen aquí]

: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.
::[imagen aquí]

:''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.
::[imagen aquí]

:''2.2. 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.
::[imagen aquí]

::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.
::[imagen aquí]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[imagen aquí]

:''2.3. 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)'''.

::[imágenes aquí]

::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.

::[imagen aquí]

:''2.4. 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'''.

[imagen aquí]

::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.

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

2017-01-11T21:54:54Z

Alemurrod:

== 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".
:[imagen aquí]

: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".
:[imagen aquí]

: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.
::[imagen aquí]

:''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.
::[imagen aquí]

:''2.2. 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.
::[imagen aquí]

::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.
::[imagen aquí]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[imagen aquí]

:''2.3. 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)'''.

::[imágenes aquí]

::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.

::[imagen aquí]

:''2.4. 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'''

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

2017-01-11T21:49:40Z

Alemurrod:

== 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".
:[imagen aquí]

: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".
:[imagen aquí]

: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.
::[imagen aquí]

:''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.
::[imagen aquí]

:''2.2. 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.
::[imagen aquí]

::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.
::[imagen aquí]

::Por último colocaremos la URL de nuestro Jenkins terminada en '''/github-webhook/''' y listo.
::[imagen aquí]

:''2.3. 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)'''.

::[imágenes aquí]

::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.

::[imagen aquí]

:''2.4. Acciones para ejecutar después''

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

2017-01-11T21:34:59Z

Alemurrod:

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

2017-01-11T21:33:54Z

Alemurrod:

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

2017-01-11T21:24:12Z

Alemurrod:

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

2017-01-11T21:21:37Z

Alemurrod:

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

2017-01-11T21:21:17Z

Alemurrod:

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

2017-01-11T21:20:57Z

Alemurrod:

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

2017-01-11T21:20:17Z

Alemurrod:

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

2017-01-11T21:20:10Z

Alemurrod:

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

2017-01-11T21:20:03Z

Alemurrod:

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

2017-01-11T21:19:43Z

Alemurrod:

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

2017-01-11T21:19:31Z

Alemurrod:

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

2017-01-11T21:19:20Z

Alemurrod:

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

2017-01-11T21:18:56Z

Alemurrod: Página creada con «== 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 ram...»

Visualización y Gestión de Resultados G28

2017-01-10T22:12:19Z

Alemurrod:

== Miembros del equipo ==

*[[Usuario:juacascor|Juan Antonio Castañeda Cortázar]] '''Coordinador - Ingeniero Software'''
*[[Usuario:alemurrod|Alejandro Murillo Rodríguez]] '''Coordinador - Ingeniero Software'''
*[[Usuario:abdche|Abdelkader Chellik]] '''Ingeniero Software'''
*[[Usuario:zaksah2|Zakaria Sahmoudi]] '''Ingeniero Software'''

== Definición del proyecto ==
Este proyecto trata del desarrollo del subsistema de Agora@US "Visualización y gestión de resultados". Nuestro grupo es el encargado de desarrollar el sistema de visualización, cuyo propósito es crear gráficas que muestren los resultados de las votaciones a partir de los datos obtenidos de los otros subsistemas.

== Código heredado ==

A continuación ofrecemos el siguiente enlace donde se encuentra el código del proyecto heredado en la plataforma GitHub:

* https://github.com/AgoraUS1516/G10

== Gestión de la comunicación ==

Para la buena comunicación entre los miembros del grupo nos hemos basado en herramientas como:
* '''Telegram''': lo hemos usado para comunicaciones cortas
* '''Hangouts''': para realizar reuniones telemáticas y nos dimos cuenta que no era tan eficaz porque no se entendía muy bien cuando se ponen a hablar más de dos personas y también había problemas de conexión
* '''Reuniones presenciales''': para nosotros ha sido la mejor manera de comunicarnos.

== Gestión de las tareas ==
Para la gestión de tareas al principio hemos usado las hojas de '''Excel de Google Drive''' para la creación de las tareas y la asignaciones de cada una mediante una tabla que lleva las tareas y el nombre de la persona encargada de hacerla y luego pensamos en hacerlo con '''Trello''' de manera que dividimos el estado de las tareas en cuatro estados. En un apartado tenemos definidas todas las tareas que tiene que hacer cada uno, asignándola a cada miembro del grupo gracias a que Trello nos permite asignar tareas a miembros del grupo y también asignar la persona que se encargara de verificar la tarea, y cuando se empieza a trabajar sobre una tarea el miembro encargado lo pasa al estado "In progress" y cuando se termina de hacer la tarea lo pasa al estado "Verification" para que el miembro asignado a verificarla lo verifica y la pasa al estado "Done" y por últimos teníamos un apartado de enlaces útiles donde se pone informaciones útiles para la realización de las tareas.

== Entorno de desarrollo ==

=== Tecnologías y herramientas ===

El equipo de trabajo decidió usar como IDE '''Spring Tool Suite''' y hacer uso de las tecnologías y herramientas siguientes:

* '''Java 7'''
* '''Maven'''
* '''Tomcat 7'''
* '''MySQL'''
* '''Git'''
* '''AngularJS'''
* '''CSS3'''
* '''HTML5'''

=== Instalación de subsitema ===

Para la instalación de nuestro subsistema se deberá:
*Descargar el proyecto desde nuestro repositorio de GitHub
*Crear en MySQL una base de datos de nombre egc-frontend y un usuario user-frontend y contraseña us4r-front4nd con permiso para todas las acciones en la base de datos creada. Puede usarse para ello el siguiente código:

<code>
START TRANSACTION;
DROP DATABASE IF EXISTS `egc-frontend`;
CREATE DATABASE `egc-frontend`;
USE `egc-frontend`;
GRANT ALL ON `egc-frontend`.* TO 'user-frontend'@'localhost' IDENTIFIED BY 'us4r-front4nd';
COMMIT;
</code>

*Crear war del proyecto haciendo uso de maven, para ello hay que dirigirse a la raiz del proyeto y usar el comando mvn war:war
*Desplegar el war creado en un servidor de aplicaciones como por ejemplo TOMCAT 7.

=== Lecciones aprendidas ===

Dado que en el proyecto del año pasado se usaba AngularJS, hemos aprendido nociones básicas sobre este framework MVC para poder añadir algunas mejoras en la visualización de los resultados.
Por otra parte hemos aprendido que Spring tool suit es un IDE muy versátil y como de usar ya que viene configurado directamente para trabajar con proyectos maven, gestionar código con git y trabajar con spring.

== Gestión del código ==

Para la gestión del código se ha optado por Git y usaremos GitHub como servidor para alojar el código. A continuación se encuentra el enlace a nuestro repositorio de GitHub:

* https://github.com/AgoraUS-G2-1617/G28

A continuación detallaremos aspectos relacionados con la gestión del código en nuestro trabajo como pueden ser el ''usage model'', gestión de las ramas, aplicación de cambios, asignación de roles y políticas de nombre y estilo del código fuente.

==== Usage model y gestión de las ramas ====

[[Archivo:Usage model G28.png|thumb|alt=Alt|Usage model|upright=3]]

El modelo de uso que hemos seguido se basa en la creación de dos ramas principales, la rama ''master'' y la rama ''develop''.

En la rama ''master'' se decidió tener las versiones estables de nuestro proyecto. Por otro lado, cuando queramos seguir desarrollando la aplicación lo vamos a hacer en la rama ''develop''. Esta rama será donde llevaremos todos los cambios que vayamos a implementar nuevos en la aplicación. Una vez que los cambios en la rama ''develop'' estén validados por nosotros y lo creamos conveniente, lo pasaremos a la rama ''master''.

Por último, cada funcionalidad nueva se implementará en una rama local, las cuales no saldrán reflejadas, pero que están ahí. Una vez que terminemos una funcionalidad en un rama local, llamemos a la rama ''funcionalidad_1'', haremos una fusión (''merge'') con la rama ''develop'' y avisaremos de los cambios al equipo.

* [[Caso práctico: ''branch'' y ''commit''.]]

==== Aplicación de cambios y asignación de roles ====

A la hora de aplicar cambios o nuevas funcionalidades siempre hemos actuado de la misma manera. Cuando teníamos en nuestra rama local el cambio o la funcionalidad terminada, nos cambiábamos a la rama ''develop'' y hacíamos un ''merge'' con la rama que implementaba esa funcionalidad. En este caso, el encargado de hacer el ''merge'' a la rama ''develop'' será, obviamente, el mismo que implementó esa funcionalidad. Una vez puesto en ''develop'' el nuevo cambio, se avisaba al grupo, y decidíamos si queríamos meter algún cambio más en ''develop'' o si simplemente queríamos realizar el ''push'' a la rama ''master''.

No teníamos una persona encargada de realizar el ''push'' a la rama ''master'', simplemente se lo asignábamos al miembro del equipo que no lo había hecho hasta el momento, para que pudiera practicar con ''git''. Esto se eligió así para que todos pudiéramos tener la misma experiencia.

* [[Caso práctico: ''merge'' y ''push''.]]

==== Políticas de nombre y estilo del código fuente ====

Para el nuevo código fuente implementado(sin contar el ya existente) se han intentado seguir las siguiente políticas de estilo para el código:

* '''Nombres apropiados para las variables''': siempre hemos intentado usar nombres de variables para que no dificulten la lectura del código.
* '''Estilo de indentación más legible y espaciado para buena lectura del código'''.

== Gestión de incidencias ==

Todas las incidencias se deberán reportar en el apartado "Issues" de nuestro GitHub (https://github.com/AgoraUS-G2-1617/G28) y deberán de seguir el siguiente esquema:

* Titulo: Titulo descriptivo del problema
* Descripción: Detalles del problema
* Modulo: Módulo en el cuál se encuentra el posible código erróneo.
* Fecha: Ultima fecha en el cuál se modifico el código en el que se encuentra el problema.
* Pasos: Los pasos que se deben de seguir para reproducir el mismo problema en otra maquina distinta.
* Salida esperada: La salida (si es que sale algo) que nos da al ejecutar el código
* Salida real: La salida que nos devuelve el sistema.

El procedimiento a seguir para la creación y solución de incidencias será el siguiente:
La persona que encuentre algún problema en la aplicación será el responsable de crear la incidencia, una vez creada intentará resolverla, si no pudiera se lo comunicaría al grupo y se decidirá a que persona se le asignará dicha incidencia.
Una vez resuelto el problema otro miembro del grupo verificará que está resuelta y se cerrará la incidencia.

== Integración continua ==
===Jenkins===
La integración continua la gestionamos por medio de Jenkins y éste a su vez hace uso de Maven y muchas herramientas más para llevarla a cabo.
Disponemos en nuestra máquina virtual desplegadas dos versiones del sistema las cuales son posibles acceder mediante Internet gracias a que uno de nuestros miembros del grupo tiene configurado su router para redirigir el tráfico hacía estas:

* Beta: http://visualizacionagoraus1617.duckdns.org:8088/Frontend-Resultados-beta
* Stable: http://visualizacionagoraus1617.duckdns.org:8088/Frontend-Resultados-stable

Ahora mismo está configurado de tal manera que cuando Jenkins detecte algún cambio en el proyecto(push) desplegará el código que tengamos en nuestra rama develop automáticamente. Sin embargo, para actualizar lo que hay desplegado en la versión stable se hará de manera manual por siempre mantener estable la versión, y se actualizará con el consentimiento de todos los miembros, de esta manera, podremos tener el código desplegado de la rama master.

Para la configuración de las distintas fases (beta y stable) veremos los siguientes casos prácticos para entrar en detalle en la configuración.

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

===Travis===

Para la construcción continua también se hace uso de la herramienta Travis, cuando esta aplicación detecte un que se ha ejecutado un commit en GitHub lanzará los comando proporcionados en el fichero .travis.yml, y ejecutará los test del proyecto.
Así podemos automatizar la construcción y la ejecución de pruebas del sistema.

* [[Caso práctico: Integración de Travis con GitHub.]]

== Subsistemas relacionados ==

*Base de datos

== Diario del grupo ==

=== Actas ===

* [[Acta 01 - Creación y presentación del grupo (11/11/2016)]]
* [[Acta 02 - Reunión de grupo (21/11/2016)]]
* [[Acta 03 - Reunión de grupo (06/12/2016)]]
* [[Acta 04 - Reunión de grupo (12/12/2016)]]
* [[Acta 05 - Reunión de grupo (27/12/2016)]]
* [[Acta 06 - Reunión de grupo (09/01/2017)]]

=== Hoja de tiempos ===

* [[Hoja de tiempos - Visualización y gestión de resultados - 2016-2017]]

Visualización y Gestión de Resultados G28

2017-01-10T22:12:08Z

Alemurrod:

Visualización y Gestión de Resultados G28

2017-01-10T22:09:50Z

Alemurrod:

== Miembros del equipo ==

*[[Usuario:juacascor|Juan Antonio Castañeda Cortázar]] '''Coordinador - Ingeniero Software'''
*[[Usuario:alemurrod|Alejandro Murillo Rodríguez]] '''Coordinador - Ingeniero Software'''
*[[Usuario:abdche|Abdelkader Chellik]] '''Ingeniero Software'''
*[[Usuario:zaksah2|Zakaria Sahmoudi]] '''Ingeniero Software'''

== Definición del proyecto ==
Este proyecto trata del desarrollo del subsistema de Agora@US "Visualización y gestión de resultados". Nuestro grupo es el encargado de desarrollar el sistema de visualización, cuyo propósito es crear gráficas que muestren los resultados de las votaciones a partir de los datos obtenidos de los otros subsistemas.

== Código heredado ==

A continuación ofrecemos el siguiente enlace donde se encuentra el código del proyecto heredado en la plataforma GitHub:

* https://github.com/AgoraUS1516/G10

== Gestión de la comunicación ==

Para la buena comunicación entre los miembros del grupo nos hemos basado en herramientas como:
* '''Telegram''': lo hemos usado para comunicaciones cortas
* '''Hangouts''': para realizar reuniones telemáticas y nos dimos cuenta que no era tan eficaz porque no se entendía muy bien cuando se ponen a hablar más de dos personas y también había problemas de conexión
* '''Reuniones presenciales''': para nosotros ha sido la mejor manera de comunicarnos.

== Gestión de las tareas ==
Para la gestión de tareas al principio hemos usado las hojas de '''Excel de Google Drive''' para la creación de las tareas y la asignaciones de cada una mediante una tabla que lleva las tareas y el nombre de la persona encargada de hacerla y luego pensamos en hacerlo con '''Trello''' de manera que dividimos el estado de las tareas en cuatro estados. En un apartado tenemos definidas todas las tareas que tiene que hacer cada uno, asignándola a cada miembro del grupo gracias a que Trello nos permite asignar tareas a miembros del grupo y también asignar la persona que se encargara de verificar la tarea, y cuando se empieza a trabajar sobre una tarea el miembro encargado lo pasa al estado "In progress" y cuando se termina de hacer la tarea lo pasa al estado "Verification" para que el miembro asignado a verificarla lo verifica y la pasa al estado "Done" y por últimos teníamos un apartado de enlaces útiles donde se pone informaciones útiles para la realización de las tareas.

== Entorno de desarrollo ==

=== Tecnologías y herramientas ===

El equipo de trabajo decidió usar como IDE '''Spring Tool Suite''' y hacer uso de las tecnologías y herramientas siguientes:

* '''Java 7'''
* '''Maven'''
* '''Tomcat 7'''
* '''MySQL'''
* '''Git'''
* '''AngularJS'''
* '''CSS3'''
* '''HTML5'''

=== Instalación de subsitema ===

Para la instalación de nuestro subsistema se deberá:
*Descargar el proyecto desde nuestro repositorio de GitHub
*Crear en MySQL una base de datos de nombre egc-frontend y un usuario user-frontend y contraseña us4r-front4nd con permiso para todas las acciones en la base de datos creada. Puede usarse para ello el siguiente código:

<code>
START TRANSACTION;
DROP DATABASE IF EXISTS `egc-frontend`;
CREATE DATABASE `egc-frontend`;
USE `egc-frontend`;
GRANT ALL ON `egc-frontend`.* TO 'user-frontend'@'localhost' IDENTIFIED BY 'us4r-front4nd';
COMMIT;
</code>

*Crear war del proyecto haciendo uso de maven, para ello hay que dirigirse a la raiz del proyeto y usar el comando mvn war:war
*Desplegar el war creado en un servidor de aplicaciones como por ejemplo TOMCAT 7.

=== Lecciones aprendidas ===

Dado que en el proyecto del año pasado se usaba AngularJS, hemos aprendido nociones básicas sobre este framework MVC para poder añadir algunas mejoras en la visualización de los resultados.
Por otra parte hemos aprendido que Spring tool suit es un IDE muy versátil y como de usar ya que viene configurado directamente para trabajar con proyectos maven, gestionar código con git y trabajar con spring.

== Gestión del código ==

Para la gestión del código se ha optado por Git y usaremos GitHub como servidor para alojar el código. A continuación se encuentra el enlace a nuestro repositorio de GitHub:

* https://github.com/AgoraUS-G2-1617/G28

A continuación detallaremos aspectos relacionados con la gestión del código en nuestro trabajo como pueden ser el ''usage model'', gestión de las ramas, aplicación de cambios, asignación de roles y políticas de nombre y estilo del código fuente.

==== Usage model y gestión de las ramas ====

[[Archivo:Usage model G28.png|thumb|alt=Alt|Usage model|upright=3]]

El modelo de uso que hemos seguido se basa en la creación de dos ramas principales, la rama ''master'' y la rama ''develop''.

En la rama ''master'' se decidió tener las versiones estables de nuestro proyecto. Por otro lado, cuando queramos seguir desarrollando la aplicación lo vamos a hacer en la rama ''develop''. Esta rama será donde llevaremos todos los cambios que vayamos a implementar nuevos en la aplicación. Una vez que los cambios en la rama ''develop'' estén validados por nosotros y lo creamos conveniente, lo pasaremos a la rama ''master''.

Por último, cada funcionalidad nueva se implementará en una rama local, las cuales no saldrán reflejadas, pero que están ahí. Una vez que terminemos una funcionalidad en un rama local, llamemos a la rama ''funcionalidad_1'', haremos una fusión (''merge'') con la rama ''develop'' y avisaremos de los cambios al equipo.

* [[Caso práctico: ''branch'' y ''commit''.]]

==== Aplicación de cambios y asignación de roles ====

A la hora de aplicar cambios o nuevas funcionalidades siempre hemos actuado de la misma manera. Cuando teníamos en nuestra rama local el cambio o la funcionalidad terminada, nos cambiábamos a la rama ''develop'' y hacíamos un ''merge'' con la rama que implementaba esa funcionalidad. En este caso, el encargado de hacer el ''merge'' a la rama ''develop'' será, obviamente, el mismo que implementó esa funcionalidad. Una vez puesto en ''develop'' el nuevo cambio, se avisaba al grupo, y decidíamos si queríamos meter algún cambio más en ''develop'' o si simplemente queríamos realizar el ''push'' a la rama ''master''.

No teníamos una persona encargada de realizar el ''push'' a la rama ''master'', simplemente se lo asignábamos al miembro del equipo que no lo había hecho hasta el momento, para que pudiera practicar con ''git''. Esto se eligió así para que todos pudiéramos tener la misma experiencia.

* [[Caso práctico: ''merge'' y ''push''.]]

==== Políticas de nombre y estilo del código fuente ====

Para el nuevo código fuente implementado(sin contar el ya existente) se han intentado seguir las siguiente políticas de estilo para el código:

* '''Nombres apropiados para las variables''': siempre hemos intentado usar nombres de variables para que no dificulten la lectura del código.
* '''Estilo de indentación más legible y espaciado para buena lectura del código'''.

== Gestión de incidencias ==

Todas las incidencias se deberán reportar en el apartado "Issues" de nuestro GitHub (https://github.com/AgoraUS-G2-1617/G28) y deberán de seguir el siguiente esquema:

* Titulo: Titulo descriptivo del problema
* Descripción: Detalles del problema
* Modulo: Módulo en el cuál se encuentra el posible código erróneo.
* Fecha: Ultima fecha en el cuál se modifico el código en el que se encuentra el problema.
* Pasos: Los pasos que se deben de seguir para reproducir el mismo problema en otra maquina distinta.
* Salida esperada: La salida (si es que sale algo) que nos da al ejecutar el código
* Salida real: La salida que nos devuelve el sistema.

El procedimiento a seguir para la creación y solución de incidencias será el siguiente:
La persona que encuentre algún problema en la aplicación será el responsable de crear la incidencia, una vez creada intentará resolverla, si no pudiera se lo comunicaría al grupo y se decidirá a que persona se le asignará dicha incidencia.
Una vez resuelto el problema otro miembro del grupo verificará que está resuelta y se cerrará la incidencia.

== Integración continua ==
===Jenkins===
La integración continua la gestionamos por medio de Jenkins y éste a su vez hace uso de Maven y muchas herramientas más para llevarla a cabo.
Disponemos en nuestra máquina virtual desplegadas dos versiones del sistema las cuales son posibles acceder mediante Internet gracias a que uno de nuestros miembros del grupo tiene configurado su router para redirigir el tráfico hacía estas:
* Beta: http://visualizacionagoraus1617.duckdns.org:8088/Frontend-Resultados-beta
* Stable: http://visualizacionagoraus1617.duckdns.org:8088/Frontend-Resultados-stable

Ahora mismo está configurado de tal manera que cuando Jenkins detecte algún cambio en el proyecto(push) desplegará el código que tengamos en nuestra rama develop automáticamente. Sin embargo, para actualizar lo que hay desplegado en la versión stable se hará de manera manual por siempre mantener estable la versión, y se actualizará con el consentimiento de todos los miembros, de esta manera, podremos tener el código desplegado de la rama master.

Para la configuración de las distintas fases (beta y stable) veremos los siguientes casos prácticos para entrar en detalle en la configuración.

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

===Travis===

Para la construcción continua también se hace uso de la herramienta Travis, cuando esta aplicación detecte un que se ha ejecutado un commit en GitHub lanzará los comando proporcionados en el fichero .travis.yml, y ejecutará los test del proyecto.
Así podemos automatizar la construcción y la ejecución de pruebas del sistema.

* [[Caso práctico: Integración de Travis con GitHub.]]

== Subsistemas relacionados ==

*Base de datos

== Diario del grupo ==

=== Actas ===

* [[Acta 01 - Creación y presentación del grupo (11/11/2016)]]
* [[Acta 02 - Reunión de grupo (21/11/2016)]]
* [[Acta 03 - Reunión de grupo (06/12/2016)]]
* [[Acta 04 - Reunión de grupo (12/12/2016)]]
* [[Acta 05 - Reunión de grupo (27/12/2016)]]
* [[Acta 06 - Reunión de grupo (09/01/2017)]]

=== Hoja de tiempos ===

* [[Hoja de tiempos - Visualización y gestión de resultados - 2016-2017]]

Visualización y Gestión de Resultados G28

2017-01-10T20:09:21Z

Alemurrod:

== Miembros del equipo ==

*[[Usuario:juacascor|Juan Antonio Castañeda Cortázar]] '''Coordinador - Ingeniero Software'''
*[[Usuario:alemurrod|Alejandro Murillo Rodríguez]] '''Coordinador - Ingeniero Software'''
*[[Usuario:abdche|Abdelkader Chellik]] '''Ingeniero Software'''
*[[Usuario:zaksah2|Zakaria Sahmoudi]] '''Ingeniero Software'''

== Definición del proyecto ==
Este proyecto trata del desarrollo del subsistema de Agora@US "Visualización y gestión de resultados". Nuestro grupo es el encargado de desarrollar el sistema de visualización, cuyo propósito es crear gráficas que muestren los resultados de las votaciones a partir de los datos obtenidos de los otros subsistemas.

== Código heredado ==

A continuación ofrecemos el siguiente enlace donde se encuentra el código del proyecto heredado en la plataforma GitHub:

* https://github.com/AgoraUS1516/G10

== Gestión de la comunicación ==

Para la buena comunicación entre los miembros del grupo nos hemos basado en herramientas como:
* '''Telegram''': lo hemos usado para comunicaciones cortas
* '''Hangouts''': para realizar reuniones telemáticas y nos dimos cuenta que no era tan eficaz porque no se entendía muy bien cuando se ponen a hablar más de dos personas y también había problemas de conexión
* '''Reuniones presenciales''': para nosotros ha sido la mejor manera de comunicarnos.

== Gestión de las tareas ==
Para la gestión de tareas al principio hemos usado las hojas de '''Excel de Google Drive''' para la creación de las tareas y la asignaciones de cada una mediante una tabla que lleva las tareas y el nombre de la persona encargada de hacerla y luego pensamos en hacerlo con '''Trello''' de manera que dividimos el estado de las tareas en cuatro estados. En un apartado tenemos definidas todas las tareas que tiene que hacer cada uno, asignándola a cada miembro del grupo gracias a que Trello nos permite asignar tareas a miembros del grupo y también asignar la persona que se encargara de verificar la tarea, y cuando se empieza a trabajar sobre una tarea el miembro encargado lo pasa al estado "In progress" y cuando se termina de hacer la tarea lo pasa al estado "Verification" para que el miembro asignado a verificarla lo verifica y la pasa al estado "Done" y por últimos teníamos un apartado de enlaces útiles donde se pone informaciones útiles para la realización de las tareas.

== Entorno de desarrollo ==

=== Tecnologías y herramientas ===

El equipo de trabajo decidió usar como IDE '''Spring Tool Suite''' y hacer uso de las tecnologías y herramientas siguientes:

* '''Java 7'''
* '''Maven'''
* '''Tomcat 7'''
* '''MySQL'''
* '''Git'''
* '''AngularJS'''
* '''CSS3'''
* '''HTML5'''

=== Instalación de subsitema ===

Para la instalación de nuestro subsistema se deberá:
*Descargar el proyecto desde nuestro repositorio de GitHub
*Crear en MySQL una base de datos de nombre egc-frontend y un usuario user-frontend y contraseña us4r-front4nd con permiso para todas las acciones en la base de datos creada. Puede usarse para ello el siguiente código:

<code>
START TRANSACTION;
DROP DATABASE IF EXISTS `egc-frontend`;
CREATE DATABASE `egc-frontend`;
USE `egc-frontend`;
GRANT ALL ON `egc-frontend`.* TO 'user-frontend'@'localhost' IDENTIFIED BY 'us4r-front4nd';
COMMIT;
</code>

*Crear war del proyecto haciendo uso de maven, para ello hay que dirigirse a la raiz del proyeto y usar el comando mvn war:war
*Desplegar el war creado en un servidor de aplicaciones como por ejemplo TOMCAT 7.

=== Lecciones aprendidas ===

Dado que en el proyecto del año pasado se usaba AngularJS, hemos aprendido nociones básicas sobre este framework MVC para poder añadir algunas mejoras en la visualización de los resultados.
Por otra parte hemos aprendido que Spring tool suit es un IDE muy versátil y como de usar ya que viene configurado directamente para trabajar con proyectos maven, gestionar código con git y trabajar con spring.

== Gestión del código ==

Para la gestión del código se ha optado por Git y usaremos GitHub como servidor para alojar el código. A continuación se encuentra el enlace a nuestro repositorio de GitHub:

* https://github.com/AgoraUS-G2-1617/G28

A continuación detallaremos aspectos relacionados con la gestión del código en nuestro trabajo como pueden ser el ''usage model'', gestión de las ramas, aplicación de cambios, asignación de roles y políticas de nombre y estilo del código fuente.

==== Usage model y gestión de las ramas ====

[[Archivo:Usage model G28.png|thumb|alt=Alt|Usage model|upright=3]]

El modelo de uso que hemos seguido se basa en la creación de dos ramas principales, la rama ''master'' y la rama ''develop''.

En la rama ''master'' se decidió tener las versiones estables de nuestro proyecto. Por otro lado, cuando queramos seguir desarrollando la aplicación lo vamos a hacer en la rama ''develop''. Esta rama será donde llevaremos todos los cambios que vayamos a implementar nuevos en la aplicación. Una vez que los cambios en la rama ''develop'' estén validados por nosotros y lo creamos conveniente, lo pasaremos a la rama ''master''.

Por último, cada funcionalidad nueva se implementará en una rama local, las cuales no saldrán reflejadas, pero que están ahí. Una vez que terminemos una funcionalidad en un rama local, llamemos a la rama ''funcionalidad_1'', haremos una fusión (''merge'') con la rama ''develop'' y avisaremos de los cambios al equipo.

* [[Caso práctico: ''branch'' y ''commit''.]]

==== Aplicación de cambios y asignación de roles ====

A la hora de aplicar cambios o nuevas funcionalidades siempre hemos actuado de la misma manera. Cuando teníamos en nuestra rama local el cambio o la funcionalidad terminada, nos cambiábamos a la rama ''develop'' y hacíamos un ''merge'' con la rama que implementaba esa funcionalidad. En este caso, el encargado de hacer el ''merge'' a la rama ''develop'' será, obviamente, el mismo que implementó esa funcionalidad. Una vez puesto en ''develop'' el nuevo cambio, se avisaba al grupo, y decidíamos si queríamos meter algún cambio más en ''develop'' o si simplemente queríamos realizar el ''push'' a la rama ''master''.

No teníamos una persona encargada de realizar el ''push'' a la rama ''master'', simplemente se lo asignábamos al miembro del equipo que no lo había hecho hasta el momento, para que pudiera practicar con ''git''. Esto se eligió así para que todos pudiéramos tener la misma experiencia.

* [[Caso práctico: ''merge'' y ''push''.]]

==== Políticas de nombre y estilo del código fuente ====

Para el nuevo código fuente implementado(sin contar el ya existente) se han intentado seguir las siguiente políticas de estilo para el código:

* '''Nombres apropiados para las variables''': siempre hemos intentado usar nombres de variables para que no dificulten la lectura del código.
* '''Estilo de indentación más legible y espaciado para buena lectura del código'''.

== Gestión de incidencias ==

Todas las incidencias se deberán reportar en el apartado "Issues" de nuestro GitHub (https://github.com/AgoraUS-G2-1617/G28) y deberán de seguir el siguiente esquema:

* Titulo: Titulo descriptivo del problema
* Descripción: Detalles del problema
* Modulo: Módulo en el cuál se encuentra el posible código erróneo.
* Fecha: Ultima fecha en el cuál se modifico el código en el que se encuentra el problema.
* Pasos: Los pasos que se deben de seguir para reproducir el mismo problema en otra maquina distinta.
* Salida esperada: La salida (si es que sale algo) que nos da al ejecutar el código
* Salida real: La salida que nos devuelve el sistema.

El procedimiento a seguir para la creación y solución de incidencias será el siguiente:
La persona que encuentre algún problema en la aplicación será el responsable de crear la incidencia, una vez creada intentará resolverla, si no pudiera se lo comunicaría al grupo y se decidirá a que persona se le asignará dicha incidencia.
Una vez resuelto el problema otro miembro del grupo verificará que está resuelta y se cerrará la incidencia.

== Subsistemas relacionados ==

*Base de datos

== Diario del grupo ==

=== Actas ===

* [[Acta 01 - Creación y presentación del grupo (11/11/2016)]]
* [[Acta 02 - Reunión de grupo (21/11/2016)]]
* [[Acta 03 - Reunión de grupo (06/12/2016)]]
* [[Acta 04 - Reunión de grupo (12/12/2016)]]
* [[Acta 05 - Reunión de grupo (27/12/2016)]]
* [[Acta 06 - Reunión de grupo (09/01/2017)]]

=== Hoja de tiempos ===

* [[Hoja de tiempos - Visualización y gestión de resultados - 2016-2017]]

Visualización y Gestión de Resultados G28

2017-01-10T20:05:43Z

Alemurrod:

== Miembros del equipo ==

*[[Usuario:juacascor|Juan Antonio Castañeda Cortázar]] '''Coordinador - Ingeniero Software'''
*[[Usuario:alemurrod|Alejandro Murillo Rodríguez]] '''Coordinador - Ingeniero Software'''
*[[Usuario:abdche|Abdelkader Chellik]] '''Ingeniero Software'''
*[[Usuario:zaksah2|Zakaria Sahmoudi]] '''Ingeniero Software'''

== Definición del proyecto ==
Este proyecto trata del desarrollo del subsistema de Agora@US "Visualización y gestión de resultados". Nuestro grupo es el encargado de desarrollar el sistema de visualización, cuyo propósito es crear gráficas que muestren los resultados de las votaciones a partir de los datos obtenidos de los otros subsistemas.

== Código heredado ==

A continuación ofrecemos el siguiente enlace donde se encuentra el código del proyecto heredado en la plataforma GitHub:

* https://github.com/AgoraUS1516/G10

== Gestión de la comunicación ==

Para la buena comunicación entre los miembros del grupo nos hemos basado en herramientas como:
* '''Telegram''': lo hemos usado para comunicaciones cortas
* '''Hangouts''': para realizar reuniones telemáticas y nos dimos cuenta que no era tan eficaz porque no se entendía muy bien cuando se ponen a hablar más de dos personas y también había problemas de conexión
* '''Reuniones presenciales''': para nosotros ha sido la mejor manera de comunicarnos.

== Gestión de las tareas ==
Para la gestión de tareas al principio hemos usado las hojas de '''Excel de Google Drive''' para la creación de las tareas y la asignaciones de cada una mediante una tabla que lleva las tareas y el nombre de la persona encargada de hacerla y luego pensamos en hacerlo con '''Trello''' de manera que dividimos el estado de las tareas en cuatro estados. En un apartado tenemos definidas todas las tareas que tiene que hacer cada uno, asignándola a cada miembro del grupo gracias a que Trello nos permite asignar tareas a miembros del grupo y también asignar la persona que se encargara de verificar la tarea, y cuando se empieza a trabajar sobre una tarea el miembro encargado lo pasa al estado "In progress" y cuando se termina de hacer la tarea lo pasa al estado "Verification" para que el miembro asignado a verificarla lo verifica y la pasa al estado "Done" y por últimos teníamos un apartado de enlaces útiles donde se pone informaciones útiles para la realización de las tareas.

== Entorno de desarrollo ==

=== Tecnologías y herramientas ===

El equipo de trabajo decidió usar como IDE '''Spring Tool Suite''' y hacer uso de las tecnologías y herramientas siguientes:

* '''Java 7'''
* '''Maven'''
* '''Tomcat 7'''
* '''MySQL'''
* '''Git'''
* '''AngularJS'''
* '''CSS3'''
* '''HTML5'''

=== Instalación de subsitema ===

Para la instalación de nuestro subsistema se deberá:
*Descargar el proyecto desde nuestro repositorio de GitHub
*Crear en MySQL una base de datos de nombre egc-frontend y un usuario user-frontend y contraseña us4r-front4nd con permiso para todas las acciones en la base de datos creada. Puede usarse para ello el siguiente código:

<code>
START TRANSACTION;
DROP DATABASE IF EXISTS `egc-frontend`;
CREATE DATABASE `egc-frontend`;
USE `egc-frontend`;
GRANT ALL ON `egc-frontend`.* TO 'user-frontend'@'localhost' IDENTIFIED BY 'us4r-front4nd';
COMMIT;
</code>

*Crear war del proyecto haciendo uso de maven, para ello hay que dirigirse a la raiz del proyeto y usar el comando mvn war:war
*Desplegar el war creado en un servidor de aplicaciones como por ejemplo TOMCAT 7.

=== Lecciones aprendidas ===

Dado que en el proyecto del año pasado se usaba AngularJS, hemos aprendido nociones básicas sobre este framework MVC para poder añadir algunas mejoras en la visualización de los resultados.
Por otra parte hemos aprendido que Spring tool suit es un IDE muy versátil y como de usar ya que viene configurado directamente para trabajar con proyectos maven, gestionar código con git y trabajar con spring.

== Gestión del código ==

Para la gestión del código se ha optado por Git y usaremos GitHub como servidor para alojar el código. A continuación se encuentra el enlace a nuestro repositorio de GitHub:

* https://github.com/AgoraUS-G2-1617/G28

A continuación detallaremos aspectos relacionados con la gestión del código en nuestro trabajo como pueden ser el ''usage model'', gestión de las ramas, aplicación de cambios, asignación de roles y políticas de nombre y estilo del código fuente.

==== Usage model y gestión de las ramas ====

[[Archivo:Usage model G28.png|thumb|alt=Alt|Usage model|upright=3]]

El modelo de uso que hemos seguido se basa en la creación de dos ramas principales, la rama ''master'' y la rama ''develop''.

En la rama ''master'' se decidió tener las versiones estables de nuestro proyecto. Por otro lado, cuando queramos seguir desarrollando la aplicación lo vamos a hacer en la rama ''develop''. Esta rama será donde llevaremos todos los cambios que vayamos a implementar nuevos en la aplicación. Una vez que los cambios en la rama ''develop'' estén validados por nosotros y lo creamos conveniente, lo pasaremos a la rama ''master''.

Por último, cada funcionalidad nueva se implementará en una rama local, las cuales no saldrán reflejadas, pero que están ahí. Una vez que terminemos una funcionalidad en un rama local, llamemos a la rama ''funcionalidad_1'', haremos una fusión (''merge'') con la rama ''develop'' y avisaremos de los cambios al equipo.

* [[Caso práctico: ''branch'' y ''commit''.]]

==== Aplicación de cambios y asignación de roles ====

A la hora de aplicar cambios o nuevas funcionalidades siempre hemos actuado de la misma manera. Cuando teníamos en nuestra rama local el cambio o la funcionalidad terminada, nos cambiábamos a la rama ''develop'' y hacíamos un ''merge'' con la rama que implementaba esa funcionalidad. En este caso, el encargado de hacer el ''merge'' a la rama ''develop'' será, obviamente, el mismo que implementó esa funcionalidad. Una vez puesto en ''develop'' el nuevo cambio, se avisaba al grupo, y decidíamos si queríamos meter algún cambio más en ''develop'' o si simplemente queríamos realizar el ''push'' a la rama ''master''.

No teníamos una persona encargada de realizar el ''push'' a la rama ''master'', simplemente se lo asignábamos al miembro del equipo que no lo había hecho hasta el momento, para que pudiera practicar con ''git''. Esto se eligió así para que todos pudiéramos tener la misma experiencia.

* [[Caso práctico: ''merge'' y ''push''.]]

==== Políticas de nombre y estilo del código fuente ====

Para el nuevo código fuente implementado(sin contar el ya existente) se han intentado seguir las siguiente políticas de estilo para el código:

* '''Nombres apropiados para las variables''': siempre hemos intentado usar nombres de variables para que no dificulten la lectura del código.
* '''Estilo de indentación más legible y espaciado para buena lectura del código'''.

== Gestión de incidencias ==

Todas las incidencias se deberán reportar en el apartado "Issues" de nuestro GitHub (https://github.com/AgoraUS-G2-1617/G28) y deberán de seguir el siguiente esquema:

* Titulo: Titulo descriptivo del problema
* Descripción: Detalles del problema
* Modulo: Módulo en el cuál se encuentra el posible código erróneo.
* Fecha: Ultima fecha en el cuál se modifico el código en el que se encuentra el problema.
* Pasos: Los pasos que se deben de seguir para reproducir el mismo problema en otra maquina distinta.
* Salida esperada: La salida (si es que sale algo) que nos da al ejecutar el código
* Salida real: La salida que nos devuelve el sistema.

El procedimiento a seguir para la creación y solución de incidencias será el siguiente:
La persona que encuentre algún problema en la aplicación será el responsable de crear la incidencia, una vez creada intentará resolverla, si no pudiera se lo comunicaría al grupo y se decidirá a que persona se le asignará dicha incidencia.
Una vez resuelto el problema otro miembro del grupo verificará que está resuelta y se cerrará la incidencia.

== Subsistemas relacionados ==

*Base de datos

== Diario del equipo ==

=== Actas ===

* [[Acta 01 - Creación y presentación del grupo (11/11/2016)]]
* [[Acta 02 - Reunión de grupo (21/11/2016)]]
* [[Acta 03 - Reunión de grupo (06/12/2016)]]
* [[Acta 04 - Reunión de grupo (12/12/2016)]]
* [[Acta 05 - Reunión de grupo (27/12/2016)]]
* [[Acta 06 - Reunión de grupo (09/01/2017)]]

=== Hoja de tiempos ===

* [[Hoja de tiempos - Visualización y gestión de resultados - 2016-2017]]

Visualización y Gestión de Resultados G28

2017-01-10T20:05:16Z

Alemurrod:

== Miembros del equipo ==

*[[Usuario:juacascor|Juan Antonio Castañeda Cortázar]] '''Coordinador - Ingeniero Software'''
*[[Usuario:alemurrod|Alejandro Murillo Rodríguez]] '''Coordinador - Ingeniero Software'''
*[[Usuario:abdche|Abdelkader Chellik]] '''Ingeniero Software'''
*[[Usuario:zaksah2|Zakaria Sahmoudi]] '''Ingeniero Software'''

== Definición del proyecto ==
Este proyecto trata del desarrollo del subsistema de Agora@US "Visualización y gestión de resultados". Nuestro grupo es el encargado de desarrollar el sistema de visualización, cuyo propósito es crear gráficas que muestren los resultados de las votaciones a partir de los datos obtenidos de los otros subsistemas.

== Código heredado ==

A continuación ofrecemos el siguiente enlace donde se encuentra el código del proyecto heredado en la plataforma GitHub:

* https://github.com/AgoraUS1516/G10

== Gestión de la comunicación ==

Para la buena comunicación entre los miembros del grupo nos hemos basado en herramientas como:
* '''Telegram''': lo hemos usado para comunicaciones cortas
* '''Hangouts''': para realizar reuniones telemáticas y nos dimos cuenta que no era tan eficaz porque no se entendía muy bien cuando se ponen a hablar más de dos personas y también había problemas de conexión
* '''Reuniones presenciales''': para nosotros ha sido la mejor manera de comunicarnos.

== Gestión de las tareas ==
Para la gestión de tareas al principio hemos usado las hojas de '''Excel de Google Drive''' para la creación de las tareas y la asignaciones de cada una mediante una tabla que lleva las tareas y el nombre de la persona encargada de hacerla y luego pensamos en hacerlo con '''Trello''' de manera que dividimos el estado de las tareas en cuatro estados. En un apartado tenemos definidas todas las tareas que tiene que hacer cada uno, asignándola a cada miembro del grupo gracias a que Trello nos permite asignar tareas a miembros del grupo y también asignar la persona que se encargara de verificar la tarea, y cuando se empieza a trabajar sobre una tarea el miembro encargado lo pasa al estado "In progress" y cuando se termina de hacer la tarea lo pasa al estado "Verification" para que el miembro asignado a verificarla lo verifica y la pasa al estado "Done" y por últimos teníamos un apartado de enlaces útiles donde se pone informaciones útiles para la realización de las tareas.

== Entorno de desarrollo ==

=== Tecnologías y herramientas ===

El equipo de trabajo decidió usar como IDE '''Spring Tool Suite''' y hacer uso de las tecnologías y herramientas siguientes:

* '''Java 7'''
* '''Maven'''
* '''Tomcat 7'''
* '''MySQL'''
* '''Git'''
* '''AngularJS'''
* '''CSS3'''
* '''HTML5'''

=== Instalación de subsitema ===

Para la instalación de nuestro subsistema se deberá:
*Descargar el proyecto desde nuestro repositorio de GitHub
*Crear en MySQL una base de datos de nombre egc-frontend y un usuario user-frontend y contraseña us4r-front4nd con permiso para todas las acciones en la base de datos creada. Puede usarse para ello el siguiente código:

<code>
START TRANSACTION;
DROP DATABASE IF EXISTS `egc-frontend`;
CREATE DATABASE `egc-frontend`;
USE `egc-frontend`;
GRANT ALL ON `egc-frontend`.* TO 'user-frontend'@'localhost' IDENTIFIED BY 'us4r-front4nd';
COMMIT;
</code>

*Crear war del proyecto haciendo uso de maven, para ello hay que dirigirse a la raiz del proyeto y usar el comando mvn war:war
*Desplegar el war creado en un servidor de aplicaciones como por ejemplo TOMCAT 7.

=== Lecciones aprendidas ===

Dado que en el proyecto del año pasado se usaba AngularJS, hemos aprendido nociones básicas sobre este framework MVC para poder añadir algunas mejoras en la visualización de los resultados.
Por otra parte hemos aprendido que Spring tool suit es un IDE muy versátil y como de usar ya que viene configurado directamente para trabajar con proyectos maven, gestionar código con git y trabajar con spring.

== Gestión del código ==

Para la gestión del código se ha optado por Git y usaremos GitHub como servidor para alojar el código. A continuación se encuentra el enlace a nuestro repositorio de GitHub:

* https://github.com/AgoraUS-G2-1617/G28

A continuación detallaremos aspectos relacionados con la gestión del código en nuestro trabajo como pueden ser el ''usage model'', gestión de las ramas, aplicación de cambios, asignación de roles y políticas de nombre y estilo del código fuente.

==== Usage model y gestión de las ramas ====

[[Archivo:Usage model G28.png|thumb|alt=Alt|Usage model|upright=3]]

El modelo de uso que hemos seguido se basa en la creación de dos ramas principales, la rama ''master'' y la rama ''develop''.

En la rama ''master'' se decidió tener las versiones estables de nuestro proyecto. Por otro lado, cuando queramos seguir desarrollando la aplicación lo vamos a hacer en la rama ''develop''. Esta rama será donde llevaremos todos los cambios que vayamos a implementar nuevos en la aplicación. Una vez que los cambios en la rama ''develop'' estén validados por nosotros y lo creamos conveniente, lo pasaremos a la rama ''master''.

Por último, cada funcionalidad nueva se implementará en una rama local, las cuales no saldrán reflejadas, pero que están ahí. Una vez que terminemos una funcionalidad en un rama local, llamemos a la rama ''funcionalidad_1'', haremos una fusión (''merge'') con la rama ''develop'' y avisaremos de los cambios al equipo.

* [[Caso práctico: ''branch'' y ''commit''.]]

==== Aplicación de cambios y asignación de roles ====

A la hora de aplicar cambios o nuevas funcionalidades siempre hemos actuado de la misma manera. Cuando teníamos en nuestra rama local el cambio o la funcionalidad terminada, nos cambiábamos a la rama ''develop'' y hacíamos un ''merge'' con la rama que implementaba esa funcionalidad. En este caso, el encargado de hacer el ''merge'' a la rama ''develop'' será, obviamente, el mismo que implementó esa funcionalidad. Una vez puesto en ''develop'' el nuevo cambio, se avisaba al grupo, y decidíamos si queríamos meter algún cambio más en ''develop'' o si simplemente queríamos realizar el ''push'' a la rama ''master''.

No teníamos una persona encargada de realizar el ''push'' a la rama ''master'', simplemente se lo asignábamos al miembro del equipo que no lo había hecho hasta el momento, para que pudiera practicar con ''git''. Esto se eligió así para que todos pudiéramos tener la misma experiencia.

* [[Caso práctico: ''merge'' y ''push''.]]

==== Políticas de nombre y estilo del código fuente ====

Para el nuevo código fuente implementado(sin contar el ya existente) se han intentado seguir las siguiente políticas de estilo para el código:

* '''Nombres apropiados para las variables''': siempre hemos intentado usar nombres de variables para que no dificulten la lectura del código.
* '''Estilo de indentación más legible y espaciado para buena lectura del código'''.

== Gestión de incidencias ==

Todas las incidencias se deberán reportar en el apartado "Issues" de nuestro GitHub (https://github.com/AgoraUS-G2-1617/G28) y deberán de seguir el siguiente esquema:

* Titulo: Titulo descriptivo del problema
* Descripción: Detalles del problema
* Modulo: Módulo en el cuál se encuentra el posible código erróneo.
* Fecha: Ultima fecha en el cuál se modifico el código en el que se encuentra el problema.
* Pasos: Los pasos que se deben de seguir para reproducir el mismo problema en otra maquina distinta.
* Salida esperada: La salida (si es que sale algo) que nos da al ejecutar el código
* Salida real: La salida que nos devuelve el sistema.

El procedimiento a seguir para la creación y solución de incidencias será el siguiente:
La persona que encuentre algún problema en la aplicación será el responsable de crear la incidencia, una vez creada intentará resolverla, si no pudiera se lo comunicaría al grupo y se decidirá a que persona se le asignará dicha incidencia.
Una vez resuelto el problema otro miembro del grupo verificará que está resuelta y se cerrará la incidencia.

== Subsistemas relacionados ==

*Base de datos

== Diario del equipo ==

=== Actas ===

* [[Acta 01 - Creación y presentación del grupo (11/11/2016)]]
* [[Acta 02 - Reunión de grupo (21/11/2016)]]
* [[Acta 03 - Reunión de grupo (06/12/2016)]]
* [[Acta 04 - Reunión de grupo (12/12/2016)]]
* [[Acta 05 - Reunión de grupo (27/12/2016)]]
* [[Acta 06 - Reunión de grupo (09/01/2017)]]

=== Hoja de tiempos ===

* [[Hoja de tiempos - Visualización y gestión de resultados - 2016-2017]]