https://1984.lsi.us.es/wiki-egc/api.php?action=feedcontributions&feedformat=atom&user=Anddonram 2026-04-24T08:47:02Z Contribuciones del usuario MediaWiki 1.29.0 https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=5470 2017-01-06T17:38:45Z

<p>Anddonram: /* Subsistemas relacionados */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Opera ==<br /> <br /> Enlace al grupo en Opera: http://opera.eii.us.es/egc/public/trabajo/ver/id/62<br /> <br /> == Actas ==<br /> <br /> ===29-12-2016===<br /> Duración:30 minutos<br /> <br /> Se asignaron los apartados imprescindibles para la redacción documento de entrega final:<br /> <br /> *Resumen: Eva Menéndez<br /> *Introducción y contexto: José Gavilán<br /> *Descripción del sistema: Eva Menéndez<br /> *Elementos de control: Renato González<br /> *Entorno de desarrollo: José Gavilán<br /> *Gestión del código fuente: Andrés Doncel<br /> *Gestión construcción e integración continua: Andrés Jiménez<br /> *Gestión del cambio e incidencias: Andrés Doncel<br /> *Gestión de liberaciones y despliegue: Andrés Jiménez<br /> *Mapa de herramientas: Renato González<br /> *Conclusiones: ¿?<br /> <br /> Queda pendiente asignar las conclusiones para una próxima reunión, preferiblemente cuando el resto de apartados hayan sido completados.<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> ===Tipos de incidencias===<br /> *example: para ejemplos de cómo resolver incidencias<br /> *bug: para informar de un error en el funcionamiento del código<br /> *enhancement: para proponer una nueva funcionalidad<br /> *help wanted y question: para dudas sobre el funcionamiento en general<br /> <br /> ===Prioridad y estado de incidencias===<br /> <br /> A continuación, tenemos el asunto de las prioridades. Hay tres etiquetas de alta, media y baja prioridad. La actual es de alta prioridad.<br /> <br /> 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.<br /> <br /> Por último, el estado de la incidencia se marca con solo dos etiquetas:<br /> <br /> *started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla<br /> *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.<br /> <br /> Si es así, se puede cerrar la incidencia.<br /> <br /> En caso contrario, se debe volver a marcar la etiqueta started.<br /> <br /> 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.<br /> <br /> == Integración continua ==<br /> 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:<br /> <br /> * 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.<br /> https://jenkins.egc.duckdns.org/<br /> <br /> * 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.<br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> * 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.<br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> <br /> 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:<br /> <br /> git clone https://github.com/AgoraUS-G1-1617/Frontend.git<br /> <br /> git pull --all<br /> <br /> <br /> sudo apt-get install docker.io<br /> <br /> sudo docker pull anapsix/nodejs<br /> <br /> sudo docker run -ti --expose=8080 -p 8081:8080 -v /home/usuario/Frontend/:/app/ -w /app anapsix/nodejs<br /> <br /> ===Integración continua de pruebas ===<br /> <br /> 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.<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==<br /> <br /> *Recuento y Modificación de resultados<br /> *Creación y administración de votaciones</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=5324 2016-12-29T16:01:01Z

<p>Anddonram: /* 29-12-2016 */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Opera ==<br /> <br /> Enlace al grupo en Opera: http://opera.eii.us.es/egc/public/trabajo/ver/id/62<br /> <br /> == Actas ==<br /> <br /> ===29-12-2016===<br /> Duración:30 minutos<br /> <br /> Se asignaron los apartados imprescindibles para la redacción documento de entrega final:<br /> <br /> *Resumen: Eva Menéndez<br /> *Introducción y contexto: José Gavilán<br /> *Descripción del sistema: Eva Menéndez<br /> *Elementos de control: Renato González<br /> *Entorno de desarrollo: José Gavilán<br /> *Gestión del código fuente: Andrés Doncel<br /> *Gestión construcción e integración continua: Andrés Jiménez<br /> *Gestión del cambio e incidencias: Andrés Doncel<br /> *Gestión de liberaciones y despliegue: Andrés Jiménez<br /> *Mapa de herramientas: Renato González<br /> *Conclusiones: ¿?<br /> <br /> Queda pendiente asignar las conclusiones para una próxima reunión, preferiblemente cuando el resto de apartados hayan sido completados.<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> ===Tipos de incidencias===<br /> *example: para ejemplos de cómo resolver incidencias<br /> *bug: para informar de un error en el funcionamiento del código<br /> *enhancement: para proponer una nueva funcionalidad<br /> *help wanted y question: para dudas sobre el funcionamiento en general<br /> <br /> ===Prioridad y estado de incidencias===<br /> <br /> A continuación, tenemos el asunto de las prioridades. Hay tres etiquetas de alta, media y baja prioridad. La actual es de alta prioridad.<br /> <br /> 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.<br /> <br /> Por último, el estado de la incidencia se marca con solo dos etiquetas:<br /> <br /> *started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla<br /> *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.<br /> <br /> Si es así, se puede cerrar la incidencia.<br /> <br /> En caso contrario, se debe volver a marcar la etiqueta started.<br /> <br /> 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.<br /> <br /> == Integración continua ==<br /> 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:<br /> <br /> * 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.<br /> https://jenkins.egc.duckdns.org/<br /> <br /> * 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.<br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> * 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.<br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> <br /> 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:<br /> <br /> git clone https://github.com/AgoraUS-G1-1617/Frontend.git<br /> <br /> git pull --all<br /> <br /> <br /> sudo apt-get install docker.io<br /> <br /> sudo docker pull anapsix/nodejs<br /> <br /> sudo docker run -ti --expose=8080 -p 8081:8080 -v /home/usuario/Frontend/:/app/ -w /app anapsix/nodejs<br /> <br /> ===Integración continua de pruebas ===<br /> <br /> 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.<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=5323 2016-12-29T16:00:18Z

<p>Anddonram: /* Actas */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Opera ==<br /> <br /> Enlace al grupo en Opera: http://opera.eii.us.es/egc/public/trabajo/ver/id/62<br /> <br /> == Actas ==<br /> <br /> ===29-12-2016===<br /> Duración:30 minutos<br /> <br /> Se asignaron los apartados imprescindibles para la redacción documento de entrega final:<br /> <br /> Resumen: Eva Menéndez<br /> Introducción y contexto: José Gavilán<br /> Descripción del sistema: Eva Menéndez<br /> Elementos de control: Renato González<br /> Entorno de desarrollo: José Gavilán<br /> Gestión del código fuente: Andrés Doncel<br /> Gestión construcción e integración continua: Andrés Jiménez<br /> Gestión del cambio e incidencias: Andrés Doncel<br /> Gestión de liberaciones y despliegue: Andrés Jiménez<br /> Mapa de herramientas: Renato González<br /> Conclusiones: ¿?<br /> <br /> Queda pendiente asignar las conclusiones para una próxima reunión, preferiblemente cuando el resto de apartados hayan sido completados.<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> ===Tipos de incidencias===<br /> *example: para ejemplos de cómo resolver incidencias<br /> *bug: para informar de un error en el funcionamiento del código<br /> *enhancement: para proponer una nueva funcionalidad<br /> *help wanted y question: para dudas sobre el funcionamiento en general<br /> <br /> ===Prioridad y estado de incidencias===<br /> <br /> A continuación, tenemos el asunto de las prioridades. Hay tres etiquetas de alta, media y baja prioridad. La actual es de alta prioridad.<br /> <br /> 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.<br /> <br /> Por último, el estado de la incidencia se marca con solo dos etiquetas:<br /> <br /> *started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla<br /> *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.<br /> <br /> Si es así, se puede cerrar la incidencia.<br /> <br /> En caso contrario, se debe volver a marcar la etiqueta started.<br /> <br /> 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.<br /> <br /> == Integración continua ==<br /> 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:<br /> <br /> * 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.<br /> https://jenkins.egc.duckdns.org/<br /> <br /> * 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.<br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> * 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.<br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> <br /> 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:<br /> <br /> git clone https://github.com/AgoraUS-G1-1617/Frontend.git<br /> <br /> git pull --all<br /> <br /> <br /> sudo apt-get install docker.io<br /> <br /> sudo docker pull anapsix/nodejs<br /> <br /> sudo docker run -ti --expose=8080 -p 8081:8080 -v /home/usuario/Frontend/:/app/ -w /app anapsix/nodejs<br /> <br /> ===Integración continua de pruebas ===<br /> <br /> 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.<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=5240 2016-12-19T17:42:29Z

<p>Anddonram: /* Integración continua */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Opera ==<br /> <br /> Enlace al grupo en Opera: http://opera.eii.us.es/egc/public/trabajo/ver/id/62<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> ===Tipos de incidencias===<br /> *example: para ejemplos de cómo resolver incidencias<br /> *bug: para informar de un error en el funcionamiento del código<br /> *enhancement: para proponer una nueva funcionalidad<br /> *help wanted y question: para dudas sobre el funcionamiento en general<br /> <br /> ===Prioridad y estado de incidencias===<br /> <br /> A continuación, tenemos el asunto de las prioridades. Hay tres etiquetas de alta, media y baja prioridad. La actual es de alta prioridad.<br /> <br /> 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.<br /> <br /> Por último, el estado de la incidencia se marca con solo dos etiquetas:<br /> <br /> *started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla<br /> *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.<br /> <br /> Si es así, se puede cerrar la incidencia.<br /> <br /> En caso contrario, se debe volver a marcar la etiqueta started.<br /> <br /> 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.<br /> <br /> == Integración continua ==<br /> 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:<br /> <br /> * 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.<br /> https://jenkins.egc.duckdns.org/<br /> <br /> * 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.<br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> * 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.<br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> <br /> 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:<br /> <br /> git clone https://github.com/AgoraUS-G1-1617/Frontend.git<br /> <br /> git pull --all<br /> <br /> <br /> sudo apt-get install docker.io<br /> <br /> sudo docker pull anapsix/nodejs<br /> <br /> sudo docker run -ti --expose=8080 -p 8081:8080 -v /home/usuario/Frontend/:/app/ -w /app anapsix/nodejs<br /> <br /> ===Integración continua de pruebas ===<br /> <br /> 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.<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4957 2016-11-30T13:19:50Z

<p>Anddonram: /* Prioridad y estado de incidencias */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> ===Tipos de incidencias===<br /> *example: para ejemplos de cómo resolver incidencias<br /> *bug: para informar de un error en el funcionamiento del código<br /> *enhancement: para proponer una nueva funcionalidad<br /> *help wanted y question: para dudas sobre el funcionamiento en general<br /> <br /> ===Prioridad y estado de incidencias===<br /> <br /> A continuación, tenemos el asunto de las prioridades. Hay tres etiquetas de alta, media y baja prioridad. La actual es de alta prioridad.<br /> <br /> 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.<br /> <br /> Por último, el estado de la incidencia se marca con solo dos etiquetas:<br /> <br /> *started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla<br /> *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.<br /> <br /> Si es así, se puede cerrar la incidencia.<br /> <br /> En caso contrario, se debe volver a marcar la etiqueta started.<br /> <br /> 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.<br /> <br /> == Integración continua ==<br /> 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:<br /> <br /> * 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.<br /> https://jenkins.egc.duckdns.org/<br /> <br /> * 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.<br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> * 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.<br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> 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`.<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4956 2016-11-30T13:19:26Z

<p>Anddonram: /* Tipos de incidencias */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> ===Tipos de incidencias===<br /> *example: para ejemplos de cómo resolver incidencias<br /> *bug: para informar de un error en el funcionamiento del código<br /> *enhancement: para proponer una nueva funcionalidad<br /> *help wanted y question: para dudas sobre el funcionamiento en general<br /> <br /> ===Prioridad y estado de incidencias===<br /> <br /> A continuación, tenemos el asunto de las prioridades. Hay tres etiquetas de alta, media y baja prioridad. La actual es de alta prioridad.<br /> 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.<br /> Por último, el estado de la incidencia se marca con solo dos etiquetas:<br /> -started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla<br /> -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.<br /> Si es así, se puede cerrar la incidencia.<br /> En caso contrario, se debe volver a marcar la etiqueta started.<br /> 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.<br /> <br /> == Integración continua ==<br /> 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:<br /> <br /> * 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.<br /> https://jenkins.egc.duckdns.org/<br /> <br /> * 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.<br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> * 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.<br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> 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`.<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4955 2016-11-30T13:18:01Z

<p>Anddonram: /* Gestión de incidencias */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> ===Tipos de incidencias===<br /> -example: para ejemplos de cómo resolver incidencias<br /> -bug: para informar de un error en el funcionamiento del código<br /> -enhancement: para proponer una nueva funcionalidad<br /> -help wanted y question: para dudas sobre el funcionamiento en general<br /> <br /> ===Prioridad y estado de incidencias===<br /> <br /> A continuación, tenemos el asunto de las prioridades. Hay tres etiquetas de alta, media y baja prioridad. La actual es de alta prioridad.<br /> 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.<br /> Por último, el estado de la incidencia se marca con solo dos etiquetas:<br /> -started: indica que se ha tenido en cuenta la incidencia y se está trabajando para resolverla<br /> -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.<br /> Si es así, se puede cerrar la incidencia.<br /> En caso contrario, se debe volver a marcar la etiqueta started.<br /> 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.<br /> <br /> == Integración continua ==<br /> 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:<br /> <br /> * 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.<br /> https://jenkins.egc.duckdns.org/<br /> <br /> * 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.<br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> * 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.<br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> 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`.<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4951 2016-11-30T10:37:37Z

<p>Anddonram: /* Gestión de incidencias */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> == Integración continua ==<br /> Se cuenta con integración continua en la página:<br /> <br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> <br /> La integración continua del sistema en la rama dev está en el siguiente enlace:<br /> <br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4950 2016-11-30T10:34:32Z

<p>Anddonram: /* Gestión de código */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada por al menos dos desarrolladores en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> 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.<br /> <br /> Cuando una incidencia está resuelta, se debe indicar en el issue correspondiente, con el commit<br /> <br /> == Integración continua ==<br /> Se cuenta con integración continua en la página:<br /> <br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> <br /> La integración continua del sistema en la rama dev está en el siguiente enlace:<br /> <br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4949 2016-11-30T10:32:51Z

<p>Anddonram: /* Gestión de incidencias */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> 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.<br /> <br /> Cuando una incidencia está resuelta, se debe indicar en el issue correspondiente, con el commit<br /> <br /> == Integración continua ==<br /> Se cuenta con integración continua en la página:<br /> <br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> <br /> La integración continua del sistema en la rama dev está en el siguiente enlace:<br /> <br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4948 2016-11-30T10:03:20Z

<p>Anddonram: /* Integración continua */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Integración continua ==<br /> Se cuenta con integración continua en la página:<br /> <br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> <br /> La integración continua del sistema en la rama dev está en el siguiente enlace:<br /> <br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4947 2016-11-30T10:03:11Z

<p>Anddonram: /* Integración continua */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Integración continua ==<br /> Se cuenta con integración continua en la página:<br /> <br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> <br /> La integración continua del sistema en la rama dev está en el siguiente enlace:<br /> https://beta.frontend.agoraus1.egc.duckdns.org/<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4946 2016-11-30T09:12:08Z

<p>Anddonram: /* Gestión de código */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> 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 &quot;c&quot; (de candidate) tras la versión.<br /> <br /> Solo cuando la funcionalidad de una versión candidata esté probada en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;r&quot; (de release).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Integración continua ==<br /> Se cuenta con integración continua en la página:<br /> <br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4945 2016-11-30T09:09:07Z

<p>Anddonram: /* Integración continua */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> Solo cuando la funcionalidad este probada en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;candidata&quot; o &quot;release&quot; (por definir uso de etiquetas).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Integración continua ==<br /> Se cuenta con integración continua en la página:<br /> <br /> https://frontend.agoraus1.egc.duckdns.org/<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4944 2016-11-30T09:08:06Z

<p>Anddonram: /* Integración continua */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> Solo cuando la funcionalidad este probada en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;candidata&quot; o &quot;release&quot; (por definir uso de etiquetas).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Integración continua ==<br /> Se cuenta con integración continua en la página <br /> [https://frontend.agoraus1.egc.duckdns.org/]<br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4769 2016-11-08T17:33:57Z

<p>Anddonram: /* Gestión de código */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama<br /> <br /> Solo cuando la funcionalidad este probada en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;candidata&quot; o &quot;release&quot; (por definir uso de etiquetas).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Integración continua ==<br /> <br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4768 2016-11-08T17:33:39Z

<p>Anddonram: /* Gestión de código */</p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;. Los cambios en local se harán en una copia de esta rama \n<br /> Solo cuando la funcionalidad este probada en &quot;dev&quot; se juntará con la rama &quot;master&quot;, marcando esa versión como &quot;candidata&quot; o &quot;release&quot; (por definir uso de etiquetas).<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Integración continua ==<br /> <br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4767 2016-11-08T17:30:39Z

<p>Anddonram: </p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de código==<br /> Se trabajará en una rama &quot;dev&quot;.<br /> Solo cuando la funcionalidad este probada se juntará con la rama &quot;master&quot;.<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Integración continua ==<br /> <br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4766 2016-11-08T17:29:09Z

<p>Anddonram: </p> <hr /> <div>= Aspectos organizativos =<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Integración continua ==<br /> <br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4765 2016-11-08T17:28:37Z

<p>Anddonram: /* Gestión de incidencias */</p> <hr /> <div>= Aspectos organizativos =<br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Integración continua ==<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> <br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4764 2016-11-08T17:28:14Z

<p>Anddonram: /* Aspectos organizativos */</p> <hr /> <div>= Aspectos organizativos =<br /> == Gestión de incidencias ==<br /> Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> <br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4763 2016-11-08T17:27:55Z

<p>Anddonram: /* Aspectos organizativos */</p> <hr /> <div>= Aspectos organizativos =<br /> Gestión de incidencias: Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> <br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4762 2016-11-08T17:27:43Z

<p>Anddonram: /* Aspectos organizativos */</p> <hr /> <div>= Aspectos organizativos =<br /> *Gestión de incidencias: Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> *Descripción<br /> *Pasos a ejecutar<br /> *Resultado esperado<br /> *Resultado obtenido<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> <br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Frontend_y_visualizaci%C3%B3n_de_resultados_1617&diff=4761 2016-11-08T17:27:18Z

<p>Anddonram: Página creada con «= Aspectos organizativos = Gestión de incidencias: Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo: Descripci...»</p> <hr /> <div>= Aspectos organizativos =<br /> Gestión de incidencias: Se usarán las Issues de Github, donde se describirá el problema con la mayor exactitud posible, incluyendo:<br /> Descripción<br /> Pasos a ejecutar<br /> Resultado esperado<br /> Resultado obtenido<br /> <br /> == Miembros ==<br /> * '''José Renato Ramos González:''' Project Manager<br /> * '''José Gavilán Ruiz:''' Software Developer<br /> * '''Eva Menendez Montes:''' Software Developer<br /> * '''Andrés Miguel Jiménez Ríos''': Software Developer<br /> * '''Andrés Doncel Ramírez:''' Software Developer<br /> <br /> == Actas ==<br /> <br /> <br /> <br /> == Repositorio de código ==<br /> https://github.com/AgoraUS-G1-1617/Frontend<br /> <br /> <br /> == Subsistemas relacionados ==</div>

Anddonram https://1984.lsi.us.es/wiki-egc/index.php?title=Espacios_para_el_grupo_1&diff=4760 2016-11-08T17:20:17Z

<p>Anddonram: </p> <hr /> <div>* [[Creación_Administración_Votaciones_1617 | Creación y administración de votaciones]]<br /> * [[Frontend y visualización de resultados 1617]]</div>

Anddonram