Diferencia entre revisiones de «Equipo de integración general - 17 18 - G2»
(→Máquina virtual de desarrollo) |
|||
Línea 12: | Línea 12: | ||
El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí] | El repositorio de GitHub del equipo será accesible [https://github.com/EGC-G2-Trabajo-1718/integracion aquí] | ||
+ | |||
+ | == Máquina virtual de desarrollo == | ||
+ | La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1QcyMX2CTODWyq4KWQSWc259S-sidhe4f/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" | ||
+ | !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 <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:50000</nowiki> para acceder al portal wordpress. | ||
+ | |||
+ | === Subsistemas desplegados === | ||
+ | *Wordpress (Portal Jornadas) | ||
+ | |||
+ | === Configuración de la máquina === | ||
+ | *'''Número de CPUs''': 2 | ||
+ | *'''RAM Reservada''': 1536MB | ||
+ | *'''SO''': Debian 9 (Stretch) | ||
+ | *'''Usuario''': egc | ||
+ | *'''Contraseña''': egc | ||
+ | *'''Tiene Docker y Docker Compose instalados''' | ||
== Opera == | == Opera == | ||
Línea 71: | Línea 116: | ||
Cada equipo debe establecer una metodología de gestión de ramas. A continuación ponemos un ejemplo de 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: | ||
[[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]] | [[File:branch-flow.png|center|thumb|1000px|link=https://1984.lsi.us.es/wiki-egc/images/egc/d/dc/Branch-flow.png]] | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Revisión del 19:33 28 nov 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
- 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
- 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: