Diferencia entre revisiones de «Equipo de integración general - 17 18 - G2»
(→Máquina virtual de desarrollo) |
(→Máquina virtual de desarrollo) |
||
Línea 18: | Línea 18: | ||
{| class="wikitable" | {| class="wikitable" | ||
!Subsistema | !Subsistema | ||
+ | !Dirección IP | ||
!Puerto | !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) | |Wordpress (Portal Jornadas) | ||
+ | |172.18.2.5 | ||
|50000 | |50000 | ||
|- | |- | ||
|Portal votaciones | |Portal votaciones | ||
+ | |172.18.2.10 | ||
|50010 | |50010 | ||
|- | |- | ||
|Autenticación | |Autenticación | ||
+ | |172.18.2.20 | ||
|50020 | |50020 | ||
|- | |- | ||
|Administración de censos | |Administración de censos | ||
+ | |172.18.2.30 | ||
|50030 | |50030 | ||
|- | |- | ||
|Administración de votaciones | |Administración de votaciones | ||
+ | |172.18.2.40 | ||
|50040 | |50040 | ||
|- | |- | ||
|Almacenamiento de votos | |Almacenamiento de votos | ||
+ | |172.18.2.50 | ||
|50050 | |50050 | ||
|- | |- | ||
|Cabina de votaciones | |Cabina de votaciones | ||
+ | |172.18.2.60 | ||
|50060 | |50060 | ||
+ | |- | ||
+ | |Cabina Telegram | ||
+ | |No | ||
+ | |No | ||
|- | |- | ||
|Recuento | |Recuento | ||
+ | |172.18.2.70 | ||
|50070 | |50070 | ||
|} | |} |
Revisión del 18:41 30 dic 2017
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. Los puertos asignados a cada subsistema se detallan a continuación:
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 |
Esta configuración de puertos se mantiene en el entorno de despliegue. Para acceder a algún servicio la URL consiste en http://localhost:<puerto>. Ej: http://localhost:50000 para acceder al portal wordpress.
Subsistemas desplegados
- Wordpress (Portal Jornadas)
Configuración de la máquina
Nota: la máquina ha sido exportada como un servicio virtualizado de VirtualBox.
- Número de CPUs: 2
- RAM Reservada: 1536MB
- SO: Debian 9 (Stretch)
- Usuario: egc
- Contraseña: egc
- Tiene Docker y Docker Compose instalados
Opera
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: