Equipo de integración general - 17 18 - G1

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

Se han asignado los siguientes puertos a cada subsistema:

Acceso a cada uno de los subsistemas

Como se indica en los documentos de proceso de entrega de WordPress y Votaciones, el objetivo es que cada subsistema desplegado contenga variables de entorno de las URLs de otros subsistemas. Sin embargo, y por si hay grupos que no llegan a implementar las variables de entorno, se listan las URLs actuales donde se desplegará cada uno de los subsistemas. Estas URLs son de utilidad para subsistemas que deban consumir APIs o realizar redirecciones hacia otros subsistemas.

Acceso a los plugin de Wordpress

Estado del servidor

Subsistemas actualmente desplegados en el servidor:

• Login
• Cabina Web
• Administración de Votaciones
• Recuento de votos
• Gestión de registro

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 llevar a cabo las tareas de gestión de cambios, código e incidencias, se hará uso de la plataforma GitHub, siguiendo las directrices expuestas en clase:

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 (index.html index.php/Teor%C3%ADa_-_17/18). 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. Los commits en local se harán libremente cuando el equipo estime oportuno, siendo necesario agruparlos en un push con un incremento de subversión en caso de implementar parte de una funcionalidad completa, o en un push con un incremento de versión en caso de implementar dicha funcionalidad al completo. En caso de ser requerido por el equipo de integración, se harán en su repositorio. El número de versionado y su nomenclatura se explican en el punto siguiente. Debido a la libertad de creación de commits, para poder agruparlos de forma más rápida a la hora de hacer un push en el servidor, se seguirá el formato siguiente:

• Título: Incluirá la palabra New o Update dependiendo si es un archivo nuevo o una actualización de uno existente, seguido de un título descriptivo del commit.
• Descripción: Contendrá una explicación más detalla del contenido del commit.
• Pie: Indicará el Issue al que hace referencia el Commit.

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 dentro del repositorio del subgrupo correspondiente (el que genera dicho cambio y los que se ven afectados por el mismo) con el formato expresado en el algoritmo de la sección “Formato para incidencias, cambios y tareas” La creación del issue dentro del repositorio X corresponde al subgrupo X y a nadie más.

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.

Directrices de gestión de dudas y documentación

El procedimiento a seguir para plantear y resolver dudas al equipo de integración es el siguiente:

1. Plantear la duda dentro del grupo de trabajo.
2. Contactar con el equipo de integración para indicarle la duda.
3. El equipo de integración creará el issue en su repositorio indicando la duda o incidencia.
4. El equipo de integración asignará a alguien para el seguimiento de dicha duda y su resolución junto con el equipo que la ha planteado.

Respecto al desarrollo de documentos, éstos seguirán el siguiente formato:

• Si se tratan de documentos cuyo contenido sea código, la nomenclatura del archivo subido será: NombreSubgrupo-versión. Las versiones se incrementarán cada vez que el subsistema reciba una nueva funcionalidad completa (por ejemplo el proceso de creación completo de una votación). Las subversiones se incrementarán cada vez que se añada una nueva parte a un proceso funcional completo (por ejemplo añadir el formulario de creación de una votación), y los números de parche se incrementarán cada vez que se solucione un bug dentro de dicha subversión.
• En el caso de documentación de otro tipo, se seguirá el esquema NombreSubgrupo-NombreDocumento, con el fin de aclarar el contenido de dicho archivo.

Independientemente del tipo de documento, a la hora de subirlo al repositorio del Equipo de Integración, deberá hacerse en la carpeta especificada por éste cuando se solicite el documento.

Directrices de gestión de ramas

Cada grupo debe tener en su repositorio una rama principal, con toda la documentación, a partir de la cual saldrán las siguientes ramas secundarias opcionales:

• Ramas que representan diferentes funcionalidades del grupo. Por ejemplo: Scripts MySQL, Entornos…
• Ramas personales de cada miembro del grupo, según estime el coordinador de éste.

Es responsabilidad del coordinador del grupo tanto el decidir qué ramas opcionales usar, si expandirlas con más de ellas, y hacer merge de las mismas cuando se complete cada ciclo del milestone si lo considera oportuno.

Dudas resueltas e información relevante

En esta sección se añadirá toda información referente a problemas concretos y dudas referentes a los subgrupos que pudieran ser de utilidad para el resto a fin de agilizar más las comunicaciones y relaciones entre subgrupos e Integración.