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

De Wiki de EGC
Saltar a: navegación, buscar
(Gestión de código)
(Gestión de incidencias)
Línea 26: Línea 26:
 
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.
 
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, con el commit
+
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 ==
 
== Integración continua ==

Revisión del 11:37 30 nov 2016

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

Se cuenta con integración continua en la página:

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


La integración continua del sistema en la rama dev está en el siguiente enlace:

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

Repositorio de código

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


Subsistemas relacionados