Equipo de integración general - 17 18 - G2
Contenido
Miembros
- Gonzalo Delgado Chaves
- Jesús Rivas Jiménez
- Javier Sánchez Parra
- Mohammed Alaoui Mhammedi
- Roberto García Calero
Repositorio GitHub
El repositorio de GitHub del equipo será accesible aquí
Máquina virtual de desarrollo
La máquina virtual de desarrollo (descarga 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
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 http://localhost:<puerto>. Ej: http://localhost:50000 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
Script de inicio general
Script de despliegue de pruebas
Opera
Puede acceder a nuestro proyecto en Opera 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:
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:
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:
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 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: