Diferencia entre revisiones de «Gestión del programa - 17 18 - G2»
(→Gestión de incidencias) |
|||
Línea 57: | Línea 57: | ||
== Gestión del código == | == Gestión del código == | ||
+ | |||
+ | |||
+ | |||
+ | === Formato general de commits === | ||
+ | El formato general de los commits parte de la siguiente [http://karma-runner.github.io/1.0/dev/git-commit-msg.html 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> | ||
Revisión del 19:03 2 dic 2017
Contenido
Objetivo del subsistema
Mejorar la introducción y gestión del programa así como facilitar los datos necesarios al grupo de visualización.
Consideraciones
Debe tener una API para, al menos, consultar los datos del programa y facilitarlos al grupo de Visualización.
Repositorio donde puede encontrarse el código:
https://github.com/jagalindo/program-manager-wpp
Wiki de la asignatura referente al módulo:
https://1984.lsi.us.es/wiki-egc/index.php/Gesti%C3%B3n_del_programa_-_17_18
Tecnologías Usadas
Subsistema: Gestión de programas Lenguaje/Herramienta: Eclipse -> Php Sistema de gestión de bibliotecas: Composer Bibliotecas: <Listado de bibliotecas usadas en el desarrollo.> Necesita Base de datos: Sí (todavía no definida)
Api
Consultar los datos del programa
Miembros del equipo
Jose Felix Gomez Rodriguez Coordinador - Ingeniero Software
Jose Manuel Luque Mendoza Ingeniero Software
Samuel Gonzalez Zuluaga Ingeniero Software
Felix Blanco Castaño Ingeniero Software
Jose Manuel Lara Morilla Ingeniero Software
Gestión de las tareas
La gestión y asignación de tareas se llevará a cabo mediante Trello. Dentro del tablero aparecerán 3 columnas, que serían las siguientes:
- Tareas a realizar: aquellas tareas que estén pendientes de su comienzo.
- Tareas en proceso: aquellas tareas que ya han comenzado.
- Tareas finalizadas: aquellas tareas que han sido terminadas.
Entorno de desarrollo
Gestión del código
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>
Gestión de incidencias
Detallar incidencias:
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 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>"