Revisión actual del 17:48 7 ene 2017

Contenido

1 Aspectos organizativos

Aspectos organizativos

Miembros

José Renato Ramos González: Project Manager
José Gavilán Ruiz: Software Developer
Eva Menendez Montes: Software Developer
Andrés Miguel Jiménez Ríos: Software Developer
Andrés Doncel Ramírez: Software Developer

Opera

Enlace al grupo en Opera: http://opera.eii.us.es/egc/public/trabajo/ver/id/62

Actas

07-10-2016

Participantes:
- José Renato Ramos González
- José Gavilán Ruiz
- Eva Menéndez Montes
- Andrés Miguel Jiménez Ríos
- Andrés Doncel Ramírez

Duración: 60 minutos

Conclusiones:

Tras conversaciones informales realizadas en días previos, se lleva a cabo una reunión para formalizar el equipo de trabajo, formado por todos los integrantes nombrados anteriormente.

Para facilitar la comunicación entre los distintos miembros, se llega al acuerdo de utilizar el servicio de mensajería Telegram, y se crea el grupo en la misma reunión.

06-11-2016

Participantes:
- José Renato Ramos González
- José Gavilán Ruiz
- Eva Menéndez Montes
- Andrés Miguel Jiménez Ríos
- Andrés Doncel Ramírez

Duración: 120 minutos

Conclusiones:

En esta reunión se lleva a cabo una discusión sobre las distintas ramas de las que se compondrá nuestro proyecto. Se decide trabajar en una rama “dev”, y solo cuando la funcionalidad en esta esté probada se juntará con la rama master.

Como gestor de incidencias, decidimos usar las mismas issues de GitHub, determinando el proceso detalladamente.

Además, nos encontramos con un problema inesperado, dos personas desconocidas para nosotros se habían registrado en nuestro grupo de Opera, pero sin informarnos previamente. Tras intercambiar diversos correos con estas dos personas y debatir entre nosotros, llegamos a la conclusión de que, por el momento, no los consideraríamos parte del grupo, y que al día siguiente en clase intentaríamos aclarar lo ocurrido con ellos y con David Benavides.

15-11-2016

Participantes:
- José Renato Ramos González
- José Gavilán Ruiz
- Eva Menéndez Montes
- Andrés Miguel Jiménez Ríos
- Andrés Doncel Ramírez

Duración: 90 minutos

Conclusiones:

Nuestro jefe de proyecto, José Renato Ramos, nos informa de la propuesta de integración continua que se está llevando a cabo y de que debemos nombrar un encargado para la misma, aunque no se realiza la elección en ese momento, sino que se decide aplazarla.

También se propone como incremento del proyecto realizar un cambio de Spring a Node. Una vez discutidos las ventajas y los inconvenientes de dicho cambio, siendo el más importante de ellos que la mayoría de los integrantes del grupo desconocíamos la herramienta, se decide llevarlo a cabo.

24-11-2016

Participantes:
- José Renato Ramos González
- José Gavilán Ruiz
- Eva Menéndez Montes
- Andrés Miguel Jiménez Ríos
- Andrés Doncel Ramírez

Duración: 90 minutos

Conclusiones:

El encargado de la integración continua del grupo, Andrés M. Jiménez, nos vuelve a explicar el proceso de integración continua con más detalle que el día anterior a través del grupo de Telegram.

Una vez hecho esto, se proponen distintas actividades que se pueden realizar para seguir mejorando el proyecto, entre ellos la integración con el módulo de Recuento y una refactorización de archivos CSS, JavaScript e imágenes del proyecto, nombrando encargados para las mismas.

Por último, se estuvo investigando sobre un error que encontramos que se producía en el CSS cuando recargábamos la página.

29-12-2016

Duración:30 minutos

Se asignaron los apartados imprescindibles para la redacción documento de entrega final:

Resumen: Eva Menéndez
Introducción y contexto: José Gavilán
Descripción del sistema: Eva Menéndez
Elementos de control: Renato González
Entorno de desarrollo: José Gavilán
Gestión del código fuente: Andrés Doncel
Gestión construcción e integración continua: Andrés Jiménez
Gestión del cambio e incidencias: Andrés Doncel
Gestión de liberaciones y despliegue: Andrés Jiménez
Mapa de herramientas: Renato González
Conclusiones: ¿?

Queda pendiente asignar las conclusiones para una próxima reunión, preferiblemente cuando el resto de apartados hayan sido completados.

06-01-2017

Participantes:
- José Renato Ramos González
- José Gavilán Ruiz
- Eva Menéndez Montes
- Andrés Miguel Jiménez Ríos
- Andrés Doncel Ramírez

Duración: 60 minutos

Conclusiones:

Esta reunión tiene como objetivo poner en común las distintas conclusiones que hemos sacado a lo largo del proyecto, para poder incluirlas posteriormente en el documento de la entrega final.

Una vez comentadas las distintas conclusiones, y habiendo tomado nota debidamente de las mismas, se nombra a Andrés Doncel como encargado de redactarlas en el documento final.

Gestión de código

Se trabajará en una rama "dev". Los cambios en local se harán en una copia de esta rama

Cada versión se etiquetará como vX.Y.Z, siendo X la versión mayor, Y la menor, y Z la revisión. Las versiones candidatas se marcarán con "c" (de candidate) tras la versión.

Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en "dev" se juntará con la rama "master", marcando esa versión como "r" (de release).

Gestión de incidencias

Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:

Descripción
Pasos a ejecutar
Resultado esperado
Resultado obtenido

Se espera compromiso por parte de los desarrolladores para que resuelvan activamente las incidencias surgidas. Cuando un desarrollador quiera resolver un issue, puede auto asignárselo. Si hay issues con más de una semana sin resolver, el project manager puede asignar a un desarrollador para que resuleva la incidencia.

Cuando una incidencia está resuelta, se debe indicar en el issue correspondiente. Es deseable hacer una referencia al commit que resuelve la incidencia, aunque no necesario. Una vez resuelta la incidencia, esta puede cerrarse.

Tipos de incidencias

example: para ejemplos de cómo resolver incidencias
bug: para informar de un error en el funcionamiento del código
enhancement: para proponer una nueva funcionalidad
help wanted y question: para dudas sobre el funcionamiento en general

Prioridad y estado de incidencias

A continuación, tenemos el asunto de las prioridades. Hay tres etiquetas de alta, media y baja prioridad. La actual es de alta prioridad.

Esto se complementa con las etiquetas de duplicate, invalid y wontfix, que indican, explicación previa, que la incidencia no es válida y no se va a resolver. Se procederá a cerrar la incidencia inmediatamente.

Por último, el estado de la incidencia se marca con solo dos etiquetas:

started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla
fixed: indica que la incidencia ha sido resuelta y verificada. Se espera confirmación del usuario que indicó la incidencia para que compruebe que realmente el problema está resuelto.

Si es así, se puede cerrar la incidencia.

En caso contrario, se debe volver a marcar la etiqueta started.

Como es natural. NO se puede cerrar un issue que esté en estado started, sino que debe pasar a fixed, duplicate, invalid o wontfix (siempre con explicación previa) antes de poder cerrarse.

Integración continua

La idea es tener un sistema de despliegue e integración continua durante el desarrollo de los proyectos con el fin de facilitar tanto el desarrollo como la integración de los subsistemas. Para ello se ha pensado que dicha integración constará de 3 partes:

Fase make. En esta fase se descarga el código tras una modificación y se prepara para ser lanzado. En ocasiones podrían ejecutarse test para comprobar su integridad antes del despliegue. En nuestro caso, no se hace nada.

 https://jenkins.egc.duckdns.org/

Fase beta. Esta fase se ejecuta automáticamente tras la finalización de la fase make. Se elimina la aplicación ya desplegada y se lanza la compilada en la fase make.

 https://beta.frontend.agoraus1.egc.duckdns.org/

Fase stable. Esta fase se ejecuta manualmente por el administración del Jenkins. Se diferencia de la fase beta en la estabilidad, algo necesario para la interacción por parte de los otros subsistemas con él. El código ejecutado en esta fase debe ser el mismo que el de la fase beta para corroborar su estabilidad antes de ejecutar este despliegue.

 https://frontend.agoraus1.egc.duckdns.org/

Para la configurar Jenkins, nos hace falta utilizar un docker con la configuración de nuestro proyecto. Para eso, se ha utilizado la imagen: https://hub.docker.com/r/anapsix/nodejs/ ya que incluye todo lo que nos hace falta: nodeJS y sus comandos iniciales: _npm install_ y _npm start_. Los comandos para ejercutar en local el código son:

git clone https://github.com/AgoraUS-G1-1617/Frontend.git

git pull --all

sudo apt-get install docker.io

sudo docker pull anapsix/nodejs

sudo docker run -ti --expose=8080 -p 8081:8080 -v /home/usuario/Frontend/:/app/ -w /app anapsix/nodejs

Integración continua de pruebas

Las pruebas se realizarán con los framework Jasmine y Karma. Para la automatización de las mismas se utilizará Travis, dado su fácil integración con Karma.

Repositorio de código

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

Subsistemas relacionados

Recuento y Modificación de resultados
Creación y administración de votaciones

@@ Línea 7: / Línea 7: @@
 * '''Andrés Miguel Jiménez Ríos''': Software Developer
 * '''Andrés Doncel Ramírez:''' Software Developer
+== Opera ==
+Enlace al grupo en Opera: http://opera.eii.us.es/egc/public/trabajo/ver/id/62
 == Actas ==
+===07-10-2016===
+*Participantes:
+**José Renato Ramos González
+**José Gavilán Ruiz
+**Eva Menéndez Montes
+**Andrés Miguel Jiménez Ríos
+**Andrés Doncel Ramírez
+*Duración: 60 minutos
+*Conclusiones:
+Tras conversaciones informales realizadas en días previos, se lleva a cabo una reunión para formalizar el equipo de trabajo, formado por todos los integrantes nombrados anteriormente.
+Para facilitar la comunicación entre los distintos miembros, se llega al acuerdo de utilizar el servicio de mensajería Telegram, y se crea el grupo en la misma reunión.
+===06-11-2016===
+*Participantes:
+**José Renato Ramos González
+**José Gavilán Ruiz
+**Eva Menéndez Montes
+**Andrés Miguel Jiménez Ríos
+**Andrés Doncel Ramírez
+*Duración: 120 minutos
+*Conclusiones:
+En esta reunión se lleva a cabo una discusión sobre las distintas ramas de las que se compondrá nuestro proyecto. Se decide trabajar en una rama “dev”, y solo cuando la funcionalidad en esta esté probada se juntará con la rama master.
+Como gestor de incidencias, decidimos usar las mismas issues de GitHub, determinando el proceso detalladamente.
+Además, nos encontramos con un problema inesperado, dos personas desconocidas para nosotros se habían registrado en nuestro grupo de Opera, pero sin informarnos previamente. Tras intercambiar diversos correos con estas dos personas y debatir entre nosotros, llegamos a la conclusión de que, por el momento, no los consideraríamos parte del grupo, y que al día siguiente en clase intentaríamos aclarar lo ocurrido con ellos y con David Benavides.
+===15-11-2016===
+*Participantes:
+**José Renato Ramos González
+**José Gavilán Ruiz
+**Eva Menéndez Montes
+**Andrés Miguel Jiménez Ríos
+**Andrés Doncel Ramírez
+*Duración: 90 minutos
+*Conclusiones:
+Nuestro jefe de proyecto, José Renato Ramos, nos informa de la propuesta de integración continua que se está llevando a cabo y de que debemos nombrar un encargado para la misma, aunque no se realiza la elección en ese momento, sino que se decide aplazarla.
+También se propone como incremento del proyecto realizar un cambio de Spring a Node. Una vez discutidos las ventajas y los inconvenientes de dicho cambio, siendo el más importante de ellos que la mayoría de los integrantes del grupo desconocíamos la herramienta, se decide llevarlo a cabo.
+===24-11-2016===
+*Participantes:
+**José Renato Ramos González
+**José Gavilán Ruiz
+**Eva Menéndez Montes
+**Andrés Miguel Jiménez Ríos
+**Andrés Doncel Ramírez
+*Duración: 90 minutos
+*Conclusiones:
+El encargado de la integración continua del grupo, Andrés M. Jiménez, nos vuelve a explicar el proceso de integración continua con más detalle que el día anterior a través del grupo de Telegram.
+Una vez hecho esto, se proponen distintas actividades que se pueden realizar para seguir mejorando el proyecto, entre ellos la integración con el módulo de Recuento y una refactorización de archivos CSS, JavaScript e imágenes del proyecto, nombrando encargados para las mismas.
+Por último, se estuvo investigando sobre un error que encontramos que se producía en el CSS cuando recargábamos la página.
+===29-12-2016===
+Duración:30 minutos
+Se asignaron los apartados imprescindibles para la redacción documento de entrega final:
+*Resumen: Eva Menéndez
+*Introducción y contexto: José Gavilán
+*Descripción del sistema: Eva Menéndez
+*Elementos de control: Renato González
+*Entorno de desarrollo: José Gavilán
+*Gestión del código fuente: Andrés Doncel
+*Gestión construcción e integración continua: Andrés Jiménez
+*Gestión del cambio e incidencias: Andrés Doncel
+*Gestión de liberaciones y despliegue: Andrés Jiménez
+*Mapa de herramientas: Renato González
+*Conclusiones: ¿?
+Queda pendiente asignar las conclusiones para una próxima reunión, preferiblemente cuando el resto de apartados hayan sido completados.
+===06-01-2017===
+*Participantes:
+**José Renato Ramos González
+**José Gavilán Ruiz
+**Eva Menéndez Montes
+**Andrés Miguel Jiménez Ríos
+**Andrés Doncel Ramírez
+*Duración: 60 minutos
+*Conclusiones:
+Esta reunión tiene como objetivo poner en común las distintas conclusiones que hemos sacado a lo largo del proyecto, para poder incluirlas posteriormente en el documento de la entrega final.
+Una vez comentadas las distintas conclusiones, y habiendo tomado nota debidamente de las mismas, se nombra a Andrés Doncel como encargado de redactarlas en el documento final.
 == Gestión de código==
@@ Línea 27: / Línea 129: @@
 Cuando una incidencia está resuelta, se debe indicar en el issue correspondiente. Es deseable hacer una referencia al commit que resuelve la incidencia, aunque no necesario. Una vez resuelta la incidencia, esta puede cerrarse.
+===Tipos de incidencias===
+*example: para ejemplos de cómo resolver incidencias
+*bug: para informar de un error en el funcionamiento del código
+*enhancement: para proponer una nueva funcionalidad
+*help wanted y question: para dudas sobre el funcionamiento en general
+===Prioridad y estado de incidencias===
+A continuación, tenemos el asunto de las prioridades. Hay tres etiquetas de alta, media y baja prioridad. La actual es de alta prioridad.
+Esto se complementa con las etiquetas de duplicate, invalid y wontfix, que indican, explicación previa, que la incidencia no es válida y no se va a resolver. Se procederá a cerrar la incidencia inmediatamente.
+Por último, el estado de la incidencia se marca con solo dos etiquetas:
+*started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla
+*fixed: indica que la incidencia ha sido resuelta y verificada. Se espera confirmación del usuario que indicó la incidencia para que compruebe que realmente el problema está resuelto.
+Si es así, se puede cerrar la incidencia.
+En caso contrario, se debe volver a marcar la etiqueta started.
+Como es natural. NO se puede cerrar un issue que esté en estado started, sino que debe pasar a fixed, duplicate, invalid o wontfix (siempre con explicación previa) antes de poder cerrarse.
 == Integración continua ==
@@ Línea 33: / Línea 158: @@
 * Fase make. En esta fase se descarga el código tras una modificación y se prepara para ser lanzado. En ocasiones podrían ejecutarse test para comprobar su integridad antes del despliegue. En nuestro caso, no se hace nada.
    https://jenkins.egc.duckdns.org/
 * Fase beta. Esta fase se ejecuta automáticamente tras la finalización de la fase make. Se elimina la aplicación ya desplegada y se lanza la compilada en la fase make.
    https://beta.frontend.agoraus1.egc.duckdns.org/
 * Fase stable. Esta fase se ejecuta manualmente por el administración del Jenkins. Se diferencia de la fase beta en la estabilidad, algo necesario para la interacción por parte de los otros subsistemas con él. El código ejecutado en esta fase debe ser el mismo que el de la fase beta para corroborar su estabilidad antes de ejecutar este despliegue.
    https://frontend.agoraus1.egc.duckdns.org/
-Para la configurar Jenkins, nos hace falta utilizar un docker con la configuración de nuestro proyecto. Para eso, se ha utilizado la imagen: https://hub.docker.com/r/anapsix/nodejs/ ya que incluye todo lo que nos hace falta: nodeJS y sus comandos iniciales: `npm install` y `mpn start`.
+Para la configurar Jenkins, nos hace falta utilizar un docker con la configuración de nuestro proyecto. Para eso, se ha utilizado la imagen: https://hub.docker.com/r/anapsix/nodejs/ ya que incluye todo lo que nos hace falta: nodeJS y sus comandos iniciales: _npm install_ y _npm start_. Los comandos para ejercutar en local el código son:
+git clone https://github.com/AgoraUS-G1-1617/Frontend.git
+git pull --all
+sudo apt-get install docker.io
+sudo docker pull anapsix/nodejs
+sudo docker run -ti --expose=8080 -p 8081:8080 -v /home/usuario/Frontend/:/app/ -w /app anapsix/nodejs
+===Integración continua de pruebas ===
+Las pruebas se realizarán con los framework Jasmine y Karma. Para la automatización de las mismas se utilizará Travis, dado su fácil integración con Karma.
 == Repositorio de código ==
@@ Línea 45: / Línea 188: @@
 == Subsistemas relacionados ==
+*Recuento y Modificación de resultados
+*Creación y administración de votaciones

Diferencia entre revisiones de «Frontend y visualización de resultados 1617»