Diferencia entre revisiones de «Equipo de integración general - 17 18 - G1»
(→Formateo de commits) |
(→Miembros) |
||
Línea 2: | Línea 2: | ||
<ul> | <ul> | ||
− | <li>Suriel Aido Teruel</li> | + | <li>Suriel Aido Teruel - '''suraidter'''''arroba'''''alum.us.es''' </li> |
− | <li>Paula Balsera Martínez</li> | + | <li>Paula Balsera Martínez - '''paubalmar'''''arroba'''''alum.us.es''' </li> |
− | <li>Juan Jiménez Gutiérrez</li> | + | <li>Juan Jiménez Gutiérrez - '''juajimgui'''''arroba'''''alum.us.es''' </li> |
− | <li>Álvaro Domínguez Núñez</li> | + | <li>Álvaro Domínguez Núñez - '''alvdomnun'''''arroba'''''alum.us.es''' </li> |
− | <li>Miguel Ángel Baños Carretón</li> | + | <li>Miguel Ángel Baños Carretón - '''migbancar'''''arroba'''''alum.us.es''' </li> |
− | <li>David Posada Mena</li> | + | <li>David Posada Mena - '''davposmen'''''arroba'''''alum.us.es''' </li> |
− | <li>Augusto José Rivero Carmona</li> | + | <li>Augusto José Rivero Carmona - '''augrivcar'''''arroba'''''alum.us.es''' </li> |
+ | <br><br/> | ||
+ | Cómo interpretar esta dirección: cambiar ''arroba'' por "@" | ||
</ul> | </ul> | ||
Revisión del 12:08 7 dic 2017
Contenido
Miembros
- Suriel Aido Teruel - suraidterarrobaalum.us.es
- Paula Balsera Martínez - paubalmararrobaalum.us.es
- Juan Jiménez Gutiérrez - juajimguiarrobaalum.us.es
- Álvaro Domínguez Núñez - alvdomnunarrobaalum.us.es
- Miguel Ángel Baños Carretón - migbancararrobaalum.us.es
- David Posada Mena - davposmenarrobaalum.us.es
- Augusto José Rivero Carmona - augrivcararrobaalum.us.es
Cómo interpretar esta dirección: cambiar arroba por "@"
Repositorio de GitHub
El repositorio de GitHub del equipo será accesible en este enlace Cualquier cambio o documentación importante añadida a él se notificará a los coordinadores en el momento.
Entorno de trabajo
La máquina virtual de desarrollo (descarga aquí) hace posible que cada equipo de desarrollo pueda trabajar de manera local sin depender del resto de subsistemas. Se han asignado los siguientes puertos a cada subsistema:
Subsistema | Puerto |
---|---|
Autenticación | 52000 |
Administración de votaciones | 52001 |
Administración de censos | 52002 |
Cabina de votaciones | 52003 |
Cabina de Télegram | 52004 |
Cabina de Slack | 52005 |
Almacenamiento de votos | 52006 |
Recuento de votos | 52007 |
Visualización de resultados | 52008 |
Gestion de registro | 52009 |
Esta configuración de puertos se mantiene en el entorno de despliegue. Para acceder a algún servicio la URL consiste en http://localhost:<puerto>. Ej: http://localhost:52000 para acceder a la autenticación.
Subsistemas desplegados
- Wordpress (Portal Jornadas)
Configuración de la máquina
Nota: la máquina ha sido exportada como un servicio virtualizado de VirtualBox.
- Número de CPUs: 2
- RAM Reservada: 1536MB
- SO: Debian 9 (Stretch)
- Usuario: egc
- Contraseña: egc
- Tiene Docker y Docker Compose instalados
Opera
El proyecto en Opera del grupo es accesible desde el siguiente enlace
Formatos y procedimientos
De carácter optativo hasta el 30/11/17 y obligatorio a partir de dicha fecha distinguimos el formateado de los siguientes elementos:
Formato para detallar tecnologías elegidas
Subsistema: <Nombre del subsistema/equipo> Lenguaje/Herramienta: <Lenguaje/herramienta escogida y versión> Sistema de gestión de bibliotecas: <Herramienta que se usa para añadir bibliotecas/dependencias> (Ej: Java->Maven, Python->pip) Bibliotecas: <Listado de bibliotecas usadas en el desarrollo.> Nombre_Biblioteca1: <versión> Necesita Base de datos: <Sí/No> (En caso afirmativo explicar cuál se está empleando y su versión)
Formato para detallar API
Cada subgrupo tiene total libertad para definir dicho formato, siendo de carácter imperativo, no obstante, el informar sobre su funcionamiento al resto de grupos que lo soliciten.
Formato para incidencias, cambios y tareas
Usaremos en GitHub los issues para referenciar tanto tareas a hacer por el grupo como los posibles cambios e incidencias. El formato general será el siguiente: Título del Issue: Descripción general del mismo. Ej: Elaboración del documento de URIs y Funcionalidades. Etiquetas: Etiquetas de GitHub seguidas según el algoritmo de etiquetación (explicado más abajo). Descripción: Descripción detallada del Issue. Ej: Redacción del documento en el que se explicarán las URIs asignadas a cada subsistema así como las funciones que deberá desempeñar cada uno. El algoritmo para etiquetar y tratar cada Issue es el siguiente:
- Si es una tarea:
- Si es nueva:
- Asignar prioridad: Critical, High, Medium, Low.
- Asignar temática: Cada grupo elegirá los tipos de tareas que tratará. Ej: Documentación, Base de Datos…
- Asignar estado: New, Started, Fixed, Verified, Wontfix, Duplicate.
- Asignar encargados del Issue.
- Asignar el Issue a un proyecto a la columna que corresponda: TO DO, En progreso, En espera/Con problemas, En revisión, Hecho.
- Si no es nueva:
- Introducir comentario de avance, explicando lo que se ha hecho.
- Actualizar etiquetas.
- Actualizar encargados.
- Actualizar en el proyecto que corresponda.
- Si ha terminado, introducir comentario de cierre y cerrar el Issue
- Si es nueva:
- Si es un bug:
- Si es nuevo:
- Asignar etiqueta Bug.
- Asignar prioridad: Critical, High, Medium, Low.
- Asignar temática: Cada grupo elegirá los tipos de tareas que tratará. Ej: Documentación, Base de Datos…
- Asignar estado: New, Started, Fixed, Verified, Wontfix, Duplicate.
- Asignar encargados del Issue.
- Asignar el Issue a un proyecto a la columna que corresponda: TO DO, En progreso, En espera/Con problemas, En revisión, Hecho.
- Si no es nuevo:
- Introducir comentario de avance, explicando lo que se ha hecho.
- Actualizar etiquetas.
- Actualizar encargados.
- Actualizar en el proyecto que corresponda.
- Si ha terminado, introducir comentario de cierre y cerrar el Issue.
- Si es nuevo:
- Si es un cambio:
- Si es nuevo:
- Asignar etiqueta Cambio/Mejora.
- Asignar prioridad: Critical, High, Medium, Low.
- Asignar temática: Cada grupo elegirá los tipos de tareas que tratará. Ej: Documentación, Base de Datos…
- Asignar estado: New, Started, Fixed, Verified, Wontfix, Duplicate.
- Asignar encargados del Issue.
- Asignar el Issue a un proyecto a la columna que corresponda: TO DO, En progreso, En espera/Con problemas, En revisión, Hecho.
- Si no es nuevo:
- Asignar etiqueta Accepted en caso de ser aceptado.
- Introducir comentario de avance, explicando lo que se ha hecho.
- Actualizar etiquetas.
- Actualizar encargados.
- Actualizar en el proyecto que corresponda.
- Si ha terminado, introducir comentario de cierre y cerrar el Issue.
- Si es nuevo:
Formateo de commits
Para gestionar el código, se harán commits y push en dichos repositorios siguiendo las pautas especificadas en las diapositivas de clase durante la explicación de la gestión del código fuente ( enlace). A partir de las versiones finales desarrolladas por cada grupo en cada iteración, los integrantes del equipo de Integración indicarán una semana antes de cada milestone si es necesario subir con antelación el avance funcional hecho por cada subgrupo al repositorio del Equipo de Arquitectura e Integración para disponer del código hecho.
- Título: Descripción breve y concisa del commit. Ej: Nuevo: Documento de URIs y funcionalidades
- Descripción del commit: Descripción detallada de lo incluido en el commit. Ej: Se ha incluido la primera versión del documento de URIs y funcionalidades donde se explican los endpoints básicos de cada API así como las funcionalidades de cada subgrupo
- Pie del commit: Número del Issue al que referencia
Procedimiento de gestión de cambios
Para la gestión de cambios, se procederá de la siguiente manera:
- Cada grupo que desee plantear un cambio, deberá plantearlo antes dentro de su grupo.
- Si se rechaza termina el proceso, y si se acepta se traslada dicho cambio al Equipo de Integración.
- El Equipo de Integración valorará dicho cambio. Si lo rechaza el cambio no se aplicará, y si lo acepta se comunicará a los subgrupos de dicho cambio y se actualizarán los elementos de documentación pertinentes.
Para representar cada cambio en GitHub, se creará un Issue con el formato expresado en el algoritmo de la sección “Formato para incidencias, cambios y tareas”.
Procedimiento de gestión de tareas, cambios e incidendias
Para la gestión de las incidencias, se usarán los Issues que GitHub permite gestionar en cada repositorio. El uso de estos Issues está basado en las diapositivas de clase de (Gestión de Incidencias), haciéndose de la siguiente manera:
- Cada grupo es responsable de la gestión de sus Issues.
- Cada Issue representará una tarea o problema encontrado por el grupo.
- Cada Issue será situado en un proyecto interno al repositorio, siendo actualizado entre las fases TO DO, En progreso, En espera/Con problemas, En revisión y Hecho según corresponda a su avance.
- Para cada avance o actualización de un Issue, se hará un comentario dentro de éste especificando el cambio hecho, indicando su motivo si procede.
- Una vez terminado un Issue se debe cerrar con un comentario de cierre y cerrándolo en sí mismo tras colocarlo en la columna Hecho se su proyecto correspondiente.
- Cada Issue será etiquetado en función de su temática, prioridad, estado y tipo. Los tipos son Cambio/Mejora y Bug, que sólo se incluirán en dichos casos. Las temáticas son libres para cada subgrupo. Las prioridades son Critical, High, Medium y Low, y los estados son New, Accepted (sólo para cambios), Started, Fixed, Verified, Duplicate (cambios y bugs) y Wontfix (cambios y bugs).
- Las etiquetas de cada Issue deben ser actualizadas durante el avance del mismo, con su correspondiente actualización en el proyecto y su comentario pertinente.