Diferencia entre revisiones de «Espacio en común y cabina(Curso 2015-2016)»
(→Gestión de incidencias externas) |
|||
Línea 16: | Línea 16: | ||
* Ofrecemos el [https://github.com/jorgeron/CensoEGC/issues/4#issuecomment-160288089 siguiente protocolo] para las incidencias que nos lleguen de otros subsistemas | * Ofrecemos el [https://github.com/jorgeron/CensoEGC/issues/4#issuecomment-160288089 siguiente protocolo] para las incidencias que nos lleguen de otros subsistemas | ||
+ | '''Creación y Administración de votaciones:''' | ||
+ | * Para la comunicación con otros subsistemas ofrecemos un protocolo de comunicación que se especifica en nuestra [https://1984.lsi.us.es/wiki-egc/index.php/Creaci%C3%B3n_y_administraci%C3%B3n_de_votaciones_Grupo_2_(Curso_2015-2016) sección]. | ||
=== Gestión del código === | === Gestión del código === |
Revisión del 18:53 11 dic 2015
Contenido
Definición
Espacio en común para los coordinadores de los subsistemas de AgoraUS, en el cual se recogerá tanto la información de las distintas reuniones de los coodinadores, así como información del subsistema cabina, el cual va a ser administrado por todos los coordinadores de AgoraUS
Datos de Organización
Gestión de incidencias externas
Cada grupo indicará en este apartado cómo se le reportan las incidencias externas.
Recuento:
- Para facilitar la comuniación con otros subsistemas se ofrece este enlace
Verificación:
- Se ofrece una plantilla de una incidencia reportada por otros subsistemas aquí
Censos:
- Ofrecemos el siguiente protocolo para las incidencias que nos lleguen de otros subsistemas
Creación y Administración de votaciones:
- Para la comunicación con otros subsistemas ofrecemos un protocolo de comunicación que se especifica en nuestra sección.
Gestión del código
Se dispondrá de un repositorio en Github común. El repositorio almacenará todos los subsistemas de AgoraUs para que posteriormente la cuenta pase a ser administrada por el profesor. De esta forma no se perderá la información.
El proceso para administrar el repositorio es el siguiente:
- El repositorio en común tendra una rama por cada subsistema.
- Cada subsistema tiene un repositorio propio. En cuanto tengan un release, esa versión se almacenara en el repositorio en común en la rama de su subsistema
- Cuando la rama de su subsistema en el repositorio este estable, se realizará un branch a la rama master.
- La rama master estará protegida por un administrador, el cual aceptara o denegara los pull request
Gestión de la integración continua
Debido a que tenemos un repositorio en común, se evaluará desplegar un jenkins el cual compilará todos los cambios en la rama master del repositorio