Diferencia entre revisiones de «Equipo de integración general - 17 18 - G2»
(→Máquina virtual de desarrollo) |
(→Máquina virtual de desarrollo) |
||
Línea 14: | Línea 14: | ||
== Máquina virtual de desarrollo == | == Máquina virtual de desarrollo == | ||
− | La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/ | + | 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. Los puertos asignados a cada subsistema se detallan a continuación: |
{| class="wikitable" | {| class="wikitable" |
Revisión del 19:29 5 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 | Puerto |
---|---|
Wordpress (Portal Jornadas) | 50000 |
Portal votaciones | 50010 |
Autenticación | 50020 |
Administración de censos | 50030 |
Administración de votaciones | 50040 |
Almacenamiento de votos | 50050 |
Cabina de votaciones | 50060 |
Recuento | 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: