Deliberaciones 1617

De Wiki de EGC
Revisión del 15:33 4 dic 2016 de Javgarcal (discusión | contribuciones) (→‎Ecosistema de desarrollo)
Saltar a: navegación, buscar

Aspectos organizativos

Miembros

  • García Calvo, Javier: Coordinador de proyecto, desarrollador
  • López Ruiz, Manuel Francisco: Encargado de integración continua, desarrollador
  • Rodríguez Rosado, Juan Ramón: Desarrollador
  • Rodríguez Torres, José Antonio: Desarrollador
  • Márquez Domínguez, Bartolomé: Desarrollador

Actas

Las actas de reuniones formales que ha tenido el equipo de trabajo se encuentran en los enlaces que se muestran a continuación.

https://hdvirtual.us.es/discovirt/index.php/s/J8ZCMufoWckUEsh

https://hdvirtual.us.es/discovirt/index.php/s/3J1H4i8HtRpPNn0

Ecosistema de desarrollo

El ecosistema de desarrollo que utiliza el equipo de trabajo se encuentra disponible en enlace. Por favor, si desea descargarlo, pida las credenciales de acceso a un miembro del equipo de trabajo.

Se trata de una máquina virtual basada en Xubuntu 16.04 basada en Oracle VM VirtualBox.

En enlace se tiene un repositorio que aloja el script de configuración del entorno que ha preparado el equipo de trabajo, que descarga e instala todos los componentes necesarios para el desarrollo. En dicho repositorio también se dispone de un workspace preparado para ejecutar el proyecto en el contexto del ecosistema en cuestión.

Los componentes y las versiones que se utilizan se indican a continuación:

  • Java 7
  • Java 8
  • Maven (última versión disponible)
  • Tomcat 7.0.72
  • MySQL 5.7
  • Eclipse (jee-neon-1a)

Gestión de código fuente

La gestión de código fuente se realiza con el soporte de un sistema de control de versiones basado en git. El modo de trabajo del equipo se desarrolla en las líneas que siguen a continuación.

Haciendo uso de ramas, se tienen las siguientes:

  • master: En esta rama se puede encontrar código en línea base. El equipo de trabajo asegura, en la medida de lo posible, que el contenido de esta rama sea totalmente estable y no presente defectos.
  • develop: Rama de desarrollo en la que se tiene código más o menos estable. La idea que se persigue es disponer de una rama con código en fase beta, esto es, que ha sido probado de forma informal y no se han detectado errores aunque no se pueda asegurar la ausencia de los mismos.
  • ramas auxiliares: Se trata de ramas que se crearán cada vez que se vaya a hacer una modificación sobre el código de la rama develop. Pueden o no estar presentes en el repositorio remoto.

La política de gestión de código fuente que sigue el equipo de trabajo no permite la modificación de la rama master directamente. De esta forma, por cada modificación que se vaya a hacer sobre el código que se encuentra en la rama develop, se debe hacer pull de esta rama para estar en sincronía con la última versión del código y crear una rama auxiliar en el repositorio local y trabajar sobre la misma. Se pueden hacer los commits que se consideren oportunos en las ramas auxiliares. Una vez se haya dado por finalizada la modificación sobre el código y se haya comprobado que funciona correctamente y no ha afectado a otros componentes (en la medida de lo posible), se debe hacer merge de la rama develop con la rama auxiliar con las modificaciones ya realizadas. Después de esto y de forma trivial, se hace push de la rama develop para publicar en el repositorio remoto los últimos cambios, de tal forma que esté siempre lo más actualizado posible. Si hubiera conflictos, se resuelven.

Una vez se haya dado por finalizado el desarrollo tras una reunión en la que deben estar presente todos los miembros del equipo de trabajo y se haya asegurado mediante una comprobación exhaustiva que no se han encontrado deficiencias en el código desarrollado, se llevará el código de la rama develop a la rama master y se le asociará una etiqueta al último commit.

Gestión de incidencias

En cuanto a la gestión de incidencias, se llevan a cabo mediante issues en GitHub y un tablero kanban que se ha añadido haciendo uso del plugin ZenHub.

En dicho tablero se dispone de una serie de listas que indican el estado de las tareas que contienen. Estas listas son:

  • New Issues: incidencias que se han detectado y aún no han sido asignadas a un miembro del equipo o que no se han discutido con el resto de miembros del equipo.
  • Icebox: contiene las incidencias que el equipo de trabajo considera como no importantes y que probablemente no se resuelvan.
  • Backlog: en esta lista se muestran las incidencias que están pendientes de ser llevadas a cabo por el miembro del equipo que la tenga asignada. Una incidencia, normalmente, estará asociada solamente a un miembro del equipo de trabajo.
  • In Progress: incidencias que se están llevando a cabo, esto es, que ya han comenzado a resolverse pero aún no han terminado.
  • Review/QA: las incidencias que se encuentren en esta lista son aquellas que están pendientes de revisión por los miembros del equipo de trabajo.
  • Closed: incidencias que ya han sido revisadas a priori y que se consideran como terminadas.

El modo de gestión de incidencias se detalla a continuación.

Cuando un miembro del equipo de trabajo detecta una incidencia, la registra en GitHub y, si lo cree oportuno, se la asigna a sí mismo. Esta incidencia, normalmente (a no ser que suponga un cambio menor), se discute con el resto del equipo y pasa a Backlog. Cuando el miembro del equipo que la tenga asignada lo crea conveniente, comenzará a ocuparse de dicha incidencia, que pasará al estado In Progress. Cuando se esté realizando una incidencia, se espera que el miembro del equipo monitorice el tiempo que emplea en resolverla mediante la herramienta Toggl. Una vez haya finalizado la incidencia, se moverá a Review/QA y, cuando sea revisada por el resto de miembros del equipo de trabajo, se considerará como cerrada y se moverá a la lista Closed.

Integración continua

La integración continua del sistema se gestiona haciendo uso de las herramientas Jenkins, Maven y Docker.

Se dispone de dos versiones del sistema que están siempre desplegadas:

El código que se encuentra en la rama develop del repositorio remoto del proyecto se desplegará, de forma automática, en la URL correspondiente a la versión Beta cuando Jenkins detecte que ha habido cambios en el repositorio. En cuanto a la versión Stable, los cambios deberán ser publicados manualmente, por motivos de aseguramiento de la calidad, por un miembro del equipo de trabajo, siempre con la aprobación del resto de miembros del equipo y haciendo uso del código que se encuentra en la rama master.

Opera

Los entregables del grupo se encuentran en el enlace que se indica a continuación:

http://opera.eii.us.es/egc/public/trabajo/ver/id/44

Repositorio de código

El repositorio del equipo de trabajo está alojado en la plataforma GitHub bajo la organización AgoraUS-G1-1617, donde también se pueden encontrar el resto de subsistemas del curso 2016/17.

https://github.com/AgoraUS-G1-1617/Deliberations

Subsistemas relacionados

Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Deliberaciones_1617&oldid=5083»