Wiki de EGC - Contribuciones del usuario [es]

Equipo de integración general - 17 18 - G1

2018-01-14T16:44:08Z

Davposmen:

== Miembros ==

<ul>
<li>Suriel Aido Teruel - '''suraidter'''''arroba'''''alum.us.es''' </li>
<li>Paula Balsera Martínez - '''paubalmar'''''arroba'''''alum.us.es''' </li>
<li>Juan Jiménez Gutiérrez - '''juajimgui1'''''arroba'''''alum.us.es''' </li>
<li>Álvaro Domínguez Núñez - '''alvdomnun'''''arroba'''''alum.us.es''' </li>
<li>Miguel Ángel Baños Carretón - '''migbancar'''''arroba'''''alum.us.es''' </li>
<li>David Posada Mena - '''davposmen'''''arroba'''''alum.us.es''' </li>
<li>Augusto José Rivero Carmona - '''augrivcar'''''arroba'''''alum.us.es''' </li>
 
Cómo interpretar esta dirección: cambiar ''arroba'' por "@"
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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:

{| class="wikitable"
!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
|}

== 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.

{| class="wikitable"
!Subsistema
!URL
!Desplegado
|-
|WordPress
|g1wordpress.egc.duckdns.org
|Si
|-
|Login
|g1login.egc.duckdns.org
|Si
|-
|Cabina Web
|g1cabinaweb.egc.duckdns.org
|Si
|-
|Admin. Votaciones
|g1admvotes.egc.duckdns.org
|Si
|-
|Admin. Censos
|g1admcensos.egc.duckdns.org
|No
|-
|Visual. Resultados
|g1vresultados.egc.duckdns.org
|No
|-
|Cabina Telegram
|g1cabinatelegram.egc.duckdns.org
|No
|-
|Cabina Slack
|g1cabinaslack.egc.duckdns.org
|No
|-
|Almac. Votos
|g1almvotos.egc.duckdns.org
|No
|-
|Recuento Votos
|g1recvotos.egc.duckdns.org
|Si
|}

== Acceso a los plugin de Wordpress ==
{| class="wikitable"
!Plugin
!URL
!Desplegado
|-
|Redes Sociales
|
|No
|-
|Visualización de resultados
|
|No
|-
|Gestión de programa
|
|No
|-
|Gestión de registro
|
|Si
|-
|Gestión de generación estática
|
|No
|-
|Gestión de visualización de programa
|
|No
|}

== Estado del servidor ==

Subsistemas actualmente desplegados en el servidor:

<ul>
<li>Login</li>
<li>Cabina Web</li>
<li>Administración de Votaciones</li>
<li>Recuento de votos</li>
<li>Gestión de registro</li>
</ul>

== Opera ==

El proyecto en Opera del grupo es accesible desde el siguiente [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 (http://1984.lsi.us.es/wikiegc/
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:
#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 '''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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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:
# Plantear la duda dentro del grupo de trabajo.
# Contactar con el equipo de integración para indicarle la duda.
# El equipo de integración creará el issue en su repositorio indicando la duda o incidencia.
# 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.

Equipo de integración general - 17 18 - G1

2018-01-14T16:25:21Z

Davposmen: /* Estado del servidor */

== Miembros ==

<ul>
<li>Suriel Aido Teruel - '''suraidter'''''arroba'''''alum.us.es''' </li>
<li>Paula Balsera Martínez - '''paubalmar'''''arroba'''''alum.us.es''' </li>
<li>Juan Jiménez Gutiérrez - '''juajimgui1'''''arroba'''''alum.us.es''' </li>
<li>Álvaro Domínguez Núñez - '''alvdomnun'''''arroba'''''alum.us.es''' </li>
<li>Miguel Ángel Baños Carretón - '''migbancar'''''arroba'''''alum.us.es''' </li>
<li>David Posada Mena - '''davposmen'''''arroba'''''alum.us.es''' </li>
<li>Augusto José Rivero Carmona - '''augrivcar'''''arroba'''''alum.us.es''' </li>
 
Cómo interpretar esta dirección: cambiar ''arroba'' por "@"
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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:

{| class="wikitable"
!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
|}

== 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.

{| class="wikitable"
!Subsistema
!URL
!Desplegado
|-
|WordPress
|g1wordpress.egc.duckdns.org
|Si
|-
|Login
|g1login.egc.duckdns.org
|Si
|-
|Cabina Web
|g1cabinaweb.egc.duckdns.org
|Si
|-
|Admin. Votaciones
|g1admvotes.egc.duckdns.org
|Si
|-
|Admin. Censos
|g1admcensos.egc.duckdns.org
|No
|-
|Visual. Resultados
|g1vresultados.egc.duckdns.org
|No
|-
|Cabina Telegram
|g1cabinatelegram.egc.duckdns.org
|No
|-
|Cabina Slack
|g1cabinaslack.egc.duckdns.org
|No
|-
|Almac. Votos
|g1almvotos.egc.duckdns.org
|No
|-
|Recuento Votos
|g1recvotos.egc.duckdns.org
|Si
|}

== Estado del servidor ==

Subsistemas actualmente desplegados en el servidor:

<ul>
<li>Login</li>
<li>Cabina Web</li>
<li>Administración de Votaciones</li>
<li>Recuento de votos</li>
</ul>

== Opera ==

El proyecto en Opera del grupo es accesible desde el siguiente [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 (http://1984.lsi.us.es/wikiegc/
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:
#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 '''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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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:
# Plantear la duda dentro del grupo de trabajo.
# Contactar con el equipo de integración para indicarle la duda.
# El equipo de integración creará el issue en su repositorio indicando la duda o incidencia.
# 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.

Equipo de integración general - 17 18 - G1

2018-01-14T16:23:08Z

Davposmen: /* Acceso a cada uno de los subsistemas */

== Miembros ==

<ul>
<li>Suriel Aido Teruel - '''suraidter'''''arroba'''''alum.us.es''' </li>
<li>Paula Balsera Martínez - '''paubalmar'''''arroba'''''alum.us.es''' </li>
<li>Juan Jiménez Gutiérrez - '''juajimgui1'''''arroba'''''alum.us.es''' </li>
<li>Álvaro Domínguez Núñez - '''alvdomnun'''''arroba'''''alum.us.es''' </li>
<li>Miguel Ángel Baños Carretón - '''migbancar'''''arroba'''''alum.us.es''' </li>
<li>David Posada Mena - '''davposmen'''''arroba'''''alum.us.es''' </li>
<li>Augusto José Rivero Carmona - '''augrivcar'''''arroba'''''alum.us.es''' </li>
 
Cómo interpretar esta dirección: cambiar ''arroba'' por "@"
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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:

{| class="wikitable"
!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
|}

== 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.

{| class="wikitable"
!Subsistema
!URL
!Desplegado
|-
|WordPress
|g1wordpress.egc.duckdns.org
|Si
|-
|Login
|g1login.egc.duckdns.org
|Si
|-
|Cabina Web
|g1cabinaweb.egc.duckdns.org
|Si
|-
|Admin. Votaciones
|g1admvotes.egc.duckdns.org
|Si
|-
|Admin. Censos
|g1admcensos.egc.duckdns.org
|No
|-
|Visual. Resultados
|g1vresultados.egc.duckdns.org
|No
|-
|Cabina Telegram
|g1cabinatelegram.egc.duckdns.org
|No
|-
|Cabina Slack
|g1cabinaslack.egc.duckdns.org
|No
|-
|Almac. Votos
|g1almvotos.egc.duckdns.org
|No
|-
|Recuento Votos
|g1recvotos.egc.duckdns.org
|Si
|}

== Estado del servidor ==

Subsistemas actualmente desplegados en el servidor:

<ul>
<li>Login</li>
<li>Cabina Web</li>
<li>Administración de Votos</li>
</ul>

== Opera ==

El proyecto en Opera del grupo es accesible desde el siguiente [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 (http://1984.lsi.us.es/wikiegc/
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:
#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 '''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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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:
# Plantear la duda dentro del grupo de trabajo.
# Contactar con el equipo de integración para indicarle la duda.
# El equipo de integración creará el issue en su repositorio indicando la duda o incidencia.
# 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.

Equipo de integración general - 17 18 - G1

2017-12-23T15:54:55Z

Davposmen: /* Directrices de gestión de ramas */

== Miembros ==

<ul>
<li>Suriel Aido Teruel - '''suraidter'''''arroba'''''alum.us.es''' </li>
<li>Paula Balsera Martínez - '''paubalmar'''''arroba'''''alum.us.es''' </li>
<li>Juan Jiménez Gutiérrez - '''juajimgui1'''''arroba'''''alum.us.es''' </li>
<li>Álvaro Domínguez Núñez - '''alvdomnun'''''arroba'''''alum.us.es''' </li>
<li>Miguel Ángel Baños Carretón - '''migbancar'''''arroba'''''alum.us.es''' </li>
<li>David Posada Mena - '''davposmen'''''arroba'''''alum.us.es''' </li>
<li>Augusto José Rivero Carmona - '''augrivcar'''''arroba'''''alum.us.es''' </li>
 
Cómo interpretar esta dirección: cambiar ''arroba'' por "@"
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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:

{| class="wikitable"
!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 <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:52000</nowiki> para acceder a la autenticación.

== Opera ==

El proyecto en Opera del grupo es accesible desde el siguiente [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 (http://1984.lsi.us.es/wikiegc/
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:
#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 '''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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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:
# Plantear la duda dentro del grupo de trabajo.
# Contactar con el equipo de integración para indicarle la duda.
# El equipo de integración creará el issue en su repositorio indicando la duda o incidencia.
# 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.

Equipo de integración general - 17 18 - G1

2017-12-23T15:53:08Z

Davposmen: /* Formateo de commits */

== Miembros ==

<ul>
<li>Suriel Aido Teruel - '''suraidter'''''arroba'''''alum.us.es''' </li>
<li>Paula Balsera Martínez - '''paubalmar'''''arroba'''''alum.us.es''' </li>
<li>Juan Jiménez Gutiérrez - '''juajimgui1'''''arroba'''''alum.us.es''' </li>
<li>Álvaro Domínguez Núñez - '''alvdomnun'''''arroba'''''alum.us.es''' </li>
<li>Miguel Ángel Baños Carretón - '''migbancar'''''arroba'''''alum.us.es''' </li>
<li>David Posada Mena - '''davposmen'''''arroba'''''alum.us.es''' </li>
<li>Augusto José Rivero Carmona - '''augrivcar'''''arroba'''''alum.us.es''' </li>
 
Cómo interpretar esta dirección: cambiar ''arroba'' por "@"
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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:

{| class="wikitable"
!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 <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:52000</nowiki> para acceder a la autenticación.

== Opera ==

El proyecto en Opera del grupo es accesible desde el siguiente [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 (http://1984.lsi.us.es/wikiegc/
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:
#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 '''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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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:
# Plantear la duda dentro del grupo de trabajo.
# Contactar con el equipo de integración para indicarle la duda.
# El equipo de integración creará el issue en su repositorio indicando la duda o incidencia.
# 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, 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.

Equipo de integración general - 17 18 - G1

2017-12-17T13:34:37Z

Davposmen:

== Miembros ==

<ul>
<li>Suriel Aido Teruel - '''suraidter'''''arroba'''''alum.us.es''' </li>
<li>Paula Balsera Martínez - '''paubalmar'''''arroba'''''alum.us.es''' </li>
<li>Juan Jiménez Gutiérrez - '''juajimgui1'''''arroba'''''alum.us.es''' </li>
<li>Álvaro Domínguez Núñez - '''alvdomnun'''''arroba'''''alum.us.es''' </li>
<li>Miguel Ángel Baños Carretón - '''migbancar'''''arroba'''''alum.us.es''' </li>
<li>David Posada Mena - '''davposmen'''''arroba'''''alum.us.es''' </li>
<li>Augusto José Rivero Carmona - '''augrivcar'''''arroba'''''alum.us.es''' </li>
 
Cómo interpretar esta dirección: cambiar ''arroba'' por "@"
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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:

{| class="wikitable"
!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 <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:52000</nowiki> para acceder a la autenticación.

== Opera ==

El proyecto en Opera del grupo es accesible desde el siguiente [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 ( [http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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 '''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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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:
# Plantear la duda dentro del grupo de trabajo.
# Contactar con el equipo de integración para indicarle la duda.
# El equipo de integración creará el issue en su repositorio indicando la duda o incidencia.
# 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, 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.

Equipo de integración general - 17 18 - G1

2017-12-16T16:56:17Z

Davposmen:

== Miembros ==

<ul>
<li>Suriel Aido Teruel - '''suraidter'''''arroba'''''alum.us.es''' </li>
<li>Paula Balsera Martínez - '''paubalmar'''''arroba'''''alum.us.es''' </li>
<li>Juan Jiménez Gutiérrez - '''juajimgui1'''''arroba'''''alum.us.es''' </li>
<li>Álvaro Domínguez Núñez - '''alvdomnun'''''arroba'''''alum.us.es''' </li>
<li>Miguel Ángel Baños Carretón - '''migbancar'''''arroba'''''alum.us.es''' </li>
<li>David Posada Mena - '''davposmen'''''arroba'''''alum.us.es''' </li>
<li>Augusto José Rivero Carmona - '''augrivcar'''''arroba'''''alum.us.es''' </li>
 
Cómo interpretar esta dirección: cambiar ''arroba'' por "@"
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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:

{| class="wikitable"
!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 <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:52000</nowiki> para acceder a la autenticación.

== Opera ==

El proyecto en Opera del grupo es accesible desde el siguiente [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 ( [http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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 '''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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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:
# Plantear la duda dentro del grupo de trabajo.
# Contactar con el equipo de integración para indicarle la duda.
# El equipo de integración creará el issue en su repositorio indicando la duda o incidencia.
# 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.

== 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.

Equipo de integración general - 17 18 - G1

2017-12-12T09:55:56Z

Davposmen: /* Entorno de trabajo */

== Miembros ==

<ul>
<li>Suriel Aido Teruel - '''suraidter'''''arroba'''''alum.us.es''' </li>
<li>Paula Balsera Martínez - '''paubalmar'''''arroba'''''alum.us.es''' </li>
<li>Juan Jiménez Gutiérrez - '''juajimgui1'''''arroba'''''alum.us.es''' </li>
<li>Álvaro Domínguez Núñez - '''alvdomnun'''''arroba'''''alum.us.es''' </li>
<li>Miguel Ángel Baños Carretón - '''migbancar'''''arroba'''''alum.us.es''' </li>
<li>David Posada Mena - '''davposmen'''''arroba'''''alum.us.es''' </li>
<li>Augusto José Rivero Carmona - '''augrivcar'''''arroba'''''alum.us.es''' </li>
 
Cómo interpretar esta dirección: cambiar ''arroba'' por "@"
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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:

{| class="wikitable"
!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 <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:52000</nowiki> para acceder a la autenticación.

== Opera ==

El proyecto en Opera del grupo es accesible desde el siguiente [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 ( [http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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 '''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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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:
# Plantear la duda dentro del grupo de trabajo.
# Contactar con el equipo de integración para indicarle la duda.
# El equipo de integración creará el issue en su repositorio indicando la duda o incidencia.
# 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.

Equipo de integración general - 17 18 - G1

2017-12-07T16:52:09Z

Davposmen: /* Formatos y procedimientos */

== Miembros ==

<ul>
<li>Suriel Aido Teruel - '''suraidter'''''arroba'''''alum.us.es''' </li>
<li>Paula Balsera Martínez - '''paubalmar'''''arroba'''''alum.us.es''' </li>
<li>Juan Jiménez Gutiérrez - '''juajimgui1'''''arroba'''''alum.us.es''' </li>
<li>Álvaro Domínguez Núñez - '''alvdomnun'''''arroba'''''alum.us.es''' </li>
<li>Miguel Ángel Baños Carretón - '''migbancar'''''arroba'''''alum.us.es''' </li>
<li>David Posada Mena - '''davposmen'''''arroba'''''alum.us.es''' </li>
<li>Augusto José Rivero Carmona - '''augrivcar'''''arroba'''''alum.us.es''' </li>
 
Cómo interpretar esta dirección: cambiar ''arroba'' por "@"
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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 [https://drive.google.com/file/d/1QcyMX2CTODWyq4KWQSWc259S-sidhe4f/view?usp=sharing 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:

{| class="wikitable"
!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 <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:52000</nowiki> 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 [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 ( [http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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 '''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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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:
# Plantear la duda dentro del grupo de trabajo.
# Contactar con el equipo de integración para indicarle la duda.
# El equipo de integración creará el issue en su repositorio indicando la duda o incidencia.
# 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.

Equipo de integración general - 17 18 - G1

2017-12-07T16:09:42Z

Davposmen: /* Procedimiento de gestión de cambios */

== Miembros ==

<ul>
<li>Suriel Aido Teruel - '''suraidter'''''arroba'''''alum.us.es''' </li>
<li>Paula Balsera Martínez - '''paubalmar'''''arroba'''''alum.us.es''' </li>
<li>Juan Jiménez Gutiérrez - '''juajimgui1'''''arroba'''''alum.us.es''' </li>
<li>Álvaro Domínguez Núñez - '''alvdomnun'''''arroba'''''alum.us.es''' </li>
<li>Miguel Ángel Baños Carretón - '''migbancar'''''arroba'''''alum.us.es''' </li>
<li>David Posada Mena - '''davposmen'''''arroba'''''alum.us.es''' </li>
<li>Augusto José Rivero Carmona - '''augrivcar'''''arroba'''''alum.us.es''' </li>
 
Cómo interpretar esta dirección: cambiar ''arroba'' por "@"
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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 [https://drive.google.com/file/d/1QcyMX2CTODWyq4KWQSWc259S-sidhe4f/view?usp=sharing 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:

{| class="wikitable"
!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 <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:52000</nowiki> 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 [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 ( [http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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 '''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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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.

Equipo de integración general - 17 18 - G1

2017-12-07T10:20:13Z

Davposmen: /* Miembros */

Equipo de integración general - 17 18 - G1

2017-12-07T10:08:00Z

Davposmen: /* Miembros */

Equipo de integración general - 17 18 - G1

2017-11-30T20:13:51Z

Davposmen: /* Formateo de commits */

== Miembros ==

<ul>
<li>Suriel Aido Teruel</li>
<li>Paula Balsera Martínez</li>
<li>Juan Jiménez Gutiérrez</li>
<li>Álvaro Domínguez Núñez</li>
<li>Miguel Ángel Baños Carretón</li>
<li>David Posada Mena</li>
<li>Augusto José Rivero Carmona</li>
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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 [https://drive.google.com/file/d/1QcyMX2CTODWyq4KWQSWc259S-sidhe4f/view?usp=sharing 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:

{| class="wikitable"
!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 <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:52000</nowiki> 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 [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 ( [http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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.

Equipo de integración general - 17 18 - G1

2017-11-30T19:58:47Z

Davposmen: Página creada con «== Miembros == <ul> <li>Suriel Aido Teruel</li> <li>Paula Balsera Martínez</li> <li>Juan Jiménez Gutiérrez</li> <li>Álvaro Domínguez Núñez</li> <li>Miguel Ángel Ba...»

== Miembros ==

<ul>
<li>Suriel Aido Teruel</li>
<li>Paula Balsera Martínez</li>
<li>Juan Jiménez Gutiérrez</li>
<li>Álvaro Domínguez Núñez</li>
<li>Miguel Ángel Baños Carretón</li>
<li>David Posada Mena</li>
<li>Augusto José Rivero Carmona</li>
</ul>

== Repositorio de GitHub ==

El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/Integracion-EGC-G1 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 [https://drive.google.com/file/d/1QcyMX2CTODWyq4KWQSWc259S-sidhe4f/view?usp=sharing 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:

{| class="wikitable"
!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 <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:52000</nowiki> 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 [http://opera.eii.us.es/egc/public/trabajo/ver/id/103 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 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 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.

=== 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 ( [http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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 ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 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.

Espacios para el grupo 1 1718

2017-11-30T18:20:14Z

Davposmen:

EN CONSTRUCCIÓN

== Lista de proyectos ==

* [[Equipo de integración general - 17_18 - G1]]
* [[Gestión del programa - 17_18 - G1]]
* [[Gestión del registro - 17_18 - G1]]
* [[Gestión de visualización del programa - 17_18 - G1]]
* [[Gestión de integración con redes sociales - 17_18 - G1]]
* [[Autenticación - 17_18 - G1]]
* [[Administración de votaciones - 17_18 - G1]]
* [[Administración de censos - 17_18 - G1]]
* [[Cabina de votaciones - 17_18 - G1]]
* [[Cabina de telegram - 17_18 - G1]]
* [[Almacenamiento de votos - 17_18 - G1]]
* [[Recuento de votos - 17_18 - G1]]
* [[Visualización de resultados - 17_18 - G1]]

Espacios para el grupo 1 1718

2017-11-30T17:42:26Z

Davposmen: Página creada con «EN CONSTRUCCIÓN [https://1984.lsi.us.es/wiki-egc/index.php?title=Equipo_de_integracion_general_-_17_18_-_G2 Equipo_de_integracion_general - 17_18 - G2]»

EN CONSTRUCCIÓN

[https://1984.lsi.us.es/wiki-egc/index.php?title=Equipo_de_integracion_general_-_17_18_-_G2 Equipo_de_integracion_general - 17_18 - G2]