Diferencia entre revisiones de «Frontend y visualización de resultados 1617»
(→Integración continua) |
(→Integración continua) |
||
| Línea 32: | Línea 32: | ||
* 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. | * 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. | * 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. | * 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`. | ||
== Repositorio de código == | == Repositorio de código == | ||
Revisión del 12:11 30 nov 2016
Contenido
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
Actas
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.
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 `mpn start`.
Repositorio de código
https://github.com/AgoraUS-G1-1617/Frontend
