Frontend y visualización de resultados 1617 - Historial de revisiones

Evamenmon: /* Actas */

2017-01-07T16:48:11Z

‎Actas

2017-01-06T17:38:45Z

‎Subsistemas relacionados

2016-12-29T16:01:01Z

‎29-12-2016

2016-12-29T16:00:18Z

‎Actas

2016-12-19T17:42:29Z

‎Integración continua

2016-12-01T17:36:18Z

‎Aspectos organizativos

2016-12-01T08:33:40Z

‎Integración continua

2016-12-01T08:33:06Z

‎Integración continua

2016-11-30T13:19:50Z

‎Prioridad y estado de incidencias

2016-11-30T13:19:26Z

‎Tipos de incidencias

@@ Línea 13: / Línea 13: @@
 == Actas ==
 ===29-12-2016===
@@ Línea 32: / Línea 96: @@
 Queda pendiente asignar las conclusiones para una próxima reunión, preferiblemente cuando el resto de apartados hayan sido completados.
 == Gestión de código==

← Revisión anterior		Revisión del 17:38 6 ene 2017
Línea 109:		Línea 109:

	== Subsistemas relacionados ==		== Subsistemas relacionados ==
		+
		+	*Recuento y Modificación de resultados
		+	*Creación y administración de votaciones

@@ Línea 19: / Línea 19: @@
 Se asignaron los apartados imprescindibles para la redacción documento de entrega final:
-Resumen: Eva Menéndez
+*Resumen: Eva Menéndez
-Introducción y contexto: José Gavilán
+*Introducción y contexto: José Gavilán
-Descripción del sistema: Eva Menéndez
+*Descripción del sistema: Eva Menéndez
-Elementos de control: Renato González
+*Elementos de control: Renato González
-Entorno de desarrollo: José Gavilán
+*Entorno de desarrollo: José Gavilán
-Gestión del código fuente: Andrés Doncel
+*Gestión del código fuente: Andrés Doncel
-Gestión construcción e integración continua: Andrés Jiménez
+*Gestión construcción e integración continua: Andrés Jiménez
-Gestión del cambio e incidencias: Andrés Doncel
+*Gestión del cambio e incidencias: Andrés Doncel
-Gestión de liberaciones y despliegue: Andrés Jiménez
+*Gestión de liberaciones y despliegue: Andrés Jiménez
-Mapa de herramientas: Renato González
+*Mapa de herramientas: Renato González
-Conclusiones: ¿?
+*Conclusiones: ¿?
 Queda pendiente asignar las conclusiones para una próxima reunión, preferiblemente cuando el resto de apartados hayan sido completados.

← Revisión anterior		Revisión del 16:00 29 dic 2016
Línea 13:		Línea 13:

	== Actas ==		== Actas ==
		+
		+	===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.

	== Gestión de código==		== Gestión de código==

← Revisión anterior		Revisión del 17:42 19 dic 2016
Línea 80:		Línea 80:

	sudo docker run -ti --expose=8080 -p 8081:8080 -v /home/usuario/Frontend/:/app/ -w /app 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 ==		== Repositorio de código ==

@@ Línea 7: / Línea 7: @@
 * '''Andrés Miguel Jiménez Ríos''': Software Developer
 * '''Andrés Doncel Ramírez:''' Software Developer
 == Actas ==

@@ Línea 62: / Línea 62: @@
 * 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

@@ Línea 63: / Línea 63: @@
    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:
 == Repositorio de código ==

@@ Línea 37: / Línea 37: @@
 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.
+*started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla
 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.

@@ Línea 29: / Línea 29: @@
 ===Tipos de incidencias===
--example: para ejemplos de cómo resolver incidencias
+*example: para ejemplos de cómo resolver incidencias
--bug: para informar de un error en el funcionamiento del código
+*bug: para informar de un error en el funcionamiento del código
--enhancement: para proponer una nueva funcionalidad
+*enhancement: para proponer una nueva funcionalidad
--help wanted y question: para dudas sobre el funcionamiento en general
+*help wanted y question: para dudas sobre el funcionamiento en general
 ===Prioridad y estado de incidencias===