Subsistemas Frontend y Visualización · 22/12/2015 1.6.1 Cambiado la resolución del ejercicio...
70
Subsistemas Frontend y Visualización Evolución y Gestión de la Configuración Grado de Ingeniería del Software Número de grupo (Opera): 10 Tutor: David Benavides Enlace de proyecto en projETSII: https://projetsii.informatica.us.es/projects/t6xqetftwntyzke2yd4 Enlace wiki: https://1984.lsi.us.es/wiki- egc/index.php/Frontend_y_visualizaci%C3%B3n_de_resultados
Transcript of Subsistemas Frontend y Visualización · 22/12/2015 1.6.1 Cambiado la resolución del ejercicio...
Subsistemas
Frontend y Visualización
Evolución y Gestión de la Configuración
Grado de Ingeniería del Software
Número de grupo (Opera): 10
Tutor: David Benavides
Enlace de proyecto en projETSII:
https://projetsii.informatica.us.es/projects/t6xqetftwntyzke2yd4
Enlace wiki:
https://1984.lsi.us.es/wiki-
egc/index.php/Frontend_y_visualizaci%C3%B3n_de_resultados
2
AUTOEVALUACIÓN
Dedicación en el proyecto en cada uno de los entregables.
Alumno Entregable 1 Entregable 2 Final
Barquero Sauci, Valentín %
Bellido Millán, Miguel A. %
Llamas García, Moisés %
Martín Rodrigo, Daniel %
Sánchez Navarro, Daniel %
0% = No he podido participar en este entregable.
25% = He trabajado algo aunque no demasiado.
50% = He trabajado aproximadamente la mitad que mis compañeros.
75% = He trabajado bastante pero podría haberle dedicado más tiempo.
100% = He trabajado como el que más.
3
HISTORIAL DE VERSIONES
Fecha Versión Detalles Participantes
27/11/2015 1.0.0 Versión inicial
Daniel Martín Rodrigo
16/12/2015 1.1.0 Realizado la introducción Moisés Llamas García
16/12/2015 1.2.0 Realización del mapa de herramientas Miguel Ángel Bellido Millán
17/12/2015 1.3.0 Realizado resumen y la gestión de cambios, incidencias y depuración.
Moisés Llamas García
18/12/2015 1.4.0 Realizado gestión del código fuente Moisés Llamas García
20/12/2015 1.5.0 Realizados la descripción técnica y los elementos de control
Valentín Barquero Saucí
21/12/2015 1.6.0 Realizado el entorno de desarrollo Moisés Llamas García
22/12/2015 1.6.1 Cambiado la resolución del ejercicio sobre la gestión del código fuente
Moisés Llamas García
22/12/2015 1.7.0 Añadido la gestión de liberaciones, despliegue y entregas
Daniel Martín Rodrigo
23/12/2015 1.7.1 Añadido la descripción sobre Angular Daniel Sánchez Navarro
24/12/2015 1.7.2 Cambiada la imagen del mapa de herramientas
Miguel Ángel Bellido Millán
25/12/2015 1.8.0 Añadida gestión de la construcción e integración continua
Daniel Martín Rodrigo
26/12/2015 1.8.1 Revisión final y cambios menores en formato Daniel Martín Rodrigo
4
Índice General
1 Resumen ................................................................................................................... 9
2 Introducción ............................................................................................................ 10
2.1 Qué es Agora@US ............................................................................................ 10
2.2 Frontend y Visualización de resultados ........................................................... 11
2.3 Tecnología ........................................................................................................ 11
3 Relación de Hitos .................................................................................................... 12
4 Descripción del sistema .......................................................................................... 12
4.1 Estado anterior ................................................................................................ 12
4.2 Cambios que se proponen ............................................................................... 14
4.3 Cambios de AngularJS ...................................................................................... 16
4.4 Historias de usuario ......................................................................................... 18
5 Elementos de control .............................................................................................. 20
5.1 Gestión del cambio para componentes ........................................................... 21
6 Entorno de Desarrollo ............................................................................................ 22
6.1 Máquina Virtual ............................................................................................... 22
6.2 Java ................................................................................................................... 22
6.3 Eclipse .............................................................................................................. 23
6.4 Maven .............................................................................................................. 23
6.5 EGit ................................................................................................................... 25
6.6 MySQL .............................................................................................................. 27
6.7 Tomcat ............................................................................................................. 28
7 Gestión del código fuente ...................................................................................... 30
7.1 Gestores de proyectos ..................................................................................... 30
7.2 Gestión del código ........................................................................................... 30
7.3 Procedimientos para trabajar con el control de versiones ............................. 31
7.3.1 Pautas para realizar un commit ................................................................ 31
7.3.2 Pautas a la hora de crear una incidencia .................................................. 32
7.3.3 Gestión de conflictos ................................................................................ 32
7.4 Roles ................................................................................................................. 32
7.5 Sintaxis del código fuente ................................................................................ 33
5
7.6 Ejercicio ............................................................................................................ 34
7.6.1 Enunciado ................................................................................................. 34
7.6.2 Solución .................................................................................................... 34
8 Gestión de la construcción e integración continua ............................................... 40
8.1 Procedimientos ................................................................................................ 40
8.2 Implementación ............................................................................................... 40
8.3 Caso Práctico 1 ................................................................................................. 46
8.3.1 Enunciado ................................................................................................. 46
8.3.2 Solución .................................................................................................... 46
8.4 Caso Práctico 2 ................................................................................................. 49
8.4.1 Enunciado ................................................................................................. 49
8.4.2 Solución .................................................................................................... 49
8.5 Caso Práctico 3 ................................................................................................. 51
8.5.1 Enunciado ................................................................................................. 51
8.5.2 Solución .................................................................................................... 51
9 Gestión del cambio, incidencias y depuración ...................................................... 53
9.1 Gestión del cambio .......................................................................................... 53
9.2 Gestión de incidencias ..................................................................................... 53
9.3 Gestión de depuración ..................................................................................... 54
9.4 Ejercicios .......................................................................................................... 55
9.4.1 Ejercicio 1 .................................................................................................. 55
9.4.2 Ejercicio 2 .................................................................................................. 56
10 Gestión de liberaciones, despliegue y entregas .................................................... 57
10.1 Procedimientos ................................................................................................ 57
10.1.1 Entregables de un proyecto ..................................................................... 57
10.1.2 Identificación de entregables ................................................................... 58
10.1.3 Gestión de la publicación, la liberación y entrega ................................... 58
10.1.4 Lugar y roles durante la entrega .............................................................. 60
10.2 Implementación ............................................................................................... 60
10.3 Caso Práctico .................................................................................................... 61
10.3.1 Enunciado ................................................................................................. 61
10.3.2 Solución .................................................................................................... 61
11 Mapa de herramientas ........................................................................................... 66
6
11.1 Lista de herramientas ...................................................................................... 66
11.2 Mapa de herramientas .................................................................................... 69
12 Conclusiones ........................................................................................................... 69
Referencias ..................................................................................................................... 70
Índice de Tablas Tabla 1: Relación de Hitos .............................................................................................. 12
Tabla 2: Historia de usuario Donación ........................................................................... 18
Tabla 3: Historia de usuario Interfaz móvil .................................................................... 18
Tabla 4: Historia de usuario Encuestas ciudad ............................................................... 19
Tabla 5: Historia de usuario Encuestas más votadas ..................................................... 19
Tabla 6: Historia de usuario Comentarios ...................................................................... 19
Tabla 7: Elementos de configuración ............................................................................. 20
Tabla 8: Dependencias de Maven .................................................................................. 21
Índice de Figuras
Ilustración 1: Arquitectura de Agora@US ...................................................................... 10
Ilustración 2: Comunicación del subsistema de visualización ........................................ 13
Ilustración 3: Diagrama de componentes de subsistemas ............................................. 14
Ilustración 4: DIAGRAMA DE COMPONENTES TRAS INTEGRACIÓN ............................... 15
Ilustración 5: Estructura de AngularJS; Scripts de AngularJS; Estructura de las vistas .. 16
Ilustración 6: Fichero app.js con el modo HTML5 .......................................................... 17
Ilustración 7: Ejemplo de controlador en controllers.js ................................................. 17
Ilustración 8: Ejemplo de redirección en un controlador de Spring .............................. 17
Ilustración 9: Virtual BOX................................................................................................ 22
Ilustración 10: JAVA ........................................................................................................ 22
Ilustración 11: IDE ECLIPSE ............................................................................................. 23
Ilustración 12: Importando Maven ................................................................................. 23
Ilustración 13: Configuración del archivo setting.xml .................................................... 24
Ilustración 14: Maven ..................................................................................................... 24
Ilustración 15: Instalación EGit ....................................................................................... 25
Ilustración 16: Añadir vista de Git .................................................................................. 26
Ilustración 17: Clonando un repositorio existente ......................................................... 26
Ilustración 18: Creación de base de datos ..................................................................... 27
Ilustración 19: MySQL ..................................................................................................... 27
7
Ilustración 20: Configuración Tomcat ............................................................................ 28
Ilustración 21: Configuración Tomcat II .......................................................................... 29
Ilustración 22: Apache Tomcat ....................................................................................... 29
Ilustración 23: Creación de ramas .................................................................................. 31
Ilustración 24: Creación de rama DevelopmentPaypal .................................................. 35
Ilustración 25: Cambio a la rama DevelopmentPaypal .................................................. 36
Ilustración 26: Publicando la rama DevelopmentPaypal en el servidor ........................ 37
Ilustración 27: Añadiendo los commits a la rama DevelopmentPaypal ......................... 38
Ilustración 28: UNIENDO LA RAMA DEVELOPMENTPAYPAL .......................................... 39
Ilustración 29: REPOSITORIO DE CÓDIGO EN GITHUB ................................................... 41
Ilustración 30: GENERANDO EJECUTABLE EN JENKINS .................................................. 43
Ilustración 31: EXPORTANDO WAR FILE EN ENTORNO DE DESARROLLO ...................... 44
Ilustración 32: PANEL PRINCIPAL DE SLACK ................................................................... 45
Ilustración 33: GRÁFICOS EN GITHUB ............................................................................. 45
Ilustración 34: CREANDO NUEVA TAREA ........................................................................ 46
Ilustración 35: CONECTANDO JENKINS CON GIT ............................................................ 47
Ilustración 36: CONFIGURANDO MAVEN EN JENKINS .................................................... 47
Ilustración 37: AUTOMATIZANDO MAVEN EN JENKINS ................................................. 48
Ilustración 38: HISTORIA DE TAREAS EN JENKINS .......................................................... 48
Ilustración 39: ESTABLECIENDO CUENTA DE CORREO EN JENKINS ............................... 49
Ilustración 40: NOTIFICACIÓN POR CORREO ELECTRÓNICO EN JENKINS ...................... 49
Ilustración 41: NOTIFICACIÓN POR CORREO ELECTRÓNICO EN JENKINS ...................... 50
Ilustración 42: AÑADIENDO DESTINATARIOS DE CORREO EN JENKINS ......................... 50
Ilustración 43: GENERANDO .WAR EN JENKINS ............................................................. 51
Ilustración 44: GENERANDO .WAR EN JENKINS ............................................................. 51
Ilustración 45: GENERANDO .WAR EN JENKINS ............................................................. 52
Ilustración 46: CREACIÓN DE INCIDENCIA ...................................................................... 54
Ilustración 47: HISTORIAL DE INCIDENCIAS .................................................................... 54
Ilustración 48: CREACIÓN DE INCIDENCIA ...................................................................... 55
Ilustración 49: Cerrar incidencia ..................................................................................... 55
Ilustración 50: CICLO DE VIDA SOFTWARE [Referencia2] .............................................. 58
Ilustración 51: CICLO DE VIDA ÁGIL [Referencia2] ......................................................... 59
Ilustración 52: CREACIÓN DE UNA APLICACIÓN EN OPENSHIFT .................................... 61
Ilustración 53: CREACIÓN DE APLICACIÓN EN OPENSHIFT ............................................ 62
Ilustración 54: DUMPING BASE DE DATOS ..................................................................... 62
Ilustración 55: MODIFICACIÓN SCRIPT DE EXPORTACIÓN ............................................. 63
Ilustración 56: CONSOLA PHPMYADMIN DE BD EN OPENSHIFT .................................... 64
Ilustración 57: URL REPOSITORY REMOTO OPENSHIFT ................................................. 64
Ilustración 58: CLONANDO REPOSITORIO REMOTO OPENSHIFT ................................... 65
Ilustración 59: EXPORTAR APLICACIÓN EN ECLIPSE ....................................................... 65
Ilustración 60: SPRING .................................................................................................... 66
Ilustración 61: HIBERNATE .............................................................................................. 66
Ilustración 62: JAVA ........................................................................................................ 66
Ilustración 63: JAVA DEVELOPMENT KIT ........................................................................ 66
8
Ilustración 64: MAVEN .................................................................................................... 67
Ilustración 65: ECLIPSE.................................................................................................... 67
Ilustración 66: JSON ........................................................................................................ 67
Ilustración 67: GIT ........................................................................................................... 67
Ilustración 68: MYSQL ..................................................................................................... 67
Ilustración 69: APACHE ................................................................................................... 68
Ilustración 70: OPENSHIFT .............................................................................................. 68
Ilustración 71: JENKINS ................................................................................................... 68
Ilustración 72: SONARQUBE ........................................................................................... 68
Ilustración 73: SLACK ...................................................................................................... 68
Ilustración 74: MAPA DE HERRAMIENTAS ...................................................................... 69
9
1 Resumen
En el presente docoumento se detalla toda la información acerca del subsitema
Frontend y Visualización de resultados. Dicho subsistema pertenece al proyecto
Agora@US, aplicación que ofrece un servicio de votaciones de forma segura online.
Este subsistema se realizará con la finalidad de aprender a trabajar en grupo y llevar
una gestion de la configuracion del proyecto mencionado anteriormente, que se llevará
a cabo dentro de la asignatura Evolución y Gestión de la Configuración, incluida en la
titulacion de Grado de Ingeniería del Software.
El sistema Agora@us es un proyecto que se divide en varios subsitemas, de forma
que tanto el desarrollo como la gestión del código se realiza de forma independiente en
cada subsitema. En nuestro caso, el subsistema a desarrollar es el de Frontend y
Visualización de resultados, cuyo objetivo es comunicarse con los subsistemas de
Recuento y Moodificación de Resultados, para procesar los datos y posteriormente,
visualizarlos para informar al usuario de los resultados de las votaciones.
Las herraminetas usadas para el trabajo son las siguientes:
o Gestión del proyecto: Projetsii.
o Gestión de la construcción: Maven, usado para la compilación.
o Gestión del código fuente: Git, repositorio de codigo que ofrece un servicio
de control de versiones y centralización del código.
o Gestion de despliegue: Openshift, usado para desplegar la aplicación.
o Gestión de la calidad: Google CodePro Analytic, herramienta gratuita
ofrecida por Google para mejorar la calidad del software.
10
2 Introducción En esta sección se presenta la arquitectura que tiene el proyecto Agora@US y a
continuación, se describe el funcionamiento del subsistema Frontend y Visualización
de resultados y de los subsistemas de los que depende.
2.1 Qué es Agora@US Para aprender a realizar la evolución y gestión de un código, se decidió usar
Agora@US, proyecto que surge como ejemplo para aprender la integración entre los
subsistemas que forman esta aplicación.
Para el presente curso, cada subsistema debe de obtener el código realizado en
el curso 2014/2015, evolucionarlo añadiendo nuevas funcionalidades y/o detectando
y corrigiendo errores, integrando finalmente todos los subsistemas obteniendo de
nuevo el mismo proyecto realizado en el curso 2014/2015, pero con nuevas
funcionalidades y reduciendo los errores a nivel de codificación que se produjeron en
el año pasado.
A continuación se muestran los subsistemas que se acordaron el pasado año y a
los cuales, la clase debía de adaptarse:
Ilustración 1: Arquitectura de Agora@US
11
2.2 Frontend y Visualización de resultados
Nuestro grupo es el encargado de desarrollar el subsitema de Frontend y
Visualización de resultados, cuyo propósito es recibir los recuentos de los votos de las
distintas votaciones o referéndums para almacenarlos en una base de datos propia y
posteriormente visualizarlos en forma de gráficas, para que el usuario de manera rápida
e intuitiva pueda comprobar los resultados de las votaciones.
El recuento de votos (mencionado anteriormente) es realizado por los
subsistemas de Modificación de resultados y Recuento de Votos, que se coordinan entre
ellos para ofrecer la información adecuada a traves del subsitema de Recuento de Votos.
Desde principios del proyecto, nuestro grupo llegó al acuerdo con el grupo de
Recuento de Votos de que la comunicación entre los dos subsitemas sería a traves del
uso de API REST, por lo que los datros sería enviados como un JSON con formatos
distintos, dependiendo de la API en cuestión.
2.3 Tecnología
Referente a las tecnologías, nos encontrabamos que el código heredado
correspondiente a los subsistemas que nuestro grupo debía de desarrollar era diferente.
Por un lado, el subsitema de Frontend de Resultados utilizaba el framework Spring e
Hibernate mientras que el subsitema de Visualización de Resultados había desarrollado
su proyecto usando HTML y JavaScript.
Por tanto, la primera decisión que debe de tomar el grupo es como desarrollar el
proyecto que se nos planteaba. Había tres opciones:
Evolucionar el código de ambos subsistemas usando los frameworks
usados en el anterior curso.
Migrar el código del subsistema de Frontend de Resultados al framework
de Visualización de Resultados.
Migrar el código del subsistema de Visualización de Resultados al
framework de Frontend de Resultados.
La primera opcion rapidamente fue descartada, ya que aunque es una opción
viable, no estimamos que fuera la mejor opción, puesto que debíamos de integrarnos
entre nosotros mismo, además que con el resto de subsistemas. Por tanto, la cuestión
era hacia que framewok realizamos la migración.
Finalemente, se realizó la migración del código del subsistema de Visualización
de Resultados al framework Spring e Hibernate.
12
3 Relación de Hitos
Fecha Nombre
17 de Noviembre 2015 Integración 01
01 de Diciembre 2015 Integración 02
15 de Diciembre 2015 Integración 03
26 de Diciembre 2015 Entrega de proyecto
12 de Enero 2016 2015 Integración 04
Tabla 1: Relación de Hitos
4 Descripción del sistema
En este capítulo se presenta detalles técnicos y funcionales de los subsistemas
heredados y los cambios a nivel estructural y funcional que se pretenden introducir.
4.1 Estado anterior
Los subsistemas de Visualización y de Frontend de los resultados se encontraban
separados pues fueron desarrollados por grupos diferentes en el curso anterior.
Visualización se comunicaba mediante peticiones asíncronas al subsistema Frontend y
con el subsistema de Creación y administración de censos para obtener los datos que se
iban a mostrar. En concreto solicitaba dos formatos de JSON correspondientes a la lista
de encuestas y a los recuentos con las respuestas. Visualización para mostrar las gráficas
hacia uso de la librería Highcharts en javascript.
Por otro lado, tenemos que Frontend se comunica con Recuento que es el que
envía información sobre los recuentos realizados de los votos en una encuesta. Estos
datos son persistidos y accesibles a Visualización.
A continuación, presentamos un diagrama de secuencia de la comunicación que
se producía en el sistema heredado desde la perspectiva de visualización.
13
Se presenta también un diagrama de componentes en el que se muestra la
conexión entre subsistemas.
Ilustración 2: Comunicación del subsistema de visualización
14
4.2 Cambios que se proponen
Se analiza el estado actual de los subsistemas de Visualización y Frontend de
resultados, y se procede a la integración del código de Visualización con el de Frontend
para aprovechar la utilidad que ofrece el framework de Spring y Hibernate en el que ha
sido desarrollado este último.
Ilustración 3: Diagrama de componentes de subsistemas
15
Ilustración 4: DIAGRAMA DE COMPONENTES TRAS INTEGRACIÓN
Se pretenden realizar algunos cambios de funcionalidad como de estructura, los
cuales destacamos a continuación:
- En primer lugar, se estudia la posibilidad de que la aplicación se haga responsive,
esto es, que pueda la interfaz de usuario ajustarse a las pantallas de los
dispositivos móviles. Para ello se investigan diferentes tecnologías y se opta por
la integración de Bootstrap en la aplicación.
- Se decide añadir código haciendo uso de “Apache Tiles” mediante JSP, pero es
más tarde se explora la alternativa de usar “AngularJS”. La aplicación funcionaba
con el componente “Apache Tiles” que facilitaba el funcionamiento del Modelo
Vista Controlador. Los cambios de “AngularJS” se detallan más adelante.
- Se decide estudiar la posibilidad de usar postgreSQL como SGBD en lugar de
MySQL.
- Se estudia la posibilidad de añadir la funcionalidad de que los usuarios puedan
realizar donaciones a la aplicación. Se estudian diferentes formas de hacerlo y se
decide el uso de “Paypal”.
- Se pretende añadir nuevas estadísticas sobre las encuestas y sus resultados
como:
16
Número de encuestas realizadas por ciudad o lugar
Las preguntas con más respuestas
- Se desea añadir comentarios a los resultados de una encuesta.
4.3 Cambios de AngularJS A continuación se detallan los cambios realizados para la correcta integración y
funcionamiento de “AngularJS” con los componentes ya existentes en el proyecto del
año pasado.
Uno de los cambios más importantes fue la eliminación de “Apache Tiles” de
nuestro proyecto, eliminando la configuración que permitía el mapeo de las vistas y se
cambión la página de inicio a “index.html” con un formato que permite el uso de
“AngularJS” con sus correspondientes módulos y variables. Tras realizar este cambio
teníamos que añadir un nuevo mecanismo que nos permitiese mapear las vistas, por lo
que se creó una nueva estructura para que “AngularJS” pudiese mapear
correctamente las vistas:
Ilustración 5: Estructura de AngularJS; Scripts de AngularJS; Estructura de las vistas
El fichero “index.html” es el fichero principal, en el cual mediante “AngularJS”
insertaremos las diferentes vistas que se quieran mostrar, teniendo además incluidos
en la cabecera los scripts correspondientes para el correcto funcionamiento de
“AngularJS”.
En el fichero “app.js” se encuentra la definición de la aplicación de angular y
como se mapean las rutas de las url dentro del contexto de la aplicación de
“AngularJS”. Aquí es donde se decide, en función de la url, que vista se va a cargar y
con qué controlador.
17
Ilustración 6: Fichero app.js con el modo HTML5
En el fichero “controllers.js” es donde se definen los controladores que se
cargarán y ejecutarán en función del fichero “app.js” y la url de dirección. Además es
necesario decirle a “AngularJS” que use el “modo HTML5”, el cual ayuda a la
redirección.
Ilustración 7: Ejemplo de controlador en controllers.js
Tras realizar esto, nos dimos cuenta de que no era suficiente, ya que si se
introducía manualmente la url en el navegador, obteníamos un “404 page not found”
(ya que no había interacción con el servidor) por lo que fue necesario crear un
controlador con “Spring framework” que redireccione al controlador de “AngularJS” a
través de la url (incluyendo /#/ justo antes de la url para decirle a “AngularJS” que se
encargue de la redirección. Esto es posible gracias al “modo HTML5”.
Ilustración 8: Ejemplo de redirección en un controlador de Spring
También se cambiaron los controladores a controladores rest, de forma que
devuelvan objetos JSON para que angular se encargue de usarlos en las vistas. Para
realizar pruebas se han creado otros controladores de Spring que devuelven JSONs, de
forma que podemos probar la aplicación como si consumiésemos una API externa.
Respecto a las pruebas con “AngularJS”, aún no podemos realizarlas de forma
automática, ya que la forma de probar AngularJS se realiza mediante Karma.js y
Protractor.js, los cuales necesitan Node.js para funcionar. Esta opción se ha descartado
de momento debido al aumento considerable de tamaño del proyecto y las
18
dificultades que planteaba a la hora del despliegue. Aun así se están buscando
alternativas.
4.4 Historias de usuario A continuación, se hace una descripción de las historias de usuario referentes a los
cambios citados con anterioridad:
Tabla 2: Historia de usuario Donación
Tabla 3: Historia de usuario Interfaz móvil
ID: 1 Nombre: Donación
Prioridad: 4
Estimación: 4
Descripción: Como administrador quiero poder recibir donaciones para que los usuarios contribuyan al mantenimiento de la aplicación
Dependencias: Ninguna
Pruebas de aceptación:
Realizar donación y comprobar que se ha ingresado en la cuenta
ID: 2 Nombre: Interfaz móvil
Prioridad: 1
Estimación: 4
Descripción: Como usuario quiero poder acceder a la visualización de los resultados desde un dispositivo móvil para consultar los resultados en cualquier parte.
Dependencias: Ninguna
Pruebas de aceptación:
Realizar donación y comprobar que se ha ingresado en la cuenta
19
Tabla 4: Historia de usuario Encuestas ciudad
Tabla 5: Historia de usuario Encuestas más votadas
Tabla 6: Historia de usuario Comentarios
ID: 3 Nombre: Encuestas ciudad
Prioridad: 2
Estimación: 4
Descripción: Como usuario quiero poder visualizar la frecuencia de encuestas por ciudades para que poder conocer cuáles son las ciudades con más actividad.
Dependencias: Ninguna
Pruebas de aceptación:
Visualizar el número de encuestas por ciudad
ID: 4 Nombre: Preguntas más votadas
Prioridad: 3
Estimación: 4
Descripción: Como usuario quiero poder ver las preguntas que más participación han tenido para conocer en qué temas se suele votar más.
Dependencias: Ninguna
Pruebas de aceptación:
Listar las preguntas con más respuestas
ID: 5 Nombre: Comentarios
Prioridad: 5
Estimación: 4
Descripción: Como usuario quiero poder comentar los resultados de una votación para realizar un análisis de los resultados.
Dependencias: Ninguna
Pruebas de aceptación:
Comentar los resultados de una encuesta y comprobar que el comentario se ha almacenado.
20
5 Elementos de control Los elementos de configuración se identifican en la siguiente tabla:
Elementos de configuración
Memoria del proyecto Máquina virtual de desarrollo y despliegue Código fuente integrado de Frontend y visualización Componentes(depedencias .jar de maven)
Tabla 7: Elementos de configuración
Con respecto a la nomenclatura a utilizar, podemos definir el formato para los
elementos de configuración. El formato será el de X.Y.Z donde X identifica cambios
relevantes y mayores en el elemento como solución de un problema de integración o la
adición de un nuevo apartado, Y cambios medios que necesiten un pequeño análisis y Z
cambios menores de errores locales que se corrigen de manera rápida.
A continuación, se enumeran los artefactos (componentes de terceros) que se deben
tener en cuenta para la gestión de la configuración. Cabe destacar que la nomenclatura
que se utiliza para los componentes es la usada por maven.
Artefacto Versión
spring-context 3.2.4.RELEASE
spring-webmvc 3.2.4.RELEASE spring-orm 3.2.4.RELEASE spring-tx 3.2.4.RELEASE spring-aspects 3.2.4.RELEASE spring-data-jpa 1.3.4.RELEASE spring-security-web 3.1.4.RELEASE spring-security-config 3.1.4.RELEASE spring-security-taglibs 3.1.4.RELEASE spring-test 3.2.4.RELEASE jackson-databind 2.6.2 jackson-annotation 2.6.2 jackson-core 2.6.2
javax.inject 1 aspectjrt 1.7.4 tiles-core 2.2.2 tiles-servlet 2.2.2 tiles-jsp 2.2.2 mysql-connector-java 5.1.26 hibernate-entitymanager 4.2.3.Final hibernate-c3p0 4.2.3.Final hibernate-validator 4.3.1.Final servlet-api 2.5
21
jsp-api 2.0
jstl 1.2 displaytag 1.2 standard 1.2.2 junit 4.11 joda-time 2.2 slf4j-log4j12 1.7.5
Tabla 8: Dependencias de Maven
5.1 Gestión del cambio para componentes
En el caso de que sea necesario añadir o modificar un componente se deberá:
1. buscar la versión más actualizada
2. realizar pruebas para comprobar y verificar que todo funciona como
anteriormente usando esa versión
3. en el caso de incompatibilidad, buscar una versión más antigua compatible con
el resto de y realizar pruebas
4. verificar que el problema se ha solucionado
5. documentar los cambios realizados
22
Ilustración 9: Virtual BOX
Ilustración 10: JAVA
6 Entorno de Desarrollo A continuación, se detallan el entorno que hemos usado, además de otras
herramientas complementarias al entorno de desarrollo. Es importante prestar
atención a las versiones instaladas, pues de lo contrario, no se puede asegurar el
correcto funcionamiento de la aplicación.
6.1 Máquina Virtual El equipo de desarrollo ha querido simular al máximo el entorno de desarrollo
que se encontrará en una empresa profesional. Es por ello que todo el trabajo ha sido
desarrollado en una máquina virtual. Esto tiene una serie de ventajas, como que no
desperdiciamos los recursos de nuestra máquina física. En cualquier momento, si
necesitamos asignarle más recurso para la realización del proyecto, podremos
asignárselos.
La máquina virtual usada para este proyecto ha sido VirtualBox, en la que
debemos de instalar la versión 4.2 o superior. Podemos descargarnos esta máquina
virtual desde su página oficial (https://www.virtualbox.org/wiki/Downloads).
6.2 Java Necesitamos de un compilador Java. Para ello, vamos a usar JDK en su versión 1.7, el
cual lo podemos encontrar en la siguiente página
(http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-
2133151.html?ssSourceSiteId=otnes)
23
Ilustración 12: Importando Maven
Ilustración 11: IDE ECLIPSE
6.3 Eclipse Debido a la gran familiarización de todos los desarrolladores con el entorno de
desarrollo Eclipse, se ha decidido usar Eclipse, en su versión Eclipse Indigo. Lo
podemos encontrar para descargárnoslo desde su página oficial
(https://www.eclipse.org/downloads/)
6.4 Maven Esta herramienta es usada para la construcción de nuestro proyecto, en el cual
se encontrarán todas las dependencias que son necesarias para el desarrollo de éste.
Maven lo podemos integrar con nuestro entorno de desarrollo mediante un plugin que
se encuentra dentro del Marketplace de eclipse. Los pasos para instalar y configurar
este plugin son los siguientes:
1. Debemos de dirigirnos a la página oficial de Maven
(https://maven.apache.org/download.cgi) y descargarnos su última versión.
Una vez descargado, debemos de descomprimir el paquete en el lugar que
consideremos más adecuado.
2. Desde eclipse, debemos acceder al menú “Windows>Preference”, escribimos
“maven” y seleccionamos en el submenú que nos aparece “Installation”. Nos
mostrará la versión de maven que instalamos en el paso anterior. Debemos
de seleccionar la versión de maven que descargamos en el paso anterior.
24
Como podemos ver, se nos ha seleccionado el archivo setting.xml. Este archivo
contiene la configuración global del entorno. En el siguiente paso veremos cómo
configurar nuestro propio setting.xml
3. En el mismo submenú, debemos de seleccionar el apartado “User Setting”,
para configurar el arhivo setting.xml con la configuración que deseemos.
Ilustración 13: Configuración del archivo setting.xml
4. Configuración del archivo pom.xml. Este archivo será el que contenga todas
las dependencias que necesitemos para desarrollar el proyecto. Para ello,
basta con ver el repositoriode maven (http://repo1.maven.org/maven2/) y
ver qué dependencias tiene y añadir las dependencias de la forma:
<dependency>
<groupID>…..</ groupID >
<artefactID>….</artefactID>
<version>…</version>
<scope>….</scope>
</dependency>
Nota: el scope puede ser compile, test o runtime, dependiendo de en qué
fase queremos tener disponible la dependencia.
Ilustración 14: Maven
25
6.5 EGit
EGit es un plugin, que podemos encontrar en el Marketplace de eclipse y sirve
para poder usar el repositorio de git, dentro del IDE eclipse, sin tener que usar la
consola.
Para instalar esta herramienta, debemos de seguir lo siguientes pasos:
1. En el menú de eclipse, debemos de seleccionar “Help> Install New Software”
y en buscador poner http://dowload.eclipse.org/egit/updates-
2.3#sthash.Dv02tyGo0dpuf y seleccionar “Eclipse Git Tem Provider” y as
continuación, seleccionamos “Next”
Ilustración 15: Instalación EGit
2. Una vez que tenemos descargado el plugin, debemos de conectarnos a
nuestro repositorio de nuestra cuenta de git, para realizar nuestro primer
“git clone” y poder empezar a trabajar en nuestro repositorio local.
2.1 Colocar la vista de git en nuestro entorno de desarrollo. Para ello, en el
menú, seleccionamos “Windows>Show View” y seleccionamos Git
Repositories
26
Ilustración 16: Añadir vista de Git
2.2 Añadir un repositorio existente en Git. Para realizar este paso tendremos
que realizar:
- Añadir la URL de nuestro repositorio de Github
- Añadir el correo y la contraseña de nuestro usuario de Github
Ilustración 17: Clonando un repositorio existente
27
6.6 MySQL Para almacenar los datos de las encuestas que son recibidos por el subsistema de
recuento, el equipo de desarrollo ha decidido usar una base de datos conocida, como
es MySQL, en su versión 5.5. La podemos descargar en el siguiente enlace:
(https://dev.mysql.com/downloads/windows/installer/5.5.html)
Para configurar la base de datos solo debemos de crear una instancia, a la que
llamaremos localhost y crear una cuenta de administrador cuyas credenciales son:
- Usuario: root
- Contraseña: V3rY=$tR0nG=P@$$w0rd$
Una vez que tenemos nuestra cuanta de administrador, el siguiente es un script
para crear la base de datos. El script es el siguiente:
Ilustración 18: Creación de base de datos
Una vez que la base de datos ha sido creada, en el panel donde se encuentran las
bases de datos podremos ver como se ha creado una nueva con el nombre “egc-
frontend”.
Ilustración 19: MySQL
28
6.7 Tomcat Tomcat es un servidor de aplicaciones. Está muy bien integrado con eclipse, es por ello
por lo que el equipo de desarrollo estimó oportuno usar este servidor. La versión que
vamos a usar es la 7.0 y la podemos descargar desde el siguiente enlace
(https://tomcat.apache.org/download-70.cgi). Los pasos para la instalación es la
siguiente:
1. Buscar el servidor tomcat (previamente descargado y descomprimido en la
carpetas elegida). Para ello, debemos de dirigirnos a
Windows>preferences>servers>runtime enviroments:
Ilustración 20: Configuración Tomcat
29
2. Hacemos click en “add” y seleccionamos “Apache Tomcat v7.0” y pulsamos el
botón “next”, en lo que tendremos que seleccionar la carpeta donde
instalamos tomcat en el paso 1 y luego pulsaremos el botón “finish”
Ilustración 21: Configuración Tomcat II
3. Cuando tenemos el servidor iniciado, debemos de comprobar que el puerto usado
es el correcto. Para ello, hacemos doble click en “Tomcat v7.0 Server” en la vista de
servidores y seleccionamos el puerto como 8080 que es el que utiliza por defecto.
Ilustración 22: Apache Tomcat
30
7 Gestión del código fuente
A la hora de gestionar el código fuente, existen varias herramientas gratuitas que
pueden ser de gran utilidad. Primero, lo más importante sería elegir una herramienta
en la cual, podamos crear tareas, asignarles un recurso y además, tener un espacio
común de comunicación entre los integrantes del equipo.
7.1 Gestores de proyectos Projetsii: es una herramienta online, con la que el equipo se encuentra muy
familiarizado, debido al uso de la herramienta a lo largo de la carrera. Esta
herramienta puede ser de gran ayuda a la hora de gestionar los recursos
necesarios para este proyecto, y además, gestionar y planificar las tareas, crear
diagramas de Gantt, foros, repositorio de código…
GitHub: es una herramienta en la que el grupo no está muy familiarizado,
aunque si se conoce las funciones básicas como gestionar tareas del proyecto,
uso de su wiki, un gestor de incidencias y un repositorio de código.
El equipo estimó que la planificación es una de las fases más importantes a la hora
de abordar un proyecto software como este, por lo que sería necesario usar cuantas
herramientas sean oportunas para una mejor planificación. Por consiguiente, se usó
projetsii para la creación y asignación de tareas y también se usaría github para
gestionar las incidencias, pues usaremos su repositorio de código para alojar el código
del proyecto, y se consideró más cómodo usar dicho gestor de incidencias.
7.2 Gestión del código Como se mencionó en el apartado anterior, para la gestión del código el equipo
decidió utilizar la herramienta Git, herramienta muy potente, la cual se integra
perfectamente con nuestro entorno de desarrollo, en este caso eclipse.
Tras varias sesiones prácticas llevadas a cabo en la asignatura de Evolución y
Gestión de la Configuración, rápidamente el equipo se dio cuenta que trabajar
directamente sobre la rama master no era lo más recomendable, si no que debían de
crearse ramas, en función de la funcionalidad que se fuera a desarrollar en ese
momento y mantener en la rama master siempre una versión estable del proyecto.
En primer lugar, en el repositorio se encuentra la rama “Master”. En ella, siempre
se mantiene una versión estable del proyecto, por si en alguna ocasión, se pide algún
entregable que no esté provisto en el grupo.
Se creará una rama a partir de la rama “Master” y nunca sobre una rama que no
sea esta. En esta nueva rama se experimentará nuevas funcionalidades propuestas
para el proyecto o la integración de nuevas bibliotecas que supongan un cambio
importante sobre la arquitectura de la aplicación.
31
Para la unión de ramas, se realizará cuando la rama sobre la que se está
investigando este integrada la nueva funcionalidad y/o nueva librería y este cambio no
puede afectar a la funcionalidad del proyecto.
A continuación, con el objetivo de explicar de forma gráfica para aclarar posibles
dudas, se adjunta una imagen, representando lo antes mencionado sobre el proceso
de creación y/o unión de ramas.
Ilustración 23: Creación de ramas
7.3 Procedimientos para trabajar con el control de versiones
7.3.1 Pautas para realizar un commit
Se decidió de crear un procedimiento común a la hora de realizar los commits, de
forma que se estableció un convenio entre los integrantes del grupo a fin de que al
leer el título y descripción de un commit que sea de otro miembro del equipo, fuese lo
más claro posible. Los pasos a seguir son los siguientes:
1. Título del commit. Este debe de empezar por una palabra clave en
mayúsculas que hará referencia al tipo de cambio que se trata:
i. ADICIÓN[título del commit]
ii. CORRECCIÓN[título del commit]
iii. APIGET[título del commit]
iv. PERSISTENCIA[título del commit]
v. CONFIGURACIÓN[título del commit]
vi. DESPLIEGUE[título del commit]
2. Una vez especificado el tipo de cambio, en la parte de [título del commit]
se expondrá con un poco más de detalle el cambio lógico que supone dicho
commit, sin superar los 80 caracteres.
3. Por último, se añadirá una descripción detallada que responda al porqué
del cambio y que explique en qué consiste.
32
7.3.2 Pautas a la hora de crear una incidencia
Se decidió un procedimiento común para todos los integrantes del grupo, a fin
de detallar lo máximo posible una incidencia para que no dé lugar a confusiones por
parte de los demás usuarios. Los pasos a seguir son los siguientes:
1. Indicar los pasos a seguir para reproducir el problema.
2. Una vez llegado a donde se produce el error, indicar que error se
devuelve
3. Explicar con el máximo detalle posible cual es el resultado esperado.
4. Indicar la versión del software utilizado de desarrollo y sistema
operativo.
7.3.3 Gestión de conflictos
A la hora de gestionar los conflictos que Git no puede resolver de manera
automática, se definió un procedimiento a seguir, para minimizar en la manera de lo
posible. Al ser un equipo con una cantidad considerable de personas trabajable, es
inevitable que aparezcan futuros conflictos en el código que se deba de solucionar de
manera manual.
En primer lugar, se definió un procedimiento para la interacción con el repositorio:
1. git clone. Esto se realizaría solo la primera vez, para obtener en local el código
que hubiera en el repositorio.
2. Modificar los ficheros oportunos.
3. git pull para actualizar la versión en local.
4. git add con los ficheros quye se quiern incluir en el commit.
5. git commit. Esto se realizaría utilizando el procedimiento previamente definido
(ver pautas para realizar un commit).
6. git push, de la rama sobre la que se esté trabajando.
Tras definir estos pasos a seguir, se tomaron otras medidas con herramientas que
faciliten la comunicación entre los integrantes. Para ello, se usó la aplicación web
Slack, ya que unifica varios servicios que no oferce otras herramientas y es usado por
la mayoría de las empresas para su comunicación interna (para más información,
visitar https://slack.com/).
Como último recurso, se acordó que si seguidos estos pasos se produce algún
conflicto, el desarrollador al que le aparezca dicho conflicto será el encargado de
resolverlo.
7.4 Roles Durante el desarrollo del trabajo, podemos diferenciar los siguientes roles:
Coordinador: persona con capacidad para tomar decisiones sobre todos los
miembros del equipo, encargado de la comunicación con el resto de
coordinadores de los demás subsistemas y de solucionar los conflictos entre los
miembros del grupo en caso de que existiesen).
33
Desarrollador: persona de realizar el código fuente que le han sido asignadas,
tomando las decisiones de cuando crear una rama, cuando hacer merge, push,
etc.
Todos los integrantes tienen el rol de desarrollador, incluso el coordinador.
7.5 Sintaxis del código fuente Para la sintaxis del código fuente hemos usando la aprendida a lo largo de la titulación
de Ingeniería Informática-Ingeniería del Software.
1“En este apartado se detalla la política que se ha seguido a la hora de escribir
el código fuente, con el fin de homogeneizar la sintaxis utilizada.
En primer lugar, los nombres de todas las clases empiezan por mayúscula, y en
caso de tener más de una palabra, cada una de las que siguen a la primera también
empezarán con mayúsculas.
Por otro lado, los servicios y los repositorios relacionados con las entidades del
dominio se denominarán siguiendo el esquema NombreEntidadService yu
NombreEntidadRepository respectivamente.
En lo que respecta a los métodos de cada clase, éstos comienzan con minúscula,
pero en el caso de que tengan más de una palabra, de la segunda en adelante
comienzan con mayúscula.
Por último, para la estructura general del código se ha seguido el esquema de
programación indentada usando tabulaciones.”1
1 Para la sintaxis del código fuente, esta se ha recogido de la documentación del grupo Frontend de
Resultados del curso 2014-2015
34
7.6 Ejercicio
7.6.1 Enunciado
Tras realizar la integración de los subsistemas y se establece en la rama
“Master” un versión estable de dicho proyecto. Se desea añadir una nueva
funcionalidad al sistema heredado. La nueva funcionalidad consiste en permitir a los
usuarios realizar donaciones a la aplicación Agora@US mediante la plataforma de
pagos seguros Paypal.
En primer lugar, se debe crear una nueva rama sobre la rama Master, que se
denominará “DevelopmentPaypal”. Una vez que la rama está creada, debemos de
trabajar sobre dicha rama durante el desarrollo y finalmente, cuando la nueva
funcionalidad este completamente desarrollada, unir la rama “DevelopmentPaypal” a
la rama Master.
7.6.2 Solución
Nos dirigimos a “Team>Switch To>New Branch” y en la vista que nos aparecerá
creamos la nueva rama con nombre “DevelopmentPaypal” quedando la vista
como la mostrada:
35
Ilustración 24: Creación de rama DevelopmentPaypal
Nota: debemos de esperar a que eclipse construya el workspace. Esto puede
llevar un tiempo, dependiendo de la conexión a internet.
Nos dirigimos a “Team>Switch To>other” y marcamos la rama creada en el
paso anterior y seleccionamos el botón “checkout”:
36
Ilustración 25: Cambio a la rama DevelopmentPaypal
Nos dirigimos a “Team>Push to Upstream” para publicar la nueva rama en el
servidor:
37
Ilustración 26: Publicando la rama DevelopmentPaypal en el servidor
38
Para realizar los cambios oportunos hasta añadir la nueva funcionalidad, se
hará commit sobre la rama creada. Para hacer commit, deberemos de
dirigirnos a “Team>Commit”:
Ilustración 27: Añadiendo los commits a la rama DevelopmentPaypal
Nota: Para realizar un commit correctamente, debemos de seguir las pautas
definidas en el presente documento (ver pautas para realizar un commit)
Para enviar los cambios realizados al servidor, debemos de dirigirnos a
“Team>Push to Upstream”
Nos cambiamos a la rama “master”, realizando el mismo proceso que el
seguido en el primer apartado.
Por último, debemos de realizar un “merge”. Para ello, debemos de dirigirnos a
“Team>Merge” y seleccionamos la rama “DevelopmentPaypal” para fusionarla
con la rama en la que estamos actualmente, que será siempre la “master”:
39
Ilustración 28: UNIENDO LA RAMA DEVELOPMENTPAYPAL
40
8 Gestión de la construcción e integración continua
8.1 Procedimientos
Dentro de los procesos de integración hemos optado por una integración incremental
del sistema de cara a ir resolviendo los posibles errores de una manera progresiva y
ordenada, evitando situaciones finales insostenibles que deriven en un abandono del
proyecto. Debido a que partimos con un código heredado, el modo de ejecución será
de tipo bottom-up, partiendo de una base sólida en los niveles de codificación para ir
progresivamente escalando hasta la interfaz de usuario.
De acuerdo a los principios básicos de buenas prácticas para una correcta integración
continua, los procedimientos que nuestro sistema debe contemplar son:
1. Maintain a single source repository.
2. Automated the build.
3. Make your build self-testing.
4. Everyone commits to mainline every day.
5. Every commit should build mainline on an integration machine.
6. Keep the build fast and short.
7. Test in a clone of the production environment.
8. Make it easy for anyone to get the latest executable.
9. Everyone can see what´s happening.
10. Automated deployment.
8.2 Implementación
1. Maintain a single source repository
Para mantener repositorios unificados se han tomados dos medidas, por un lado
hemos gestionado nuestro código fuente con un sistema de control de versiones GIT y
lo hemos almacenamos en un repositorio desde Github. Por otro lado, para gestionar
las dependencias de los diferentes artefactos del proyecto se ha utilizado Maven como
repositorio de artefactos.
41
Ilustración 29: REPOSITORIO DE CÓDIGO EN GITHUB
2. Automated the build
Para automatizar la compilación del proyecto hemos montado nuestro propio servidor Jenkins. Hubiera sido más práctico montar uno para todos los subsistemas, de hecho se hizo, pero el sistema dejó de estar operativo y decimos montar el nuestro para evitar problemas.
URL: https://jenkins-visualizacion.rhcloud.com
User: admin
Pass: CXTkrnbwD9GY
42
3. Make your build self-testing
Para conseguir que durante la construcción del proyecto se ejecuten los tests hemos
nuevamente usando Jenkins. En los casos prácticos se explica con más detalle la
configuración.
Resaltar que inicialmente teníamos el entorno preparado para lanzar algunos test
básicos con JUnit pero que al aplicar Angular no hemos podido usar JUnit. Esperamos
que en la siguiente entrega podamos tener tests que funcionen con Angular.
4. Everyone commits to mainline every day
No estamos trabajando en un proyecto con un volumen elevado de generación de código. Entendemos la importancia en proyectos de escala real pero en nuestro caso no hemos podido mantener esta frecuencia. No obstante, teniendo en cuenta esta premisa, durante el desarrollo de alguno de los puntos comentados en la memoria, los commits se han hecho lo antes posible, no siendo superior a tres días desde el inicio del desarrollo de la funcionalidad concreta.
5. Every commit should build mainline on an integration machine
La compilación sobre la mainline del proyecto durante los commits se ha automatizado con Jenkins. Cada vez que un desarrollador aplica un cambio sobre el repositorio general unos procesos compilarán el código en todo momento, en este caso práctico podemos verlo con más detalle.
6. Keep the build fast and short
Para optimizar el código queremos aplicar controles de calidad del software con herramientas como Sonar y Google CodePro Analitycs. Por cuestiones de tiempo no hemos podido abordar este apartado en este entregable, es nuestra intención añadirlo en la siguiente entrega.
7. Test in a clone of the production environment
Durante el Proyecto se ha dispuesto dos entornos virtualizados de trabajo, un entorno para ejecutar las tareas de desarrollo, y otro entorno virtualizado de las mismas características que las de producción donde se han ejecutado las pruebas de aceptación y despliegue de la aplicación.
43
8. Make it easy for anyone to get the latest executable
Este apartado lo hemos cumplido automatizando el proceso de generación del .war desde Jenkins. En este caso práctico se puede ver con más detalle como en cada momento está disponible desde dicho servidor.
Ilustración 30: GENERANDO EJECUTABLE EN JENKINS
Igualmente, desde los entornos de desarrollo preparados con Eclipse e integrados con el repositorio git, la obtención del ejecutable es tan simple como darle a exportar como se indica en la siguiente imagen.
44
Ilustración 31: EXPORTANDO WAR FILE EN ENTORNO DE DESARROLLO
9. Everyone can see what´s happening.
En los que respecta a la comunicación se han tomado varias medidas, por un lado, el
uso de GitHub nos muestra información en todo momento del estado y actividad del
proyecto, información que es accesible para todos los miembros del equipo y del resto
de subsistemas. Además se ha configurado en Jenkins procesos automáticos que
controlan el código y cuando algún cambio afecta al estado del proyecto es notificado
a los desarrolladores implicados, en este caso práctico lo podemos ver con más detalle.
Para la comunicación entre los miembros del equipo se ha utilizado Slack donde se
puede mantener conversaciones de equipo además se soporte para el intercambio de
ficheros. Esta herramienta se ha integrado con GitHub de manera que todos los
cambios que se ejecuten sobre el código se reflejarán en las salas de comunicación del
grupo. Más detalle en https://egcteam10.slack.com/
45
Ilustración 32: PANEL PRINCIPAL DE SLACK
Ilustración 33: GRÁFICOS EN GITHUB
46
10. Automated deployment
Como se explica con más detalle en el capítulo de despliegue , el proceso de despliegue ha sido automatizado para desplegarlo sobre Openshift. Entendemos que hay otras formas de automatizarlo y lo intentaremos mejorar en el siguiente entregable con herramientas de Jenkins y Apache Ants.
Nota: La forma de enfocar el apartado anterior ha sido basada en uno de los trabajos del año pasado. Sólo hemos tomado la idea de explicar nuestro trabajo basándose en los 10 principios básicos de integración continua.
8.3 Caso Práctico 1
8.3.1 Enunciado
De acuerdo a las buenas prácticas para una integración incremental, un equipo de desarrolladores desea implementar en Jenkins un control periódico del código fuente, de manera que diariamente el código, con un sistema de control de versiones Git y con gestión de dependencias con Maven, debe ser empaquetado y compilado, además de pasar los test correspondientes. El control deberá ser también lanzado cuando cualquiera de los desarrolladores aplique algún cambio sobre el repositorio.
8.3.2 Solución
Lo primero que debemos hacer es ir al Panel de Control y crear nueva tarea
Ilustración 34: CREANDO NUEVA TAREA
47
Para conectar Jenkins con nuestro repositorio GIT, configuramos como se indica a
continuación:
Ilustración 35: CONECTANDO JENKINS CON GIT
Para programar las tareas diariamente debemos indicarlo en el programador, con @daily. Para compilar el proyecto lo indicamos desde la opción “Ejecutar”
Ilustración 36: CONFIGURANDO MAVEN EN JENKINS
48
Ilustración 37: AUTOMATIZANDO MAVEN EN JENKINS
Con estos comandos, al lanzar “clean” se borrarán las compilaciones anteriores que hayamos realizado y con “package” se realizarán las siguientes acciones:
validate: Valida que el proyecto es válido y contiene los elementos necesarios. compile: Compila el código. test: ejecutará los test unitarios que tengamos configurado, JUnit en este caso. package: Compila y empaqueta el código.
Si todo ha ido bien, cuando
pulsemos sobre “Construir”
deberemos obtener los
indicadores de estado de color
azul tal como se indica en la
siguiente pantalla.
Ilustración 38: HISTORIA DE TAREAS EN JENKINS
49
8.4 Caso Práctico 2
8.4.1 Enunciado
En el mismo proyecto del caso práctico1, el jefe de proyecto quiere que cuando haya algún problema durante el control rutinario el problema sea notificado al desarrollador que lo ha provocado para que sea corregido cuanto antes.
8.4.2 Solución
Lo primero que tenemos que hacer es crearnos una cuenta de correo que será la que usemos para enviar las alertas en Jenkins. Para nuestro ejemplo hemos usado una cuenta de Gmail ([email protected])
El siguiente paso es configurar Jenkins y asignarle la cuenta de correo desde la “Configuración del Sistema”.
Ilustración 39: ESTABLECIENDO CUENTA DE CORREO EN JENKINS
Desde “Notificaciones por correo electrónico” deberemos introducir los siguientes
parámetros:
Ilustración 40: NOTIFICACIÓN POR CORREO ELECTRÓNICO EN JENKINS
50
Configuradas las variables del entorno, ya sólo nos queda entrar en la tarea de nuestro proyecto y programar la orden de notificación por correo. Para esto, entramos en “Configurar” de la tarea en cuestión y nos dirigimos a “Acciones para ejecutar después”. Aquí añadiremos una nueva acción, “Notificación por correo electrónico”.
Ilustración 41: NOTIFICACIÓN POR CORREO ELECTRÓNICO EN JENKINS
En este panel es interesante resaltar que para evitar un uso indiscriminado de envío de
correos que sólo acaban en la bandeja de eliminados, es recomendable fijar envíos
individualizados de los avisos a quién los provocó. Opcionalmente se podría añadir
también al jefe de proyecto.
Ilustración 42: AÑADIENDO DESTINATARIOS DE CORREO EN JENKINS
51
8.5 Caso Práctico 3
8.5.1 Enunciado
Para poder automatizar el despliegue, el jefe de proyecto quiere que en todo momento se disponga un fichero .war actualizado para poder desplegarlo en el servidor de aplicaciones cuando antes.
8.5.2 Solución
Para automatizar el proceso debemos seleccionar desde “Acciones a ejecutar después”
Ilustración 43: GENERANDO .WAR EN JENKINS
Ilustración 44: GENERANDO .WAR EN JENKINS
52
Si todo es correcto, cuando compilemos el proyecto veremos el siguiente resultado:
Ilustración 45: GENERANDO .WAR EN JENKINS
53
9 Gestión del cambio, incidencias y depuración
Dado el tipo de proyecto que se va a abordar, evolucionar un código heredado a
une versión en la que incluya nuevas funcionalidades, el cambio es un hecho de que va
a ocurrir. Además, al ser un proyecto en el que está dividido en varios subsistemas el
cual, deben de integrarse, todo ello es sinónimo que en el futuro surgirán problemas
Por todo ello, es importante mantener definido una serie de pautas para realizar
un cambio o como crear una incidencia y tener procedimientos de depuración para
conseguir un código lo más correcto posible.
9.1 Gestión del cambio En el presente documento, procedimos a explicar de forma breve como se
procedería en el caso que fuera necesario. En concreto, se hizo referencia al
procedimiento para crear una rama (ver procedimiento).
Por otro lado, en la herramienta usada para la gestión del proyecto (projetsii), el
desarrollador correspondiente deberá de asignarse la tarea correspondiente a la que
vaya a realizar, que podrá ser, realizar una nueva funcionalidad (siguiendo los pasos de
creación de ramas descritos anteriormente) o realizar una parte de la documentación,
la cual deberá de explicar en la tarea el tiempo dedicado y en que versión de la
documentación se realizó.
9.2 Gestión de incidencias Es importante definir una serie de pautas a la hora de realizar una incidencia.
Esta es vista por todos los miembros del equipo, incluso por los miembros que están
desarrollando otro subsistema. Para ello, con anterioridad se definió una pautas a
seguir a la hora de crear una incidencia (ver pautas).
Las incidencias son creadas mediante la herramienta GitHub, en la opción
“issues”, opción muy útil ya que al crear la incidencia, se envía una notificación al
correo electrónico de todos los miembros que estén en dicho repositorio.
54
Ilustración 46: CREACIÓN DE INCIDENCIA
Una vez que una incidencia ha sido resuelta, debe de cerrarse, quedando
registrada en un historial de incidencias, que puede ser consultado por cualquier
miembro del equipo, para posibles aclaraciones de futuras incidencias. A continuación
se muestra una imagen del historial de incidencias, la cual podemos ver que podemos
aplicar diversos tipos de filtros, que será de gran utilidad a la hora de listar cierpos
tipos de incidencias.
Ilustración 47: HISTORIAL DE INCIDENCIAS
9.3 Gestión de depuración Cuando existe una incidencia, es necesario solucionarla con la mayor brevedad
posible. Para tener claro que hay que hacer, es necesario definir un proceso para que
cualquier persona, sin conocer el código que intenta corregir el error pueda resolverlo.
El primer paso es identificar la incidencia y cual es el motivo por el que se está
produciendo. Para ello, es necesario reproducir los pasos descritos en la incidencia,
para llegar al error.
Dado que el error puede ser de dos motivos, existen dos procedimientos a seguir:
1. Si el error es de ejecución, el procedimiento sería el estudio de la traza de
errores mostrada, con el fin de reconocer el origen del fallo.
55
2. Si el error es de tipo lógico, se usará el depurador de Java, mediante
puntos de ruptura.
Una vez que el error se ha corregido, debe de realizarse diferentes pruebas de modo
que se pueda asegurar que el error ha sido corregido completamente.
9.4 Ejercicios
9.4.1 Ejercicio 1
9.4.1.1 Enunciado
Se tiene una versión totalmente funcional de la aplicación, y se quiere que esta
esté desplegada en Internet. Esta tarea es asignada a un desarrollador, que tras varios
intentos, crea una incidencia debido a que obtiene un error que no tiene la capacidad
de solucionar. Otro desarrollador, lee la incidencia y decide ayudarle con su error,
hasta que consigue solucionarlo y que finalmente, la aplicación quede desplegada en
Internet.
9.4.1.2 Solución
El primer desarrollador, tras varios intentos, es incapaz de solucionar la tarea
que se le fue asignada, por lo que decide crear una incidencia.
Ilustración 48: CREACIÓN DE INCIDENCIA
Otro desarrollador, al ver la notificación en su correo electrónico decide ver todas las
incidencias que hay para poder ayudar a este desarrollador. Tras estudiar la traza
arrojada, finalmente identifica el error, corrigiéndolo y finalmente, reportando como
ha solucionado el error, cerrando la incidencia.
Ilustración 49: Cerrar incidencia
56
9.4.2 Ejercicio 2
9.4.2.1 Enunciado
Se desea añadir una nueva funcionalidad a la aplicación. Esta funcionalidad es
usar la librería AngularJS, para mejorar de esta forma el HTML.
9.4.2.2 Solución
En primer lugar, es el coordinador del grupo quien decide si se lleva a cabo la
incorporación de la nueva funcionalidad, analizando el impacto que tendría el
proyecto, analizando los posibles riesgos que puedan surgir, llegando finalmente a la
conclusión si se hace o no.
Si el coordinador opta por añadir la nueva funcionalidad, este deberá de crear la
tarea y/o subtareas correspondientes para la realización de dicha funcionalidad,
asignándole a dicha tareas los recursos que él estime necesarios.
El desarrollador al que le has sido asignada la tarea, deberá de crear una rama
correspondiente, uniéndola finalmente cuando la tarea asignada esté desarrollada
completamente.
57
10 Gestión de liberaciones, despliegue y entregas
10.1 Procedimientos En el siguiente apartado vamos a describir los procedimientos necesarios para la
gestión de liberaciones, despliegue y entregas desde un punto de vista general, es
decir, aplicable a cualquier proyecto y no exclusivamente al nuestro.
10.1.1 Entregables de un proyecto
1. Documentación del software
Plan de proyecto
Informes de seguimiento
Especificación de requisitos
Documento de diseño
Plan de pruebas
Manuales de usuario
Toda la documentación será responsabilidad del equipo de desarrollo, se encargarán
de generar la documentación a lo largo de todo el proyecto, tanto de las versiones
iniciales como de las versiones corregidas o ampliadas.
2. Base de datos
Para la base de datos, finalizado el proceso de desarrollo y pruebas, se generarán unos
scripts de exportación e importación de manera que resulte creada y cargada con los
datos iniciales en el entorno donde sea desplegada para su entrega al cliente.
3. Aplicación
Código fuente
Software ejecutable
La aplicación para ser desplegada en un servidor de aplicaciones, será exportada en un
archivo que será desplegado en un servidor de aplicaciones. Se empaquetará el código
fuente hasta la versión liberada en la entrega.
58
10.1.2 Identificación de entregables
Para la identificación de cada una de las versiones se tendrá en cuenta una
clasificación según su impacto, resultando:
1. Versiones mayores: representan importantes despliegues de software y
hardware que introducen modificaciones importantes en la funcionalidad,
características técnicas, etc.
Versiones mayores: 1.0, 2.0, etc.
2. Versiones menores: que suelen implicar la corrección de varios errores
conocidos puntuales y que a menudo son modificaciones que vienen a
implementar de una manera correctamente documentada soluciones de
emergencia.
Versiones menores: 1.1, 1.2, 1.3, etc.
3. Versiones auxiliares: modificaciones que reparan de forma rápida un error
conocido.
Versiones auxiliares: 1.1.1, 1.1.2, etc.
10.1.3 Gestión de la publicación, la liberación y entrega
Ilustración 50: CICLO DE VIDA SOFTWARE [Referencia2]
59
1. El proceso preliminar viene dado hasta cuando son conocidos los requisitos,
dependencias y plazos, y son validados por el cliente. En este punto, se inicia el
desarrollo de la nueva entrega (release 1).
2. Una vez desarrollada y pasadas las pruebas iniciales de desarrollo, esta versión
será etiquetada en el repositorio, tag “release 1”. Será la versión que se
entregará al cliente.
3. El siguiente paso son las pruebas de aceptación. El programa es revisado para
verificar que cumple con los requisitos del cliente. Durante esta fase, el proceso
completo es documentado para tener en el futuro una base de conocimientos.
4. Si el producto es aceptado, se procederá al proceso de empaquetado y los
entregables serán generados como se indicó anteriormente. La versión será
liberada para ponerla a disposición del cliente desde un repositorio online.
5. Despliegue de la aplicación en el entorno del cliente. Se instalará la base de
datos y la aplicación en el entorno del cliente para su uso y disfrute.
6. Mantenimiento. Es posible que en este punto se corrijan errores o añadan
mejoras. Esto afectará a la liberación de nuevo software, la identificación se
hará de acuerdo a lo indicado anteriormente.
El desarrollo de las diferentes versiones se hará de acuerdo al ciclo de metodologías
ágiles.
Ilustración 51: CICLO DE VIDA ÁGIL [Referencia2]
60
10.1.4 Lugar y roles durante la entrega
La entrega se realizará en las dependencias del cliente y el software estará disponible
en plataformas online. Lo roles que podemos encontrar para la entrega son:
Director del proyecto: responsable de la ejecución del proyecto con capacidad
ejecutiva para tomar decisiones sobre el mismo acuerdo con el cliente.
Equipo de despliegue: ingenieros responsables de la puesta en producción de la
aplicación desarrollada.
Cliente: responsable de la financiación del proyecto con capacidad ejecutiva para
tomar decisiones sobre el mismo.
Usuario: usuario potencial del software a desarrollar en el proyecto con una visión
detallada, aunque puede que parcial, del modelo de negocio.
Responsable TIC del cliente: responsable del entorno tecnológico del cliente, sobre el
que se debe integrar el sistema a desarrollar.
10.2 Implementación
Las herramientas que se han usado para implementar el despliegue de la aplicación ha
sido Openshift. En los casos prácticos se entrará en detalle sobre los pasos que
tenemos que seguir para el despliegue. Los datos de acceso son:
1. Base de datos: MySQL
Hosting de despliegue: Openshift
https://resultados-visualizacion.rhcloud.com/phpmyadm
2. Servidor de aplicaciones: Apache Tomcat
Hosting de despliegue: Openshift
www.resultados-visualizacion.rhcloud.com
61
10.3 Caso Práctico
10.3.1 Enunciado
Una empresa desea migrar los servicios que utiliza exclusivamente en una red local,
quiere que sus datos de visualización de estadísticas sobre encuestas estén accesibles
para cualquier usuario, para ello desea externalizar el trabajo y traspasar su entorno
de producción al hosting en la nube Openshift. La aplicación actualmente se encuentra
desplegada en un servidor local Tomcat y persiste sobre una base de datos MySQL 5.5.
Realice las acciones necesarias para desplegar el entorno de producción en Openshift.
10.3.2 Solución
El primer paso que debemos realizar es registrarnos en la web de Openshift y crear los
servicios necesarios para que nuestra aplicación pueda desplegarse sin problema. Los
pasos necesarios serían:
1. Registrarnos en la web www.openshift.com
2. Creación de una nueva aplicación desde “Add Application…” y asignarle un
nombre dns que esté disponible. En nuestro caso será:
www.resultados-visualizacion.rhcloud.com
Ilustración 52: CREACIÓN DE UNA APLICACIÓN EN OPENSHIFT
62
3. Añadir los Cartridges “Tomcat 7” y “MySQL 5.5”
Ilustración 53: CREACIÓN DE APLICACIÓN EN OPENSHIFT
Una vez tenemos la aplicación y servicios necesarios creados, es el momento de
preparar la base de datos donde persiste la aplicación. Deberemos migrar los datos de
la base local y traspasarlos a la que hemos creado en Openshift. Para ello necesitamos:
1. Generar scripts de exportación (dumping)
Exportación de la base de datos desde el entorno de desarrollo:
mysqldump -uroot -pV3rY=$tR0nG=P@$$w0rd$ EGC-Frontend > C:\Create-
EGC-Frontend.sql
Ilustración 54: DUMPING BASE DE DATOS
63
Actualización del script generado. Añadimos los comandos necesarios para la
creación de la base de datos con sus usuarios y permisos correspondientes.
Ilustración 55: MODIFICACIÓN SCRIPT DE EXPORTACIÓN
2. Creación e importación de datos
Nos conectamos a la bd creada y creamos la instancia para nuestra aplicación.
Para ello ejecutaremos el script generado en el paso anterior:
URL: https://resultados-visualizacion.rhcloud.com/phpmyadmin/
Root User: admincUvSwWt
Root Password: LwzngldaD4Jn
64
Ilustración 56: CONSOLA PHPMYADMIN DE BD EN OPENSHIFT
Desde la pestaña “Importar” se podrá cargar el script generado anteriormente
para crear la base de datos y añadirle los datos que tenía en local.
Ya sólo nos queda exportar la aplicación y desplegarla en Openshift. Para este paso
debemos hacer lo siguiente:
1. Instalar GIT desde https://git-scm.com/downloads
2. Copiar url de la aplicación desplegada en OpenShift
Ilustración 57: URL REPOSITORY REMOTO OPENSHIFT
65
3. Clonar el repositorio remoto desde la consola GIT
Ilustración 58: CLONANDO REPOSITORIO REMOTO OPENSHIFT
4. De la carpeta del repositorio local clonado debemos eliminar el archivo “pom.xml”
y la carpeta “src” completa.
5. Exportar la aplicación desarrollada desde Eclipse para generar un .war
Ilustración 59: EXPORTAR APLICACIÓN EN ECLIPSE
6. Copiar el .war en la carpeta “webapp” que se encuentra en el repositorio local
clonado. Si renombramos como “ROOT.war” la aplicación se desplegará como
directorio raíz, de lo contrario, tomará el nombre que fichero como directorio de la
url de despliegue.
7. El último paso es subir el fichero ROOT.war a Openshit, para ello sólo debemos
hacer commit y push del fichero y se activarán los automatismos para que
automáticamente se despliegue la aplicación. En este procesos se detendrán los
servicios desplegados en Openshift, se instalará la aplicación Tomcat y se volverán
a iniciar los servicios MySQL y Tomcat.
66
11 Mapa de herramientas
11.1 Lista de herramientas
Spring
Es un Framework de software libre para Java que está
bastante extendido.
Es un Framework de inyección de dependencias y usa
programación orientada a aspectos.
Hibernate
Es una herramienta de software libre de mapeo objeto-
relacional para Java mediante archivos XML o
anotaciones en los beans de las entidades que permiten
establecer estas relaciones.
Java
Es un lenguaje de programación orientado a objetos,
concurrente y de propósito general, diseñado para tener
cuantas menos dependencias de implementación mejor.
Es el lenguaje que usaremos para el desarrollo de
nuestro subsistema.
JDK
Java Development Kit (JDK) es un software que provee
herramientas de desarrollo para la creación de
programas en Java.
Ilustración 63: JAVA DEVELOPMENT KIT
Ilustración 62: JAVA
Ilustración 61: HIBERNATE
Ilustración 60: SPRING
67
Maven
Es una herramienta software para la gestión y
construcción de proyectos en Java. Tiene un modelo de
configuración de construcción simple basado en XML.
Eclipse
Entorno de desarrollo de software libre que cuenta con
multitud de plug-ins.
Es el que usaremos ya que permite la integración con
Hibernate
JSON
Es un formato ligero para el intercambio de datos que
usaremos para intercambiar datos con otros subsistemas.
Git
Es una herramienta de software libre de control de
versiones distribuido, diseñado pensando en la eficiencia
y confiabilidad del mantenimiento de versiones de
grandes proyectos.
MySQL
Es un sistema de gestión de bases de datos relacional,
multihilo y multiusuario. Es el que usaremos para nuestro
subsistema.
Ilustración 68: MYSQL
Ilustración 67: GIT
Ilustración 66: JSON
Ilustración 65: ECLIPSE
Ilustración 64: MAVEN
68
Apache Tomcat
Es un servidor que funciona como contenedor web, de
servlets y JSP.
OpenShift
Es un producto de computación en la nube de software
libre. Sirve para desplegar nuestro subsistema en la
nube.
Jenkins
Es un software de integración continua de código abierto
escrita en Java. Soporta Git.
SonarQube
Es una plataforma para evaluar código fuente de
software libre y usa diversar herramientas de análisis de
código fuente.
Slack
Es una herramienta de comunicación empresarial con la
que crear canales, salas de chat y enviar mensajes
directos.
Ilustración 73: SLACK
Ilustración 72: SONARQUBE
Ilustración 71: JENKINS
Ilustración 70: OPENSHIFT
Ilustración 69: APACHE
69
11.2 Mapa de herramientas
Ilustración 74: MAPA DE HERRAMIENTAS
12 Conclusiones Durante el desarrollo del trabajo, el equipo ha podido comprobar que la mayor
dificultad que se puede encontrar de cara al desarrollo de cualquier aplicación
software es la organización entre los distintos grupos de desarrollo.
La integración con los demás subsistema que forman el proyecto de Agora@US ha
sido el principal problema, así como la utilización de diferentes tecnologías para su
desarrollo. Ha faltado una organización, antes de que cada subsistema empezará a
desarrollar nuevas funcionalidades en sus subsistemas correspondientes. Si esta
organización se hubiera llevado a cabo, el proceso de desarrollo y su posterior
integración hubiera sido más fácil.
Otro aspecto a destacar, ha sido el conocimiento de las nuevas herramientas
conocidas a lo largo del curso. Antes de empezar la asignatura de Evolución y Gestión
de la Configuración desconocíamos herramientas tan importantes de cara al mundo
empresarial, como puede ser un sistema de control de versiones como puede ser git, o
un servidor de integración continua como Jenkins.
70
Referencias
[1] Wiki EGC. https://1984.lsi.us.es/wiki-egc/index.php
[2] PayPal Developer. https://developer.paypal.com
[3] Angular Guide. https://docs.angularjs.org/guide
[4] Angular Developer. https://docs.angularjs.org/api
[5] Soluciones de desarrollo en general. http://stackoverflow.com/
[6] Ayuda para despliegue Openshift. https://forums.openshift.com/
[7] Clases teóricas Ingeniería de Requisitos (IR).
[8] Apartados de Integración Continua.
http://www.notodocodigo.com/blog/instalacion-y-primeros-pasos-con-jenkins/
[9] Apartados sobre Despliegue. http://www.dosideas.com/noticias/java/391-
automatizacion-de-despliegues-ino-mas-dolores-de-cabeza.html
