Revisión actual del 01:00 11 ene 2017

Aspectos organizativos

Miembros

• Rafael Trujillo González: Project Manager
• Ismael de la Ossa Puerto: Software Developer
• Armando Garrido Castro: Software Developer
• Javier Pallarés Saavedra: Software Developer
• Alejandro Tortolero Niza: Software Developer

Actas

Repositorio

Como repositorio de código de nuestro subsistema usaremos Github, nuestro repositorio se encuentra dentro de la organización AgoraUS-G1-1617 para una mejor localización del resto de subsistemas.

• Enlace a GitHub.

Opera

Aqui podemos encontrar la página de grupo dentro del portal Opera donde se realizaran las entregas correspondientes.

• Enlace a Opera.

Gestión del código

Para la gestión dentro de Github se realizará utilizando dos ramas:

• Rama "development":

En esta rama se llevarán a cabo la mayor parte de los cambios en el proyecto. Aquí se añadirán las funcionalidad y mejoras que el grupo haya considerado oportuno.

• Rama "master":

En la rama master será utilizada solo para añadir los cambios realizados en la rama development que se hayan realizado de manera exitosa. De esta forma la rama master contendrá versiones estables del proyecto útiles para el despliegue remoto, como se explicará posteriormente.

Gestión de incidencias

Como gestor de incidencias utilizaremos las Issues que nos proporciona GitHub. El procedimiento para llevar a cabo la gestión de una incidencia será el siguiente.

Cada vez que un miembro del equipo descubra una incidencia, ya sean fallos en el sistema, mejoras o comentarios, este deberá de crear una issue que contendrá la siguiente información:

• Título: Debe ser claro y que acote bien en problema a tartar.
• Descripción: Aquí se tendrá que detallar la incidencia a tratar de manera que quede el texto sea claro y aporte información suficiente para poder cumplir el objetivo de manera correcta. Se deberá indicar, si fuese necesario en caso de un bug del sistema, la url del fichero donde se encuentre el fallo para una mejor localización del mismo.
• Asignación de la Issue: Cada issue debe ser asignada a un miembro del grupo, de esta forma siempre se conocerá quien se encarga de cada issue. Normalmente las issues serán autoasignada debido al que el tamaño del proyecto no es muy grande y todos los miembros del grupo conocen todos los detalles y funcionalidades del proyecto.
• Etiquetas: Se utilizarán etiquetas en función del tipo de issue que se vaya a abrir.

Enhancement:
Mejora, esta etiqueta será utilizada cada vez que la issue sea creada debido a una mejora de funcionalidad del sistema.

Bug:
Fallo, se utilizará con el fin de indicar fallos encontrados en el sistema.

Help wanted:
Ayuda, esta etiqueta tiene el fin de pedir ayuda a otros miembros del equipo cada vez que no se conozca el funcionamiento de algún
módulo del proyecto. Cada issue deberá ser comentada por otro miembro del grupo resolviendo la duda.

Question:
Pregunta, la utilizarán los miembros del grupo al abrir una issue cada vez que estos quieran conocer el estado de algún módulo
del proyecto o informarse sobre lo realizado en algún otro cambio, en este caso se deberá enlazar con commit que contenga el cambio.

Una vez una se haya solucionado lo requerido en la issue se procederá al cierre de esta. El miembro del equipo que se disponga a cerrar la issue del grupo deberá aportar una descripción de lo realizado y añadir un enlace, si fuese necesario, al fichero o ficheros que contenga los cambios realizados.

Automatización de pruebas

Nos hemos decantado por la herramienta travis CI a la hora de automatizar las pruebas.

Cada vez que se detecte un commit travis se encargará de poblar la base de datos para ejecutar los test oportunos. Una vez finalizado los test, travis nos informará de los resultados obtenidos.

• Travis.

Integración continua

Para llevar a cabo la integración continua se utilizarán las herramientas Dockers, Maven y Jenkins.

Esta integración continua consta de 3 partes:

Fase make: En esta primera fase se descargará el código cada vez que se realicen cambios en la rama "master" de GitHub y se preparará para ser desplegado.

• Jenkins.

Fase beta: Esta segunda fase se encuentra automatizada, se lleva acabo cada vez que finaliza la fase make. Consiste en eliminar la aplicación que se encuentre desplegada y a partir del código de la fase make lanzarla de nuevo.

• Enlace a modulo desplegado en fase Beta.

Fase stable: Por otro lado la fase stable se desplegará de forma manual para así asegurar el funcionamiento y la integración con el resto de subsistemas.

• Enlace a modulo desplegado en fase Stable.