Wiki de EGC - Contribuciones del usuario [es]

Equipo de integración general - 17 18 - G2

2018-01-07T17:22:43Z

Robgarcal: /* Integración continua y despliegue con Travis CI */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|3306
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Recuento
|172.18.2.70
|50070
|-
|Cabina Telegram
|No
|No
|}

*Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

*Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

*Las direcciones IPs deben estar presentes en el código publicado en el repositorio remoto, pero durante el desarrollo en local se pueden hacer peticiones a localhost gracias al mapeo de puertos entre el sistema anfitrión y la máquina virtual.

*Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP). Si este aspecto se configura en un fichero del proyecto, es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise su código para realizar modificaciones.

*No hay nombres de dominio para los subsistemas, puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

*Aunque la BD del sistema de votaciones tenga un puerto publicado en Docker, se necesita hacer un mapeo en la máquina virtual. En [http://ask.xmodulo.com/access-nat-guest-from-host-virtualbox.html esta guía] hay información de cómo hacerlo. Basta con establecer el puerto anfitrión y el puerto invitado a 3306.

=== Conexiones a bases de datos ===
Todas las conexiones se realizan a través del puerto predeterminado de MySQL (3306). Cada equipo debe realizar las configuraciones necesarias en su proyecto para que se puedan conectar a las bases de datos correspondientes. Cuando el contenedor de la base de datos del sistema de votaciones se inicializa por primera vez, se crean las bases de datos necesarias por lo que no se espera que un equipo tenga que interactuar con la base de datos en lo que a configuraciones se refiere. En todos los casos la '''contraseña de acceso''' es "egc".

{| class="wikitable"
!Subsistema
!Nombre de la BD
!Usuario
|-
|Autenticación
|autenticacion
|auth-user
|-
|Administración de censos
|adm_censos
|censos-user
|-
|Administración de votaciones
|AdministracionVotaciones
|acme-user / acme-manager
|-
|Almacenamiento de votos
|almacenamiento
|alm-user
|-
|Recuento
|recuento
|rec-user
|}

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".
'''Nota:''' en muchos casos no es necesario tener desplegados todos los subsistemas, podemos parar la ejecución de los mismos usando el comando "docker stop <nombre_contenedor>".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Integración continua y despliegue con Travis CI ==
Para realizar tareas de integración continua y despliegue continuo se usa la herramienta Travis CI. Con objeto de facilitar las operaciones en este ámbito, se ha creado una plantilla del fichero de configuración de Travis (.travis.yml) que los distintos equipos deben incorporar a sus repositorios (con algunas excepciones). Travis realizará un despliegue del subsistema en el servidor de producción de las construcciones satisfactorias en la rama "master".

Para que Travis pueda realizar el despliegue remoto de un subsistema, el equipo de integración añadirá a los repositorios un fichero encriptado.

La plantilla del fichero .travis.yml se encuentra [https://github.com/EGC-G2-Trabajo-1718/integracion/blob/master/travis/template.yml aquí].

Lista de nombres que admite el script:
* portal-votaciones
* autenticacion
* adm_censos
* adm_votaciones
* almacen_votos
* cabina_votaciones
* cabina_votaciones_telegram
* recuento_votos

'''Notas:'''
* Si tu equipo no trabaja con la base de datos del sistema de votaciones se deben omitir las líneas anteriores a "before_install". Sin embargo, es importante que la fase "before_install" siga presente con la línea que hace referencia a la desencriptación del fichero "deploy.enc".
* Falta la fase principal "script", en Travis esta fase es en la que se ejecutan las pruebas unitarias y otros tests. Cada equipo debe saber cómo ejecutar tests mediante los comandos de la herramienta pertinente (mvn, composer, node...), esto es responsabilidad de cada equipo. No se espera que en esta fase se realicen pruebas de integración con otros subsistemas, puesto que desplegar los subsistemas necesarios puede llevar a construcciones de código mucho más lentas, para ello se cuenta con la máquina virtual.
* Es importante comprobar en las primeras construcciones de la rama master que el código se despliega en la máquina de producción. Pueden haber presentes fallos en el script de despliegue que imposibiliten el despliegue del código a producción. En esos casos se deben registrar incidencias en el [https://github.com/EGC-G2-Trabajo-1718/integracion/ repositorio de integración].

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T21:02:01Z

Robgarcal: /* Descripción de IPs y puertos */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|3306
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Recuento
|172.18.2.70
|50070
|-
|Cabina Telegram
|No
|No
|}

*Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

*Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

*Las direcciones IPs deben estar presentes en el código publicado en el repositorio remoto, pero durante el desarrollo en local se pueden hacer peticiones a localhost gracias al mapeo de puertos entre el sistema anfitrión y la máquina virtual.

*Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP). Si este aspecto se configura en un fichero del proyecto, es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise su código para realizar modificaciones.

*No hay nombres de dominio para los subsistemas, puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

*Aunque la BD del sistema de votaciones tenga un puerto publicado en Docker, se necesita hacer un mapeo en la máquina virtual. En [http://ask.xmodulo.com/access-nat-guest-from-host-virtualbox.html esta guía] hay información de cómo hacerlo. Basta con establecer el puerto anfitrión y el puerto invitado a 3306.

=== Conexiones a bases de datos ===
Todas las conexiones se realizan a través del puerto predeterminado de MySQL (3306). Cada equipo debe realizar las configuraciones necesarias en su proyecto para que se puedan conectar a las bases de datos correspondientes. Cuando el contenedor de la base de datos del sistema de votaciones se inicializa por primera vez, se crean las bases de datos necesarias por lo que no se espera que un equipo tenga que interactuar con la base de datos en lo que a configuraciones se refiere. En todos los casos la '''contraseña de acceso''' es "egc".

{| class="wikitable"
!Subsistema
!Nombre de la BD
!Usuario
|-
|Autenticación
|autenticacion
|auth-user
|-
|Administración de censos
|adm_censos
|censos-user
|-
|Administración de votaciones
|AdministracionVotaciones
|acme-user / acme-manager
|-
|Almacenamiento de votos
|almacenamiento
|alm-user
|-
|Recuento
|recuento
|rec-user
|}

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".
'''Nota:''' en muchos casos no es necesario tener desplegados todos los subsistemas, podemos parar la ejecución de los mismos usando el comando "docker stop <nombre_contenedor>".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Integración continua y despliegue con Travis CI ==
Para realizar tareas de integración continua y despliegue continuo se usa la herramienta Travis CI. Con objeto de facilitar las operaciones en este ámbito, se ha creado una plantilla del fichero de configuración de Travis (.travis.yml) que los distintos equipos deben incorporar a sus repositorios (con algunas excepciones). Travis realizará un despliegue del subsistema en el servidor de producción de las construcciones satisfactorias en la rama "master".

Para que Travis pueda realizar el despliegue remoto de un subsistema, el equipo de integración añadirá a los repositorios un fichero encriptado.

La plantilla del fichero .travis.yml se encuentra [https://github.com/EGC-G2-Trabajo-1718/integracion/blob/master/travis/template.yml aquí].

'''Notas:'''
* Si tu equipo no trabaja con la base de datos del sistema de votaciones se deben omitir las líneas anteriores a "before_install". Sin embargo, es importante que la fase "before_install" siga presente con la línea que hace referencia a la desencriptación del fichero "deploy.enc".
* Falta la fase principal "script", en Travis esta fase es en la que se ejecutan las pruebas unitarias y otros tests. Cada equipo debe saber cómo ejecutar tests mediante los comandos de la herramienta pertinente (mvn, composer, node...), esto es responsabilidad de cada equipo. No se espera que en esta fase se realicen pruebas de integración con otros subsistemas, puesto que desplegar los subsistemas necesarios puede llevar a construcciones de código mucho más lentas, para ello se cuenta con la máquina virtual.
* Es importante comprobar en las primeras construcciones de la rama master que el código se despliega en la máquina de producción. Pueden haber presentes fallos en el script de despliegue que imposibiliten el despliegue del código a producción. En esos casos se deben registrar incidencias en el [https://github.com/EGC-G2-Trabajo-1718/integracion/ repositorio de integración].

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T20:55:08Z

Robgarcal: /* Descripción de IPs y puertos */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|3306
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

*Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

*Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

*Las direcciones IPs deben estar presentes en el código publicado en el repositorio remoto, pero durante el desarrollo en local se pueden hacer peticiones a localhost gracias al mapeo de puertos entre el sistema anfitrión y la máquina virtual.

*Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP). Si este aspecto se configura en un fichero del proyecto, es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise su código para realizar modificaciones.

*No hay nombres de dominio para los subsistemas, puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

=== Conexiones a bases de datos ===
Todas las conexiones se realizan a través del puerto predeterminado de MySQL (3306). Cada equipo debe realizar las configuraciones necesarias en su proyecto para que se puedan conectar a las bases de datos correspondientes. Cuando el contenedor de la base de datos del sistema de votaciones se inicializa por primera vez, se crean las bases de datos necesarias por lo que no se espera que un equipo tenga que interactuar con la base de datos en lo que a configuraciones se refiere. En todos los casos la '''contraseña de acceso''' es "egc".

{| class="wikitable"
!Subsistema
!Nombre de la BD
!Usuario
|-
|Autenticación
|autenticacion
|auth-user
|-
|Administración de censos
|adm_censos
|censos-user
|-
|Administración de votaciones
|AdministracionVotaciones
|acme-user / acme-manager
|-
|Almacenamiento de votos
|almacenamiento
|alm-user
|-
|Recuento
|recuento
|rec-user
|}

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".
'''Nota:''' en muchos casos no es necesario tener desplegados todos los subsistemas, podemos parar la ejecución de los mismos usando el comando "docker stop <nombre_contenedor>".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Integración continua y despliegue con Travis CI ==
Para realizar tareas de integración continua y despliegue continuo se usa la herramienta Travis CI. Con objeto de facilitar las operaciones en este ámbito, se ha creado una plantilla del fichero de configuración de Travis (.travis.yml) que los distintos equipos deben incorporar a sus repositorios (con algunas excepciones). Travis realizará un despliegue del subsistema en el servidor de producción de las construcciones satisfactorias en la rama "master".

Para que Travis pueda realizar el despliegue remoto de un subsistema, el equipo de integración añadirá a los repositorios un fichero encriptado.

La plantilla del fichero .travis.yml se encuentra [https://github.com/EGC-G2-Trabajo-1718/integracion/blob/master/travis/template.yml aquí].

'''Notas:'''
* Si tu equipo no trabaja con la base de datos del sistema de votaciones se deben omitir las líneas anteriores a "before_install". Sin embargo, es importante que la fase "before_install" siga presente con la línea que hace referencia a la desencriptación del fichero "deploy.enc".
* Falta la fase principal "script", en Travis esta fase es en la que se ejecutan las pruebas unitarias y otros tests. Cada equipo debe saber cómo ejecutar tests mediante los comandos de la herramienta pertinente (mvn, composer, node...), esto es responsabilidad de cada equipo. No se espera que en esta fase se realicen pruebas de integración con otros subsistemas, puesto que desplegar los subsistemas necesarios puede llevar a construcciones de código mucho más lentas, para ello se cuenta con la máquina virtual.
* Es importante comprobar en las primeras construcciones de la rama master que el código se despliega en la máquina de producción. Pueden haber presentes fallos en el script de despliegue que imposibiliten el despliegue del código a producción. En esos casos se deben registrar incidencias en el [https://github.com/EGC-G2-Trabajo-1718/integracion/ repositorio de integración].

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T20:34:53Z

Robgarcal: /* Descripción de IPs y puertos */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|No publicado al exterior
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

*Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

*Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

*Las direcciones IPs deben estar presentes en el código publicado en el repositorio remoto, pero durante el desarrollo en local se pueden hacer peticiones a localhost gracias al mapeo de puertos entre el sistema anfitrión y la máquina virtual.

*Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP). Si este aspecto se configura en un fichero del proyecto, es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise su código para realizar modificaciones.

*No hay nombres de dominio para los subsistemas, puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

=== Conexiones a bases de datos ===
Todas las conexiones se realizan a través del puerto predeterminado de MySQL (3306). Cada equipo debe realizar las configuraciones necesarias en su proyecto para que se puedan conectar a las bases de datos correspondientes. Cuando el contenedor de la base de datos del sistema de votaciones se inicializa por primera vez, se crean las bases de datos necesarias por lo que no se espera que un equipo tenga que interactuar con la base de datos en lo que a configuraciones se refiere. En todos los casos la '''contraseña de acceso''' es "egc".

{| class="wikitable"
!Subsistema
!Nombre de la BD
!Usuario
|-
|Autenticación
|autenticacion
|auth-user
|-
|Administración de censos
|adm_censos
|censos-user
|-
|Administración de votaciones
|AdministracionVotaciones
|acme-user / acme-manager
|-
|Almacenamiento de votos
|almacenamiento
|alm-user
|-
|Recuento
|recuento
|rec-user
|}

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".
'''Nota:''' en muchos casos no es necesario tener desplegados todos los subsistemas, podemos parar la ejecución de los mismos usando el comando "docker stop <nombre_contenedor>".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Integración continua y despliegue con Travis CI ==
Para realizar tareas de integración continua y despliegue continuo se usa la herramienta Travis CI. Con objeto de facilitar las operaciones en este ámbito, se ha creado una plantilla del fichero de configuración de Travis (.travis.yml) que los distintos equipos deben incorporar a sus repositorios (con algunas excepciones). Travis realizará un despliegue del subsistema en el servidor de producción de las construcciones satisfactorias en la rama "master".

Para que Travis pueda realizar el despliegue remoto de un subsistema, el equipo de integración añadirá a los repositorios un fichero encriptado.

La plantilla del fichero .travis.yml se encuentra [https://github.com/EGC-G2-Trabajo-1718/integracion/blob/master/travis/template.yml aquí].

'''Notas:'''
* Si tu equipo no trabaja con la base de datos del sistema de votaciones se deben omitir las líneas anteriores a "before_install". Sin embargo, es importante que la fase "before_install" siga presente con la línea que hace referencia a la desencriptación del fichero "deploy.enc".
* Falta la fase principal "script", en Travis esta fase es en la que se ejecutan las pruebas unitarias y otros tests. Cada equipo debe saber cómo ejecutar tests mediante los comandos de la herramienta pertinente (mvn, composer, node...), esto es responsabilidad de cada equipo. No se espera que en esta fase se realicen pruebas de integración con otros subsistemas, puesto que desplegar los subsistemas necesarios puede llevar a construcciones de código mucho más lentas, para ello se cuenta con la máquina virtual.
* Es importante comprobar en las primeras construcciones de la rama master que el código se despliega en la máquina de producción. Pueden haber presentes fallos en el script de despliegue que imposibiliten el despliegue del código a producción. En esos casos se deben registrar incidencias en el [https://github.com/EGC-G2-Trabajo-1718/integracion/ repositorio de integración].

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T20:33:57Z

Robgarcal: /* Conexiones a bases de datos */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|No publicado al exterior
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

Las direcciones IPs deben estar presentes en el código publicado en el repositorio remoto, pero durante el desarrollo en local se pueden hacer peticiones a localhost gracias al mapeo de puertos entre el sistema anfitrión y la máquina virtual.

Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP). Si este aspecto se configura en un fichero del proyecto, es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise su código para realizar modificaciones.

No hay nombres de dominio para los subsistemas,
puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

=== Conexiones a bases de datos ===
Todas las conexiones se realizan a través del puerto predeterminado de MySQL (3306). Cada equipo debe realizar las configuraciones necesarias en su proyecto para que se puedan conectar a las bases de datos correspondientes. Cuando el contenedor de la base de datos del sistema de votaciones se inicializa por primera vez, se crean las bases de datos necesarias por lo que no se espera que un equipo tenga que interactuar con la base de datos en lo que a configuraciones se refiere. En todos los casos la '''contraseña de acceso''' es "egc".

{| class="wikitable"
!Subsistema
!Nombre de la BD
!Usuario
|-
|Autenticación
|autenticacion
|auth-user
|-
|Administración de censos
|adm_censos
|censos-user
|-
|Administración de votaciones
|AdministracionVotaciones
|acme-user / acme-manager
|-
|Almacenamiento de votos
|almacenamiento
|alm-user
|-
|Recuento
|recuento
|rec-user
|}

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".
'''Nota:''' en muchos casos no es necesario tener desplegados todos los subsistemas, podemos parar la ejecución de los mismos usando el comando "docker stop <nombre_contenedor>".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Integración continua y despliegue con Travis CI ==
Para realizar tareas de integración continua y despliegue continuo se usa la herramienta Travis CI. Con objeto de facilitar las operaciones en este ámbito, se ha creado una plantilla del fichero de configuración de Travis (.travis.yml) que los distintos equipos deben incorporar a sus repositorios (con algunas excepciones). Travis realizará un despliegue del subsistema en el servidor de producción de las construcciones satisfactorias en la rama "master".

Para que Travis pueda realizar el despliegue remoto de un subsistema, el equipo de integración añadirá a los repositorios un fichero encriptado.

La plantilla del fichero .travis.yml se encuentra [https://github.com/EGC-G2-Trabajo-1718/integracion/blob/master/travis/template.yml aquí].

'''Notas:'''
* Si tu equipo no trabaja con la base de datos del sistema de votaciones se deben omitir las líneas anteriores a "before_install". Sin embargo, es importante que la fase "before_install" siga presente con la línea que hace referencia a la desencriptación del fichero "deploy.enc".
* Falta la fase principal "script", en Travis esta fase es en la que se ejecutan las pruebas unitarias y otros tests. Cada equipo debe saber cómo ejecutar tests mediante los comandos de la herramienta pertinente (mvn, composer, node...), esto es responsabilidad de cada equipo. No se espera que en esta fase se realicen pruebas de integración con otros subsistemas, puesto que desplegar los subsistemas necesarios puede llevar a construcciones de código mucho más lentas, para ello se cuenta con la máquina virtual.
* Es importante comprobar en las primeras construcciones de la rama master que el código se despliega en la máquina de producción. Pueden haber presentes fallos en el script de despliegue que imposibiliten el despliegue del código a producción. En esos casos se deben registrar incidencias en el [https://github.com/EGC-G2-Trabajo-1718/integracion/ repositorio de integración].

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T20:18:21Z

Robgarcal: /* Máquina virtual de desarrollo */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|No publicado al exterior
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

Las direcciones IPs deben estar presentes en el código publicado en el repositorio remoto, pero durante el desarrollo en local se pueden hacer peticiones a localhost gracias al mapeo de puertos entre el sistema anfitrión y la máquina virtual.

Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP). Si este aspecto se configura en un fichero del proyecto, es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise su código para realizar modificaciones.

No hay nombres de dominio para los subsistemas,
puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

=== Conexiones a bases de datos ===
Todas las conexiones se realizan a través del puerto predeterminado de MySQL (3306). Cada equipo debe realizar las configuraciones necesarias en su proyecto para que se puedan conectar a las bases de datos correspondientes. Cuando el contenedor de la base de datos del sistema de votaciones se inicializa por primera vez, se crean las bases de datos necesarias por lo que no se espera que un equipo tenga que interactuar con la base de datos en lo que a configuraciones se refiere. En todos los casos la '''contraseña de acceso''' es "egc".

{| class="wikitable"
!Subsistema
!Nombre de la BD
!Usuario
|-
|Autenticación
|autenticacion
|auth-user
|-
|Administración de censos
|adm_censos
|censos-user
|-
|Administración de votaciones
|AdministracionVotaciones
|acme-user / acme-manager
|-
|Almacenamiento de votos
|almacenamiento
|alm-user
|}

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".
'''Nota:''' en muchos casos no es necesario tener desplegados todos los subsistemas, podemos parar la ejecución de los mismos usando el comando "docker stop <nombre_contenedor>".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Integración continua y despliegue con Travis CI ==
Para realizar tareas de integración continua y despliegue continuo se usa la herramienta Travis CI. Con objeto de facilitar las operaciones en este ámbito, se ha creado una plantilla del fichero de configuración de Travis (.travis.yml) que los distintos equipos deben incorporar a sus repositorios (con algunas excepciones). Travis realizará un despliegue del subsistema en el servidor de producción de las construcciones satisfactorias en la rama "master".

Para que Travis pueda realizar el despliegue remoto de un subsistema, el equipo de integración añadirá a los repositorios un fichero encriptado.

La plantilla del fichero .travis.yml se encuentra [https://github.com/EGC-G2-Trabajo-1718/integracion/blob/master/travis/template.yml aquí].

'''Notas:'''
* Si tu equipo no trabaja con la base de datos del sistema de votaciones se deben omitir las líneas anteriores a "before_install". Sin embargo, es importante que la fase "before_install" siga presente con la línea que hace referencia a la desencriptación del fichero "deploy.enc".
* Falta la fase principal "script", en Travis esta fase es en la que se ejecutan las pruebas unitarias y otros tests. Cada equipo debe saber cómo ejecutar tests mediante los comandos de la herramienta pertinente (mvn, composer, node...), esto es responsabilidad de cada equipo. No se espera que en esta fase se realicen pruebas de integración con otros subsistemas, puesto que desplegar los subsistemas necesarios puede llevar a construcciones de código mucho más lentas, para ello se cuenta con la máquina virtual.
* Es importante comprobar en las primeras construcciones de la rama master que el código se despliega en la máquina de producción. Pueden haber presentes fallos en el script de despliegue que imposibiliten el despliegue del código a producción. En esos casos se deben registrar incidencias en el [https://github.com/EGC-G2-Trabajo-1718/integracion/ repositorio de integración].

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T19:24:15Z

Robgarcal: /* Integración continua con Travis CI */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|No publicado al exterior
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

Las direcciones IPs deben estar presentes en el código publicado en el repositorio remoto, pero durante el desarrollo en local se pueden hacer peticiones a localhost gracias al mapeo de puertos entre el sistema anfitrión y la máquina virtual.

Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP). Si este aspecto se configura en un fichero del proyecto, es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise su código para realizar modificaciones.

No hay nombres de dominio para los subsistemas,
puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".
'''Nota:''' en muchos casos no es necesario tener desplegados todos los subsistemas, podemos parar la ejecución de los mismos usando el comando "docker stop <nombre_contenedor>".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Integración continua y despliegue con Travis CI ==
Para realizar tareas de integración continua y despliegue continuo se usa la herramienta Travis CI. Con objeto de facilitar las operaciones en este ámbito, se ha creado una plantilla del fichero de configuración de Travis (.travis.yml) que los distintos equipos deben incorporar a sus repositorios (con algunas excepciones). Travis realizará un despliegue del subsistema en el servidor de producción de las construcciones satisfactorias en la rama "master".

Para que Travis pueda realizar el despliegue remoto de un subsistema, el equipo de integración añadirá a los repositorios un fichero encriptado.

La plantilla del fichero .travis.yml se encuentra [https://github.com/EGC-G2-Trabajo-1718/integracion/blob/master/travis/template.yml aquí].

'''Notas:'''
* Si tu equipo no trabaja con la base de datos del sistema de votaciones se deben omitir las líneas anteriores a "before_install". Sin embargo, es importante que la fase "before_install" siga presente con la línea que hace referencia a la desencriptación del fichero "deploy.enc".
* Falta la fase principal "script", en Travis esta fase es en la que se ejecutan las pruebas unitarias y otros tests. Cada equipo debe saber cómo ejecutar tests mediante los comandos de la herramienta pertinente (mvn, composer, node...), esto es responsabilidad de cada equipo. No se espera que en esta fase se realicen pruebas de integración con otros subsistemas, puesto que desplegar los subsistemas necesarios puede llevar a construcciones de código mucho más lentas, para ello se cuenta con la máquina virtual.
* Es importante comprobar en las primeras construcciones de la rama master que el código se despliega en la máquina de producción. Pueden haber presentes fallos en el script de despliegue que imposibiliten el despliegue del código a producción. En esos casos se deben registrar incidencias en el [https://github.com/EGC-G2-Trabajo-1718/integracion/ repositorio de integración].

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T18:23:43Z

Robgarcal:

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|No publicado al exterior
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

Las direcciones IPs deben estar presentes en el código publicado en el repositorio remoto, pero durante el desarrollo en local se pueden hacer peticiones a localhost gracias al mapeo de puertos entre el sistema anfitrión y la máquina virtual.

Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP). Si este aspecto se configura en un fichero del proyecto, es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise su código para realizar modificaciones.

No hay nombres de dominio para los subsistemas,
puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".
'''Nota:''' en muchos casos no es necesario tener desplegados todos los subsistemas, podemos parar la ejecución de los mismos usando el comando "docker stop <nombre_contenedor>".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Integración continua con Travis CI ==

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T18:22:53Z

Robgarcal:

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|No publicado al exterior
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

Las direcciones IPs deben estar presentes en el código publicado en el repositorio remoto, pero durante el desarrollo en local se pueden hacer peticiones a localhost gracias al mapeo de puertos entre el sistema anfitrión y la máquina virtual.

Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP). Si este aspecto se configura en un fichero del proyecto, es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise su código para realizar modificaciones.

No hay nombres de dominio para los subsistemas,
puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".
'''Nota:''' en muchos casos no es necesario tener desplegados todos los subsistemas, podemos parar la ejecución de los mismos usando el comando "docker stop <nombre_contenedor>".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T18:20:59Z

Robgarcal: /* Script de inicio general */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|No publicado al exterior
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

Las direcciones IPs deben estar presentes en el código publicado en el repositorio remoto, pero durante el desarrollo en local se pueden hacer peticiones a localhost gracias al mapeo de puertos entre el sistema anfitrión y la máquina virtual.

Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP). Si este aspecto se configura en un fichero del proyecto, es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise su código para realizar modificaciones.

No hay nombres de dominio para los subsistemas,
puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".
'''Nota:''' en muchos casos no es necesario tener desplegados todos los subsistemas, podemos parar la ejecución de los mismos usando el comando "docker stop <nombre_contenedor>".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T18:18:11Z

Robgarcal: /* Máquina virtual de desarrollo */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|No publicado al exterior
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

Las direcciones IPs deben estar presentes en el código publicado en el repositorio remoto, pero durante el desarrollo en local se pueden hacer peticiones a localhost gracias al mapeo de puertos entre el sistema anfitrión y la máquina virtual.

Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP). Si este aspecto se configura en un fichero del proyecto, es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise su código para realizar modificaciones.

No hay nombres de dominio para los subsistemas,
puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T18:14:11Z

Robgarcal: /* Descripción de IPs y puertos */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|No publicado al exterior
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP), si este aspecto se configura en un fichero del proyecto es responsabilidad del equipo realizar dicho cambio. En la mayoría de los subsistemas esto ha sido conseguido mediante configuraciones de los contenedores, pero en otros subsistemas es necesario que el equipo revise en su código qué modificaciones debe realizar.

No hay nombres de dominio para los subsistemas,
puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T18:10:00Z

Robgarcal: /* Script de despliegue temporal */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|No publicado al exterior
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP), si este aspecto se configura en un fichero del proyecto es responsabilidad del equipo realizar dicho cambio.

No hay nombres de dominio para los subsistemas,
puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T18:09:14Z

Robgarcal: /* Scripts de automatización */

== Miembros ==

<ul>
<li>Gonzalo Delgado Chaves</li>
<li>Jesús Rivas Jiménez</li>
<li>Javier Sánchez Parra</li>
<li>Mohammed Alaoui Mhammedi</li>
<li>Roberto García Calero</li>
</ul>

== Repositorio GitHub ==

El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí]

== Máquina virtual de desarrollo ==
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1nrXjmWwJRuOUIWOtVEZmiqczZaee96Mk/view?usp=sharing aquí]) permite a cada equipo desarrollar su trabajo en local y comprobar como se integra con el resto de subsistemas. La máquina virtual comparte una serie de puertos con el equipo anfitrión para conseguir la comunicación.

=== Descripción de IPs y puertos ===

{| class="wikitable"
!Subsistema
!Dirección IP
!Puerto
|-
|BD Wordpress
|172.18.2.1
|No publicado al exterior
|-
|BD Sistema de votación
|172.18.2.2
|No publicado al exterior
|-
|Wordpress (Portal Jornadas)
|172.18.2.5
|50000
|-
|Portal votaciones
|172.18.2.10
|50010
|-
|Autenticación
|172.18.2.20
|50020
|-
|Administración de censos
|172.18.2.30
|50030
|-
|Administración de votaciones
|172.18.2.40
|50040
|-
|Almacenamiento de votos
|172.18.2.50
|50050
|-
|Cabina de votaciones
|172.18.2.60
|50060
|-
|Cabina Telegram
|No
|No
|-
|Recuento
|172.18.2.70
|50070
|}

Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress.

Para comunicarse con la API de algún subsistema es necesario especificar la dirección IP de dicho subsistema.

Todos los subsistemas deben estar configurados para recibir peticiones al puerto 80 (HTTP), si este aspecto se configura en un fichero del proyecto es responsabilidad del equipo realizar dicho cambio.

No hay nombres de dominio para los subsistemas,
puesto que se encuentran en una red privada y por motivos de seguridad sus servicios no son expuestos al exterior. Cabe recordar el principal consumidor de las APIs de los subsistemas será el portal web del sistema de votaciones.

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

=== Scripts de automatización ===
Dado que el objetivo principal de la máquina virtual es contar con un entorno de pruebas lo más parecido al de producción (pre-producción), se han creado varios scripts que automatizan todos los procesos de despliegue de los subsistemas en contenedores. Para contar con estos scripts debemos ejecutar los siguientes comandos en la shell de la máquina virtual:
cd ~/scripts/ # Alt Gr + 4 para conseguir el caracter "~"
git clone https://github.com/EGC-G2-Trabajo-1718/integracion.git
Con estos comandos descargaremos el repositorio de integración, dentro de la carpeta tools se encuentra una serie de scripts de automatización. Para acceder a ellos basta con ejecutar lo siguiente:
cd ~/scripts/integracion/tools
ls # El comando "ls" lista los ficheros existentes en el directorio actual.
'''Nota''': dado que hemos descargado el repositorio de integración podemos obtener versiones más recientes de los scripts ejecutando "git pull".

==== Script de inicio general ====
Entre los ficheros de la carpeta tools se encuentra el script de inicio general "start.sh". Este script descarga los repositorios de los distintos subsistemas en la rama especificada por el usuario e inicia un contenedor por cada subsistema con el código descargado. Para iniciar el script escribiremos el siguiente comando:
bash ~/scripts/integracion/tools/start.sh
bash start.sh # En caso de estar situados dentro de la carpeta "tools".

==== Script de despliegue temporal ====
'''IMPORTANTE: Antes de ejecutar este script debemos comprobar en la configuración de la máquina virtual en VirtualBox que hemos especificado un directorio compartido para copiar en él la carpeta del repositorio con los cambios que hemos hecho en el código antes de subirlo.'''
Este script realiza las mismas tareas que el script de inicio general, pero con la diferencia de que permite iniciar un contenedor dentro de la máquina virtual con el código modificado en tu máquina local para realizar diversas pruebas. Los pasos a realizar para ejecutar este script son los siguientes:
# Comprobar que en el código se hacen peticiones a la dirección IP de cada subsistema.
# Realizar una copia del directorio raíz del repositorio. Con esto nos referimos a la carpeta resultante de hacer un "clone" del repositorio, no puede ser una carpeta de dentro del repositorio como "src" o derivados. Esta copia debe guardarse en el directorio compartido entre el sistema anfitrión y la máquina virtual.
# Ejecutar el script en la máquina virtual mediante el siguiente comando:
bash ~/scripts/integracion/tools/deploy-shared.sh
bash deploy-shared.sh # Suponiendo que estamos situados dentro del directorio "tools"

'''Nota''': debido a los distintos procesos que realizan los scripts, el despliegue de todos los proyectos toma bastante tiempo, además varía en función de la velocidad de la red y del rendimiento de tu equipo.

== Opera ==

Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]

== Formatos y procedimientos ==

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

''' URL base '''
Ruta completa incluido el dominio (Ej: https://censo.nvotesus.es/api/v1, https://censo.nvotesus.es/api)

Por cada ruta de la API:

''' URL relativa '''

Ruta relativa en base a la URL anterior (Ej: /getUser, /storeVote)

''' Descripción '''

Descripción de la tarea que realiza la ruta

''' Petición HTTP '''

Indicar el método HTTP usado (Ej: GET, POST, PUT, DELETE)

''' Parámetros de petición '''

Parametros que puede recibir indicando el nombre, tipo, descripción y valor por defecto (Si tiene valor por defecto significara que es opcional).

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
! Valor por defecto
|-
| user
| integer
| Nombre del usuario
|
|}

''' Ejemplo de petición '''

Ejemplo de uso de la url (Ej: GET https://auth.nvotesus.es/api/v1/get?user=test)

''' Respuesta '''

Parametros que puede recibir indicando el nombre, tipo, descripción. Será obligatorio incluir los parametros result y msg

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Nombre
! Tipo
! Descripción
|-
| result
| Boolean
| Resultado de la operación
|-
| msg
| String
| Mensaje de resultado o error
|}

''' Ejemplo de respuesta '''

Ejemplo de la respuesta a recibir.

{
"result" : true,
"msg" : "Successfull"
"username" : "tansalalv",
"name" : "Tania",
"surname" : "Salguero Álvarez",
"email" : "mail@example.com",
"genre" : "Femenino",
"autonomous_community" : "Andalucía",
"age" : "21",
"role" : "USUARIO"
}

''' Códigos de error '''

Códigos de error que puede devolver el método indicando el código HTTP, valor de result, valor del mensaje y una breve explicación de porque ha podido pasar.

Por ejemplo:

{| border="1" style="border-collapse:collapse"
|-
! Código
! Valor result
! Valor msg
! Posible motivo
|-
| 200
| true
| Successfull
|
|-
| 404
| false
| User not found
| El usuario indicado no existe.
|-
| 403
| false
| Don't have access
| No tienes permisos para acceder.
|}

=== Formato general para detallar incidencias ===
Las incidencias pueden emplearse no solo para fallos.
'''Título''': <breve título sobre la incidencia>
'''Prioridad''': a seleccionar entre distintos valores: ''urgente'', ''alto'', ''medio'', ''bajo''.
'''Estado''': ''pendiente'', ''en curso'', ''finalizado''. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
'''Descripción''': <descripción detallada del error>
La descripción puede incluir imagenes o la salida emitida por el fallo.
'''Etiquetas''': <etiquetas de GitHub para clasificar las incidencias>
''enhancement'': propuesta de mejora
''bug'': fallos encontrados en el sistema
''help wanted'': incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

=== Procedimiento general para la gestión de incidencias ===
# Establecer a un miembro del equipo el rol de gestor de incidencias.
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
# El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en ''Proyectos'' de GitHub.

Estas diapositivas incluyen información complementaria:
https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf

=== Formato general de commits ===
El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html base].

Es importante diferenciar entre los tipos (types) y usar todos en la medida de lo posible. Los ámbitos o focos (scopes) pueden emplearse para hacer referencia a distintas funcionalidades (features).

A continuación se detalla un ejemplo:

'''Título del commit''': fix: redirección errónea tras emitir voto
'''Cuerpo del commit''': Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.
'''Pie del commit''': Closes #<número de la incidencia en GitHub>

Ejemplo en texto:
fix: redirección errónea tras emitir voto

Después de que el usuario emitiese su voto este era redireccionado a una URL no existente. Ahora el usuario es redireccionado al panel principal.

Closes #19

=== Gestión de ramas ===
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de gestión de ramas:
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]]

Equipo de integración general - 17 18 - G2

2017-12-30T16:53:55Z

Robgarcal: /* Máquina virtual de desarrollo */

Equipo de integración general - 17 18 - G2

2017-12-30T16:41:25Z

Robgarcal: /* Máquina virtual de desarrollo */

Equipo de integración general - 17 18 - G2

2017-11-28T17:34:49Z

Robgarcal: /* Máquina virtual de desarrollo */

Equipo de integración general - 17 18 - G2

2017-11-28T17:33:48Z

Robgarcal:

Equipo de integración general - 17 18 - G2

2017-11-28T17:32:06Z

Robgarcal: /* Máquina virtual de desarrollo */

Equipo de integración general - 17 18 - G2

2017-11-28T17:09:16Z

Robgarcal:

Equipo de integración general - 17 18 - G2

2017-11-27T19:38:34Z

Robgarcal: /* Formato general de commits */

Equipo de integración general - 17 18 - G2

2017-11-27T19:31:53Z

Robgarcal: /* Formato general de commits */

Equipo de integración general - 17 18 - G2

2017-11-27T18:24:17Z

Robgarcal: /* Formatos y procedimientos */

Equipo de integración general - 17 18 - G2

2017-11-27T18:06:42Z

Robgarcal:

Equipo de integración general - 17 18 - G2

2017-11-27T18:03:59Z

Robgarcal: /* Procedimiento general para la gestión de incidencias */

Equipo de integración general - 17 18 - G2

2017-11-27T16:54:11Z

Robgarcal:

Equipo de integración general - 17 18 - G2

2017-11-27T16:11:42Z

Robgarcal: /* Formato general para detallar incidencias */

Asamblea 13 Nov 2017 - Grupo 2

2017-11-27T10:54:14Z

Robgarcal: Página creada con «link=https://1984.lsi.us.es/wiki-egc/images/egc/b/b7/Asamblea2_G2_1718.jpg Después de que el coordinador de la asignatu...»

[[File:Asamblea2 G2 1718.jpg|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/b/b7/Asamblea2_G2_1718.jpg]]

Después de que el coordinador de la asignatura explicara con más detalle el sistema de evaluación de los distintos apartados de la asignatura, las personas que no participaron en la organización presentaron propuestas sobre el sistema de puntuación a aplicar sobre el 10% de su nota final.

== Propuesta A ==
Esta propuesta establece que la puntuación de cada miembro vendrá dada por las horas que haya invertido tanto en la asistencia a las jornadas como en la realización de un trabajo acordado con el profesor y que esté enmarcado en el contexto de las jornadas. Para conseguir un 5 será necesario invertir 6 horas como mínimo y para conseguir un 10 será necesario invertir 12 horas mínimo.

== Propuesta B ==
Esta propuesta establece que la puntuación de cada miembro se basa en la suma de las horas de asistencia y las invertidas en realizar tareas de apoyo a la organización. El trabajo realizado en apoyo es evaluable por el profesor y puede tomar un valor de hasta 5 puntos.

== Resultados ==
Tras la presentación de las propuestas, estas se sometiron a votación. Resultó ganadora la propuesta A.
{| class="wikitable"
!style="text-align:left;" | Propuesta A
|style="color:green; font-weight:bold;" | 18 votos
|-
!style="text-align:left;" | Propuesta B
|1 voto
|}

== Fecha límite de presentación de trabajos ==
El día '''5 de diciembre de 2017 (martes)''' es la fecha límite de entrega de trabajos junto con la hoja de calculo correspondiente según el formato definido en el documento [[Archivo:00-Jornadas1718.pdf]]

'''Nota:''' enviar los trabajos en formato PDF y la hoja de cálculo con las horas dedicadas en formato [https://es.wikipedia.org/wiki/OpenDocument OpenDocument] (.ods)

Archivo:Asamblea2 G2 1718.jpg

2017-11-27T10:51:28Z

Robgarcal: Votaciones de la asamblea del 13/11/2017 (G2)

Votaciones de la asamblea del 13/11/2017 (G2)

Asambleas - 17/18

2017-11-27T09:59:38Z

Robgarcal:

[[Página_Principal]] -> [[2017/2018]]

* [[Reglamento Asamblea 2017 | Reglamento para la asamblea de peso de los elementos evaluables]]
* [[Asamblea 5 Oct 2017 - Grupo 1 | Asamblea 5 Octubre 2017 - Grupo 1, Peso de los elementos evaluables]]
* [[Asamblea 5 Oct 2017 - Grupo 2 | Asamblea 5 Octubre 2017 - Grupo 2, Peso de los elementos evaluables]]
* [[Asamblea 13 Nov 2017 - Grupo 2 | Asamblea 13 Noviembre 2017 - Grupo 2, Reestructuración del peso de los elementos evaluables]]
* [[Asamblea 16 Nov 2017 - Grupo 1 | Asamblea 16 Noviembre 2017 - Grupo 1, Reestructuración del peso de los elementos evaluables]]

Asambleas - 17/18

2017-11-27T09:57:36Z

Robgarcal:

[[Página_Principal]] -> [[2017/2018]]

* [[Reglamento Asamblea 2017 | Reglamento para la asamblea de peso de los elementos evaluables]]
* [[Asamblea 5 Oct 2017 - Grupo 1 | Asamblea 5 Octubre 2017 - Grupo 1, Peso de los elementos evaluables]]
* [[Asamblea 5 Oct 2017 - Grupo 2 | Asamblea 5 Octubre 2017 - Grupo 2, Peso de los elementos evaluables]]
* [[Asamblea 13 Nov 2017 - Grupo 1 | Asamblea 13 Noviembre 2017 - Grupo 2, Reestructuración del peso de los elementos evaluables]]
* [[Asamblea 16 Nov 2017 - Grupo 1 | Asamblea 16 Noviembre 2017 - Grupo 1, Reestructuración del peso de los elementos evaluables]]

Equipo de integración general - 17 18 - G2

2017-11-21T13:16:33Z

Robgarcal: /* Formato general para detallar incidencias */

Equipo de integración general - 17 18 - G2

2017-11-21T12:27:56Z

Robgarcal:

Equipo de integración general - 17 18 - G2

2017-11-21T12:16:45Z

Robgarcal: /* Formato para explicar tecnologías usasdas */

Equipo de integración general - 17 18 - G2

2017-11-21T11:53:02Z

Robgarcal:

Recuento de votos - 17 18 - G2

2017-11-21T11:30:07Z

Robgarcal: Página creada con «== Objetivo del subsistema == Dada una votación el subsistema deberá realizar un recuento de los votos almacenados. == Consideraciones == * Los votos están encriptados....»

== Objetivo del subsistema ==
Dada una votación el subsistema deberá realizar un recuento de los votos almacenados.

== Consideraciones ==
* Los votos están encriptados.
* Se realizan principalmente consultas. No se modifican datos de las votaciones.
* Repositorio del año pasado: https://github.com/AgoraUS-G1-1617/Recuento-y-modificacion

Gestión del registro - 17 18 - G2

2017-11-21T10:46:54Z

Robgarcal: /* Consideraciones */

== Objetivo del subsistema ==
Proporcionar un sistema de registro para asistentes a las jornadas.

== Consideraciones ==
* Debe integrarse con el portal de las jornadas (código heredado Wordpress).
* Debe acceder a la base de datos del portal.
* Debe permitir establecer períodos de registro y controlar que no se produzcan registros fuera de los plazos.
* ¿Obtener lista de registrados si eres administrador del portal?
* Repositorio donde puede encontrarse el código: https://github.com/cefiro-github/splc2017-registration
* Sitio web en donde se puede ver una instancia del proyecto funcionando: http://congreso.us.es/splc2017/registration-info/

Gestión del registro - 17 18 - G2

2017-11-21T10:43:11Z

Robgarcal: Página creada con «== Objetivo del subsistema == Proporcionar un sistema de registro para asistentes a las jornadas. == Consideraciones == * Debe integrarse con el portal de las jornadas (c...»

Espacios para el grupo 2 1718

2017-11-20T20:48:44Z

Robgarcal:

EN CONSTRUCCIÓN
== Lista de proyectos ==

Espacios para el grupo 2 1718

2017-11-20T20:48:24Z

Robgarcal: Página creada con «== Lista de proyectos ==»

== Lista de proyectos ==

Espacio para los grupos 17-18

2017-11-20T20:31:36Z

Robgarcal: Página creada con «Selecciona tu grupo: * Grupo 1 (Mañana) * Grupo 2 (Tarde)»

Selecciona tu grupo:

* [[Espacios para el grupo 1 1718|Grupo 1 (Mañana)]]
* [[Espacios para el grupo 2 1718|Grupo 2 (Tarde)]]

Asamblea 5 Oct 2017 - Grupo 2

2017-10-06T08:46:09Z

Robgarcal:

[[File:Asamblea1 G2 1718.jpg|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/3f/Asamblea1_G2_1718.jpg]]

== Elección del delegado ==

La asamblea comenzó con la '''elección del delegado'''. Se presentó únicamente la
candidatura de '''Roberto García Calero''', quien ahora es el delegado.

== Propuestas y votaciones ==

Posteriormente los alumnos realizaron propuestas de porcentajes para cada
apartado de la asignatura (jornadas, proyecto y ejercicio). Los alumnos
propusieron algunos porcentajes. Pero previamente se sometieron a votación a
mano alzada los siguientes aspectos:

'''Aplicar una ponderación diferente a las personas que participen de forma activa en las jornadas''', con el siguiente resultado:

{| class="wikitable"
!style="text-align:left;" | A favor
|style="color:green; font-weight:bold;" | 43
|-
!style="text-align:left;" | En contra
|0
|-
!style="text-align:left;" | Abstenciones
|17
|}

A favor.

'''Realizar la votación de los porcentajes con dos vueltas''', con el siguiente resultado:

{| class="wikitable"
!style="text-align:left;" | A favor
|style="color:green; font-weight:bold;" | 40
|-
!style="text-align:left;" | En contra
|19
|-
!style="text-align:left;" | Abstenciones
|1
|}

A favor.

A continuación los alumnos votaron '''los porcentajes para personas que no participasen de forma activa en las jornadas''':

{| class="wikitable"
|
!colspan="4" | Propuestas
|-
|
!A
!C
!E
!G
|-
!style="text-align:left;" | Jornadas
|10
|15
|40
|30
|-
!style="text-align:left;" | Proyecto
|60
|65
|40
|20
|-
!style="text-align:left;" | Ejercicio
|30
|20
|20
|50
|-
|
|-
!Votos 1ª ronda
|style="color:green; font-weight:bold;" | 31
|style="color:green; font-weight:bold;" | 24
|1
|6
|-
!Votos 2ª ronda
|style="color:green; font-weight:bold;" | 38
|24
|}

Propuesta más votada: '''A'''.

Después se realizaron propuestas de '''porcentajes para personas que participasen de forma activa en las jornadas''' y se recogieron los siguientes resultados:

{| class="wikitable"
|
!colspan="4" | Propuestas
|-
|
!B
!D
!E
!F
|-
!style="text-align:left;" | Jornadas
|30
|25
|30
|20
|-
!style="text-align:left;" | Proyecto
|40
|45
|60
|60
|-
!style="text-align:left;" | Ejercicio
|30
|30
|10
|20
|-
|
|-
!Votos 1ª ronda
|7
|style="color:green; font-weight:bold;" | 10
|6
|style="color:green; font-weight:bold;" | 19
|-
!Votos 2ª ronda
|
|17
|
|style="color:green; font-weight:bold;" | 24
|}

Propuesta más votada: '''F'''.

== Poderación final ==

Queda establecido que la ponderación de los elementos evaluables para el grupo 2 es la siguiente:
{| class="wikitable" style="text-align:center;"
|
!colspan="2" | Actividad en jornadas
|-
|
!Asistencia general
!Participación activa
|-
!Jornadas
|10
|20
|-
!Proyecto
|colspan="2" | 60
|-
!Ejercicio
|30
|20
|}

Asamblea 5 Oct 2017 - Grupo 2

2017-10-06T08:45:20Z

Robgarcal:

[[File:Asamblea1 G2 1718.jpg|center|thumb|750px|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/3f/Asamblea1_G2_1718.jpg]]

== Elección del delegado ==

La asamblea comenzó con la '''elección del delegado'''. Se presentó únicamente la
candidatura de '''Roberto García Calero''', quien ahora es el delegado.

== Propuestas y votaciones ==

Posteriormente los alumnos realizaron propuestas de porcentajes para cada
apartado de la asignatura (jornadas, proyecto y ejercicio). Los alumnos
propusieron algunos porcentajes. Pero previamente se sometieron a votación a
mano alzada los siguientes aspectos:

'''Aplicar una ponderación diferente a las personas que participen de forma activa en las jornadas''', con el siguiente resultado:

{| class="wikitable"
!style="text-align:left;" | A favor
|style="color:green; font-weight:bold;" | 43
|-
!style="text-align:left;" | En contra
|0
|-
!style="text-align:left;" | Abstenciones
|17
|}

A favor.

'''Realizar la votación de los porcentajes con dos vueltas''', con el siguiente resultado:

{| class="wikitable"
!style="text-align:left;" | A favor
|style="color:green; font-weight:bold;" | 40
|-
!style="text-align:left;" | En contra
|19
|-
!style="text-align:left;" | Abstenciones
|1
|}

A favor.

A continuación los alumnos votaron '''los porcentajes para personas que no participasen de forma activa en las jornadas''':

{| class="wikitable"
|
!colspan="4" | Propuestas
|-
|
!A
!C
!E
!G
|-
!style="text-align:left;" | Jornadas
|10
|15
|40
|30
|-
!style="text-align:left;" | Proyecto
|60
|65
|40
|20
|-
!style="text-align:left;" | Ejercicio
|30
|20
|20
|50
|-
|
|-
!Votos 1ª ronda
|style="color:green; font-weight:bold;" | 31
|style="color:green; font-weight:bold;" | 24
|1
|6
|-
!Votos 2ª ronda
|style="color:green; font-weight:bold;" | 38
|24
|}

Propuesta más votada: '''A'''.

Después se realizaron propuestas de '''porcentajes para personas que participasen de forma activa en las jornadas''' y se recogieron los siguientes resultados:

{| class="wikitable"
|
!colspan="4" | Propuestas
|-
|
!B
!D
!E
!F
|-
!style="text-align:left;" | Jornadas
|30
|25
|30
|20
|-
!style="text-align:left;" | Proyecto
|40
|45
|60
|60
|-
!style="text-align:left;" | Ejercicio
|30
|30
|10
|20
|-
|
|-
!Votos 1ª ronda
|7
|style="color:green; font-weight:bold;" | 10
|6
|style="color:green; font-weight:bold;" | 19
|-
!Votos 2ª ronda
|
|17
|
|style="color:green; font-weight:bold;" | 24
|}

Propuesta más votada: '''F'''.

== Poderación final ==

Queda establecido que la ponderación de los elementos evaluables para el grupo 2 es la siguiente:
{| class="wikitable" style="text-align:center;"
|
!colspan="2" | Actividad en jornadas
|-
|
!Asistencia general
!Participación activa
|-
!Jornadas
|10
|20
|-
!Proyecto
|colspan="2" | 60
|-
!Ejercicio
|30
|20
|}

Archivo:Asamblea1 G2 1718.jpg

2017-10-06T08:35:15Z

Robgarcal: Resultados de las votaciones realizadas en la primera asamblea del grupo 2 del curso 2017/18

Resultados de las votaciones realizadas en la primera asamblea del grupo 2 del curso 2017/18

Asamblea 5 Oct 2017 - Grupo 2

2017-10-06T08:23:45Z

Robgarcal: Página creada con «== Elección del delegado == La asamblea comenzó con la '''elección del delegado'''. Se presentó únicamente la candidatura de '''Roberto García Calero''', quien ahora...»

== Elección del delegado ==

La asamblea comenzó con la '''elección del delegado'''. Se presentó únicamente la
candidatura de '''Roberto García Calero''', quien ahora es el delegado.

== Propuestas y votaciones ==

Posteriormente los alumnos realizaron propuestas de porcentajes para cada
apartado de la asignatura (jornadas, proyecto y ejercicio). Los alumnos
propusieron algunos porcentajes. Pero previamente se sometieron a votación a
mano alzada los siguientes aspectos:

'''Aplicar una ponderación diferente a las personas que participen de forma activa en las jornadas''', con el siguiente resultado:

{| class="wikitable"
!style="text-align:left;" | A favor
|style="color:green; font-weight:bold;" | 43
|-
!style="text-align:left;" | En contra
|0
|-
!style="text-align:left;" | Abstenciones
|17
|}

A favor.

'''Realizar la votación de los porcentajes con dos vueltas''', con el siguiente resultado:

{| class="wikitable"
!style="text-align:left;" | A favor
|style="color:green; font-weight:bold;" | 40
|-
!style="text-align:left;" | En contra
|19
|-
!style="text-align:left;" | Abstenciones
|1
|}

A favor.

A continuación los alumnos votaron '''los porcentajes para personas que no participasen de forma activa en las jornadas''':

{| class="wikitable"
|
!colspan="4" | Propuestas
|-
|
!A
!C
!E
!G
|-
!style="text-align:left;" | Jornadas
|10
|15
|40
|30
|-
!style="text-align:left;" | Proyecto
|60
|65
|40
|20
|-
!style="text-align:left;" | Ejercicio
|30
|20
|20
|50
|-
|
|-
!Votos 1ª ronda
|style="color:green; font-weight:bold;" | 31
|style="color:green; font-weight:bold;" | 24
|1
|6
|-
!Votos 2ª ronda
|style="color:green; font-weight:bold;" | 32
|24
|}

Propuesta más votada: '''A'''.

Después se realizaron propuestas de '''porcentajes para personas que participasen de forma activa en las jornadas''' y se recogieron los siguientes resultados:

{| class="wikitable"
|
!colspan="4" | Propuestas
|-
|
!B
!D
!E
!F
|-
!style="text-align:left;" | Jornadas
|30
|25
|30
|20
|-
!style="text-align:left;" | Proyecto
|40
|45
|60
|60
|-
!style="text-align:left;" | Ejercicio
|30
|30
|10
|20
|-
|
|-
!Votos 1ª ronda
|7
|style="color:green; font-weight:bold;" | 10
|6
|style="color:green; font-weight:bold;" | 19
|-
!Votos 2ª ronda
|
|17
|
|style="color:green; font-weight:bold;" | 24
|}

Propuesta más votada: '''F'''.

== Poderación final ==

Queda establecido que la ponderación de los elementos evaluables para el grupo 2 es la siguiente:
{| class="wikitable" style="text-align:center;"
|
!colspan="2" | Actividad en jornadas
|-
|
!Asistencia general
!Participación activa
|-
!Jornadas
|10
|20
|-
!Proyecto
|colspan="2" | 60
|-
!Ejercicio
|30
|20
|}