Diferencia entre revisiones de «Equipo de integración general - 17 18 - G2»

Revisión del 17:21 29 nov 2017

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:

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:

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:

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:

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

1. Establecer a un miembro del equipo el rol de gestor de incidencias.
2. Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
3. 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: