Diferencia entre revisiones de «Verificación - G1 - 1617»
(→Repositorio de código) |
|||
| (No se muestra una edición intermedia del mismo usuario) | |||
| Línea 18: | Línea 18: | ||
== Proyecto en Opera == | == Proyecto en Opera == | ||
[http://opera.eii.us.es/egc/public/trabajo/ver/id/46 Verificación en Opera] | [http://opera.eii.us.es/egc/public/trabajo/ver/id/46 Verificación en Opera] | ||
| + | |||
| + | == Gestión del código == | ||
| + | Dentro de la gestión de Github, hemos creado dos ramas: | ||
| + | |||
| + | *Rama 'developer': | ||
| + | |||
| + | En la rama developer subiremos todos los cambios que vayamos realizando en el proyecto. Dichos cambios no deben producir errores en el proyecto. | ||
| + | |||
| + | *Rama 'master': | ||
| + | |||
| + | La rama master solo podrá ser usada por el Jefe del proyecto. El Jefe del proyecto deberá revisar todos los cambios subidos y si considera que están bien, deberá hacer un merge de la rama developer a la master. | ||
| + | |||
| + | == Gestión de incidencias== | ||
| + | Para la gestión de incidencias usaremos la pestaña issues que encontramos en Github. Todos los participantes podrán crear issues, pero el Jefe del Proyecto debe darle el visto bueno. Cada issue debe tener: | ||
| + | |||
| + | *Título: debe dar información general sobre lo que vamos a realizar. | ||
| + | |||
| + | *Descripción: detallar la issue, cual es el problema y como vamos a solucionarlo. | ||
| + | |||
| + | *Asignación: todas las issues deben tener alguna persona asignada para que solucione el error encontrado. | ||
| + | |||
| + | *Tag: En nuestro caso usaremos dos posibles etiquetas(Bug , Enhancement). Bug será utilizado para errores encontrados en el código y Enhancement para una posible mejora que podemos realizar. | ||
Revisión actual del 21:07 10 ene 2017
Contenido
Aspectos organizativos
Miembros
- Hernán González Peñalver: Project Manager
- Álvar Sánchez López: Software Developer
- Alejandro Sanabria Cruz: Software Developer
- Manuel de la Fuente Carmona: Software Developer
- Lidia Sanchez Vaz: Software Developer
Repositorio de código
Para gestionar nuestro subsistema usaremos Github. Estará dentro de la organización AgoraUS-G1-1617. Puede acceder desde el siguiente enlace.
Sitio de despliegue del subsistema
Este subsistema no está diseñado para despliegue web, sino para despliegue en forma de librería .jar consumida por otros subsistemas.
Proyecto en Opera
Gestión del código
Dentro de la gestión de Github, hemos creado dos ramas:
- Rama 'developer':
En la rama developer subiremos todos los cambios que vayamos realizando en el proyecto. Dichos cambios no deben producir errores en el proyecto.
- Rama 'master':
La rama master solo podrá ser usada por el Jefe del proyecto. El Jefe del proyecto deberá revisar todos los cambios subidos y si considera que están bien, deberá hacer un merge de la rama developer a la master.
Gestión de incidencias
Para la gestión de incidencias usaremos la pestaña issues que encontramos en Github. Todos los participantes podrán crear issues, pero el Jefe del Proyecto debe darle el visto bueno. Cada issue debe tener:
- Título: debe dar información general sobre lo que vamos a realizar.
- Descripción: detallar la issue, cual es el problema y como vamos a solucionarlo.
- Asignación: todas las issues deben tener alguna persona asignada para que solucione el error encontrado.
- Tag: En nuestro caso usaremos dos posibles etiquetas(Bug , Enhancement). Bug será utilizado para errores encontrados en el código y Enhancement para una posible mejora que podemos realizar.
