Equipo de integración general - 17 18 - G1

De Wiki de EGC
Saltar a: navegación, buscar

Miembros

  • Suriel Aido Teruel - suraidterarrobaalum.us.es
  • Paula Balsera Martínez - paubalmararrobaalum.us.es
  • Juan Jiménez Gutiérrez - juajimgui1arrobaalum.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:

  1. Si es una tarea:
    1. Si es nueva:
      1. Asignar prioridad: Critical, High, Medium, Low.
      2. Asignar temática: Cada grupo elegirá los tipos de tareas que tratará. Ej: Documentación, Base de Datos…
      3. Asignar estado: New, Started, Fixed, Verified, Wontfix, Duplicate.
      4. Asignar encargados del Issue.
      5. Asignar el Issue a un proyecto a la columna que corresponda: TO DO, En progreso, En espera/Con problemas, En revisión, Hecho.
    2. Si no es nueva:
      1. Introducir comentario de avance, explicando lo que se ha hecho.
      2. Actualizar etiquetas.
      3. Actualizar encargados.
      4. Actualizar en el proyecto que corresponda.
      5. Si ha terminado, introducir comentario de cierre y cerrar el Issue
  2. Si es un bug:
    1. Si es nuevo:
      1. Asignar etiqueta Bug.
      2. Asignar prioridad: Critical, High, Medium, Low.
      3. Asignar temática: Cada grupo elegirá los tipos de tareas que tratará. Ej: Documentación, Base de Datos…
      4. Asignar estado: New, Started, Fixed, Verified, Wontfix, Duplicate.
      5. Asignar encargados del Issue.
      6. Asignar el Issue a un proyecto a la columna que corresponda: TO DO, En progreso, En espera/Con problemas, En revisión, Hecho.
    2. Si no es nuevo:
      1. Introducir comentario de avance, explicando lo que se ha hecho.
      2. Actualizar etiquetas.
      3. Actualizar encargados.
      4. Actualizar en el proyecto que corresponda.
      5. Si ha terminado, introducir comentario de cierre y cerrar el Issue.
  3. Si es un cambio:
    1. Si es nuevo:
      1. Asignar etiqueta Cambio/Mejora.
      2. Asignar prioridad: Critical, High, Medium, Low.
      3. Asignar temática: Cada grupo elegirá los tipos de tareas que tratará. Ej: Documentación, Base de Datos…
      4. Asignar estado: New, Started, Fixed, Verified, Wontfix, Duplicate.
      5. Asignar encargados del Issue.
      6. Asignar el Issue a un proyecto a la columna que corresponda: TO DO, En progreso, En espera/Con problemas, En revisión, Hecho.
    2. Si no es nuevo:
      1. Asignar etiqueta Accepted en caso de ser aceptado.
      2. Introducir comentario de avance, explicando lo que se ha hecho.
      3. Actualizar etiquetas.
      4. Actualizar encargados.
      5. Actualizar en el proyecto que corresponda.
      6. Si ha terminado, introducir comentario de cierre y cerrar el Issue.

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:

  1. Cada grupo que desee plantear un cambio, deberá plantearlo antes dentro de su grupo.
  2. Si se rechaza termina el proceso, y si se acepta se traslada dicho cambio al Equipo de Integración.
  3. 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.