Archivo historico de la wiki de EGC

Contenido archivado y de solo lectura, importado de la wiki original en julio de 2026. Puede contener enlaces rotos y material obsoleto.

Creación Administración Votaciones 1617

Aspectos organizativos

Miembros

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.

Opera

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

Gestión del código

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

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.

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:

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.

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.

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.

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.