Diferencia entre revisiones de «Verificación 1617»
(→Gestión de incidencias) |
(→Gestión de código fuente) |
||
Línea 21: | Línea 21: | ||
== Gestión de código fuente == | == Gestión de código fuente == | ||
+ | Usaremos un repositorio Git llamado AgoraUS1617 para administrar el código fuente del sistema. | ||
+ | En este repositorio, que se aloja en el servicio de alojamiento de repositorios Git Github, cada subsistema se desarrollará en un repositorio diferente dentro del repositorio global. En el repositorio AgoaUS se recogerá el trabajo realizado y funcional de todos los grupos y su correspondiente integración. | ||
+ | Usar un repositorio global facilita el acceso al código por parte de cada grupo. Podemos obtener el código de otros grupos clonando sus repositorios y haciendo pull, obteniendo así el código más reciente del subsistema en cuestión. | ||
+ | Usar un único repositorio nos facilitaría aun más el acceso al código ya que solo tendríamos que hacer pull de la rama master para obtener el código de los demás subsistemas pero nos encontraríamos con el inconveniente de que cualquier persona podría modificar lo que quisiera, independientemente del grupo en el q se halle. | ||
+ | Este inconveniente no se nos presenta porque sólo tenemos acceso de lectura a los repositorios a los que no pertenecemos. | ||
+ | Tampoco se nos presentará problemas de conflictos con los demás grupos al alojarnos en repositorios diferentes. | ||
+ | Si usásemos un único repositorio tendríamos que crear una carpeta o una rama para cada subsistema con el fin de evitar numerosos conflictos que se presentarían al compartir muchos subsistemas la misma estructura de archivos. | ||
== Gestión de incidencias == | == Gestión de incidencias == |
Revisión del 18:01 11 ene 2017
Contenido
- 1 Aspectos organizativos
Aspectos organizativos
Miembros
- Del Rio Franco, Rafael: Project Manager
- Navas Inocencio, Jesús: Software Developer
- Rodriguez Nuñez, Ernesto: Software Developer
- Rufo Palomo, Macarena: Software Developer
- Ruiz Navarro, Jose Carlos: Software Developer
Actas
Ecosistema de desarrollo
Gestión de código fuente
Usaremos un repositorio Git llamado AgoraUS1617 para administrar el código fuente del sistema. En este repositorio, que se aloja en el servicio de alojamiento de repositorios Git Github, cada subsistema se desarrollará en un repositorio diferente dentro del repositorio global. En el repositorio AgoaUS se recogerá el trabajo realizado y funcional de todos los grupos y su correspondiente integración. Usar un repositorio global facilita el acceso al código por parte de cada grupo. Podemos obtener el código de otros grupos clonando sus repositorios y haciendo pull, obteniendo así el código más reciente del subsistema en cuestión. Usar un único repositorio nos facilitaría aun más el acceso al código ya que solo tendríamos que hacer pull de la rama master para obtener el código de los demás subsistemas pero nos encontraríamos con el inconveniente de que cualquier persona podría modificar lo que quisiera, independientemente del grupo en el q se halle. Este inconveniente no se nos presenta porque sólo tenemos acceso de lectura a los repositorios a los que no pertenecemos. Tampoco se nos presentará problemas de conflictos con los demás grupos al alojarnos en repositorios diferentes. Si usásemos un único repositorio tendríamos que crear una carpeta o una rama para cada subsistema con el fin de evitar numerosos conflictos que se presentarían al compartir muchos subsistemas la misma estructura de archivos.
Gestión de incidencias
Para la gestión de incidencias usaremos las Issue de GitHub.
Una vez encontremos una incidencia tendremos que:
- Analizar:
Las incidencias serán analizadas por al menos dos miembros del equipo, los cuales reproducirán la incidencia (para ello se espera que el autor de la incidencia de todos los detalles para poder reproducir lo ocurrido), analizaran y clasifican según su prioridad:
- ALTA: Un servicio se ve afectado de manera severa impidiendo su uso y afectando a actividades críticas de negocio.
- MEDIA: Un servicio se ve afectado impidiendo su uso pero no afectando a actividades críticas de negocio.
- BAJA: Un servicio se ve afectado pero no impide su uso.
- Resolución:
La resolución de la incidencia será asignada a un miembro del equipo, el cual debe resolverla.
En el caso de tener más de una incidencia asignada, se resolverán por orden de prioridad, siendo el orden de prioridad en resolverla ALTA, MEDIA, y BAJA.
Una vez solucionado, será subido a gitHub.
- Revisión:
Se asignará un miembro del equipo (puede ser el que realizó la resolución), el cual deberá revisar que la resolución es correcta.
- Cierre:
Se cerrará la incidencia y se documentará la solución tomada.
Integración continua
La integración continua del sistema se gestiona haciendo uso de las herramientas Jenkins, Maven y Docker.
Jenkins
- Consiste en hacer integraciones automáticas de un proyecto con el objetivo de detectar fallos cuanto antes. Consta de tres fases: Make, Beta y Stable.
*Fase Make (URL) Se encarga de descargar el proyecto tras una modificación, ejecutar test para comprobar la integridad y desplegarlo, es decir, ejecutar los test y todas las acciones oportunas antes de desplegar el proyecto.
*Fase Beta (URL) Se encarga de eliminar restos de despliegue anterior, preparar el despliegue y desplegar.
*Fase Stable (URL) Se ejecuta manualmente y las fases principales son las mismas que en la fase Beta y usa los archivos provenientes de la misma con el fin de conseguir la estabilidad del proyecto.
Travis
- Travis será la encargada de comprobar de lanzar comandos de Maven con el objetivo de comprobar los test de la aplicación, y esto lo hará cuando detecte un commit. Además, Travis añadirá automáticamente añade el verificacion1.jar.
- El objetivo de esto, es automatizar la construcción, la entrega y despliegue del sistema y la ejecución de pruebas
Subsistemas relacionados
Tiempos individuales
Autor | Tarea | Comienzo | Fin | Duración (hh:mm) |
---|---|---|---|---|
Rafael Del Rio Franco | Reunión I | 12-10-2016 17:30 | 12-10-2016 18:30 | 01:00 |
Jesus Navas Inocencio | Reunión I | 12-10-2016 17:30 | 12-10-2016 18:30 | 01:00 |
Macarena Rufo Palomo | Reunión I | 12-10-2016 17:30 | 12-10-2016 18:30 | 01:00 |
Jose Carlos Ruiz Navarro | Reunión I | 12-10-2016 17:30 | 12-10-2016 18:30 | 01:00 |
Ernesto Rodriguez Nuñez | Reunión I | 12-10-2016 17:30 | 12-10-2016 18:30 | 01:00 |
Rafael Del Rio Franco | Milestone 1 | 09-11-2016 10:40 | 09-11-2016 12:30 | 01:50 |
Jesus Navas Inocencio | Milestone 1 | 09-11-2016 10:40 | 09-11-2016 12:30 | 01:50 |
Macarena Rufo Palomo | Milestone 1 | 09-11-2016 10:40 | 09-11-2016 12:30 | 01:50 |
Jose Carlos Ruiz Navarro | Milestone 1 | 09-11-2016 10:40 | 09-11-2016 12:30 | 01:50 |
Ernesto Rodriguez Nuñez | Milestone 1 | 09-2016 10:40 | 09-11-2016 12:30 | 01:50 |
Rafael Del Rio Franco | Reunión II | 09-11-2016 17:30 | 09-11-2016 18:30 | 01:30 |
Jesus Navas Inocencio | Reunión II | 09-11-2016 17:30 | 09-11-2016 18:30 | 01:30 |
Macarena Rufo Palomo | Reunión II | 09-11-2016 17:30 | 09-11-2016 18:30 | 01:30 |
Jose Carlos Ruiz Navarro | Reunión II | 09-11-2016 17:30 | 09-11-2016 18:30 | 01:30 |
Ernesto Rodriguez Nuñez | Reunión II | 09-11-2016 17:30 | 09-11-2016 18:30 | 01:30 |
Rafael Del Rio Franco | Milestone 2 | 30-11-2016 10:40 | 30-11-2016 12:30 | 01:50 |
Jesus Navas Inocencio | Milestone 2 | 30-11-2016 10:40 | 30-11-2016 12:30 | 01:50 |
Macarena Rufo Palomo | Milestone 2 | 30-11-2016 10:40 | 30-11-2016 12:30 | 01:50 |
Jose Carlos Ruiz Navarro | Milestone 2 | 30-11-2016 10:40 | 30-11-2016 12:30 | 01:50 |
Ernesto Rodriguez Nuñez | Milestone 2 | 30-11-2016 10:40 | 30-11-2016 12:30 | 01:50 |
Rafael Del Rio Franco | Reunión III | 07-12-2016 10:30 | 07-12-2016 13:40 | 03:10 |
Jesus Navas Inocencio | Reunión III | 07-12-2016 10:30 | 07-12-2016 13:40 | 03:10 |
Macarena Rufo Palomo | Reunión III | 07-12-2016 10:30 | 07-12-2016 13:40 | 03:10 |
Jose Carlos Ruiz Navarro | Reunión III | 07-12-2016 10:30 | 07-12-2016 13:40 | 03:10 |
Ernesto Rodriguez Nuñez | Reunión III | 07-12-2016 10:30 | 07-12-2016 13:40 | 03:10 |
Rafael Del Rio Franco | Milestone 3 | 21-12-2016 10:40 | 21-12-2016 12:30 | 01:50 |
Jesus Navas Inocencio | Milestone 3 | 21-12-2016 10:40 | 21-12-2016 12:30 | 01:50 |
Macarena Rufo Palomo | Milestone 3 | 21-12-2016 10:40 | 21-12-2016 12:30 | 01:50 |
Jose Carlos Ruiz Navarro | Milestone 3 | 21-12-2016 10:40 | 21-12-2016 12:30 | 01:50 |
Ernesto Rodriguez Nuñez | Milestone 3 | 21-12-2016 10:40 | 21-12-2016 12:30 | 01:50 |
Rafael Del Rio Franco | Reunión IV | 27-12-2016 10:30 | 27-12-2016 14:00 | 03:30 |
Jesus Navas Inocencio | Reunión IV | 27-12-2016 10:30 | 27-12-2016 14:00 | 03:30 |
Macarena Rufo Palomo | Reunión IV | 27-12-2016 10:30 | 27-12-2016 14:00 | 03:30 |
Jose Carlos Ruiz Navarro | Reunión IV | 27-12-2016 10:30 | 27-12-2016 14:00 | 03:30 |
Ernesto Rodriguez Nuñez | Reunión IV | 27-12-2016 10:30 | 27-12-2016 14:00 | 03:30 |
Rafael Del Rio Franco | Reunión V | 27-12-2016 15:30 | 27-12-2016 17:30 | 02:00 |
Jesus Navas Inocencio | Reunión V | 27-12-2016 15:30 | 27-12-2016 17:30 | 02:00 |
Macarena Rufo Palomo | Reunión V | 27-12-2016 15:30 | 27-12-2016 17:30 | 02:00 |
Jose Carlos Ruiz Navarro | Reunión V | 27-12-2016 15:30 | 27-12-2016 17:30 | 02:00 |
Ernesto Rodriguez Nuñez | Reunión V | 27-12-2016 15:30 | 27-12-2016 17:30 | 02:00 |
Rafael Del Rio Franco | Reunión VI | 28-12-2016 10:30 | 28-12-2016 13:30 | 03:00 |
Jesus Navas Inocencio | Reunión VI | 28-12-2016 10:30 | 28-12-2016 13:30 | 03:00 |
Macarena Rufo Palomo | Reunión VI | 28-12-2016 10:30 | 28-12-2016 13:30 | 03:00 |
Jose Carlos Ruiz Navarro | Reunión VI | 28-12-2016 10:30 | 28-12-2016 13:30 | 03:00 |
Ernesto Rodriguez Nuñez | Reunión VI | 28-12-2016 10:30 | 28-12-2016 13:30 | 03:00 |
Rafael Del Rio Franco | Reunión VII | 09-01-2017 09:30 | 09-01-2017 14:00 | 05:30 |
Jesus Navas Inocencio | Reunión VII | 09-01-2017 09:30 | 09-01-2017 14:00 | 05:30 |
Macarena Rufo Palomo | Reunión VII | 09-01-2017 09:30 | 09-01-2017 14:00 | 05:30 |
Jose Carlos Ruiz Navarro | Reunión VII | 09-01-2017 09:30 | 09-01-2017 14:00 | 05:30 |
Ernesto Rodriguez Nuñez | ReuniónVII | 09-01-2017 09:30 | 09-01-2017 14:00 | 05:30 |
TOTAL | 119:30:00 |
Repositorio de código
Se utilizará Git como herramienta de gestión de código ya que permite la posibilidad de realizar commits locales. Además esto supone el uso de una característica que el equipo no ha utilizado anteriormente, por lo que supone una oportunidad para aprender un nuevo software de control de versiones.
Sitio de despliegue del subsistema
Este subsistema no está diseñado para despliegue web, sino para despliegue en forma de librería .jar consumida por otros subsistemas.
Proyecto en Opera
La forma en la que haremos entregar los distintos entregables del proyecto para su posterior corrección sera haciendo uso del portal Opera. El espacio usado por este proyecto de opera es el siguiente: