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

Revisión del 19:34 28 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 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: