Diferencia entre revisiones de «Cabina de votación 1617 G1»

De Wiki de EGC
Saltar a: navegación, buscar
 
(No se muestra una edición intermedia del mismo usuario)
Línea 32: Línea 32:
 
El trabajo se organiza en diferentes ramas:
 
El trabajo se organiza en diferentes ramas:
  
−
* master: En esta rama se incluye únicamente trabajo finalizado y comprobado por todos los miembros del equipo. Una vez se hace commit&push desde esta rama, quedará subido a la versión estable del sistema global.
+
* '''master''': En esta rama se incluye únicamente trabajo finalizado y comprobado por todos los miembros del equipo. Una vez se hace commit&push desde esta rama, quedará subido a la versión estable del sistema global.
  
−
* development: Esta rama contiene el trabajo en fase beta. Haciendo las veces de rama unificadora, en development se incluye todo el trabajo realizado, pero no comprobado por todos los integrantes del grupo. Una vez se hace commit&push desde esta rama, quedará subido a la versión beta del sistema global. Esta es la rama sobre la que se deben hacer todos los merge para comprobar el correcto funcionamiento de la integración local.
+
* '''development''': Esta rama contiene el trabajo en fase beta. Haciendo las veces de rama unificadora, en development se incluye todo el trabajo realizado, pero no comprobado por todos los integrantes del grupo. Una vez se hace commit&push desde esta rama, quedará subido a la versión beta del sistema global. Esta es la rama sobre la que se deben hacer todos los merge para comprobar el correcto funcionamiento de la integración local.
  
−
* Issue#X_Y: Son ramas creadas para el trabajo diario del proyecto. Cada rama queda asociada a una issue concreta, siendo esta rama aquella en la que se añadan y arreglen las funcionalidades definidas por la issue. Para facilitar la legibilidad, el formato a seguir es Issue#X_Y dónde X es un número (identificador numérico) e Y una más que breve descripción de la issue. Una vez el encargado de dicha issue considera que ha finalizado el trabajo asociado a esta rama, se encarga de incluirla en la rama 'development' para que el resto de integrantes confirmen el correcto funcionamiento y posteriormente se pase a 'master'.
+
* '''Issue#X_Y''': Son ramas creadas para el trabajo diario del proyecto. Cada rama queda asociada a una issue concreta, siendo esta rama aquella en la que se añadan y arreglen las funcionalidades definidas por la issue. Para facilitar la legibilidad, el formato a seguir es Issue#X_Y dónde X es un número (identificador numérico) e Y una más que breve descripción de la issue. Una vez el encargado de dicha issue considera que ha finalizado el trabajo asociado a esta rama, se encarga de incluirla en la rama 'development' para que el resto de integrantes confirmen el correcto funcionamiento y posteriormente se pase a 'master'.
  
 +
La creación de cada rama '''Issue#X_Y''' debe hacerse a partir de la última versión de la rama '''development''' del proyecto.
  
 
* Enlace a GitHub: https://github.com/AgoraUS-G1-1617/Cabina-de-votaciones
 
* Enlace a GitHub: https://github.com/AgoraUS-G1-1617/Cabina-de-votaciones
  
 
=== Gestión de incidencias ===
 
=== Gestión de incidencias ===
 +
 +
La gestión de incidencias se realiza mediante la propia plataforma '''GitHub''', apartado de Issues.
 +
Para cada incidencia, corrección o ampliación de funcionalidades, se crea una nueva issue dónde se especifican las particularidades del trabajo a realizar. Al miembro del equipo que le corresponda (bien por decisión del grupo o por iniciativa propia), se autoasigna dicha issue, siendo a partir de ese momento el responsable principal de la tarea.
 +
 +
Para facilitar la legibilidad de las '''Issues''' se hacen uso de diferentes etiquetas, que clasifican las issues según '''tipo''' y '''estado'''
 +
 +
* '''Tipo''': Las etiquetas utilizadas son '''enhancement''' y '''bug''', para denotar si una issue es para realizar una ampliación de las funcionalidades y solventar algún problema/error.
 +
* '''Estado''': Las principales etiquetas empleadas son '''on development''' y '''closed'''
 +
 
* Enlace a GitHub (Issues): https://github.com/AgoraUS-G1-1617/Cabina-de-votaciones/issues
 
* Enlace a GitHub (Issues): https://github.com/AgoraUS-G1-1617/Cabina-de-votaciones/issues
  

Revisión actual del 16:02 20 dic 2016

Información sobre el grupo

Miembros

  • Francisco González Valle: Jefe de proyecto
  • Álvaro García Sierra: Desarrollador
  • Juan Luis Lopez Franco : Desarrollador
  • José María Jiménez Jiménez: Desarrollador
  • Juan Carlos Liébana Fernández: Desarrollador


Información sobre el proyecto

Ecosistema

El equipo de trabajo decidió al comienzo del proyecto hacer uso de una máquina virtual basada en Xubuntu 16.04, común a todos los miembros del grupo para llevar a cabo el trabajo derivado del mismo. Dadas las características del proyecto, las tecnologías y herramientas empleadas son las siguientes:

  • Python 2.7
  • Maven
  • PyCharm Professional / SublimeText 3
  • Git

Dadas las condiciones previas al comienzo de nuestra intervención, es decir, las condiciones en las que se encontraba el proyecto del curso académico anterior (2015/16), se decidió retomar el trabajo del curso académico 2014/15.

GitHub

Gestión de código

El gestión del código se lleva a cabo mediante el software de control de versiones Git. El trabajo se organiza en diferentes ramas:

  • master: En esta rama se incluye únicamente trabajo finalizado y comprobado por todos los miembros del equipo. Una vez se hace commit&push desde esta rama, quedará subido a la versión estable del sistema global.
  • development: Esta rama contiene el trabajo en fase beta. Haciendo las veces de rama unificadora, en development se incluye todo el trabajo realizado, pero no comprobado por todos los integrantes del grupo. Una vez se hace commit&push desde esta rama, quedará subido a la versión beta del sistema global. Esta es la rama sobre la que se deben hacer todos los merge para comprobar el correcto funcionamiento de la integración local.
  • Issue#X_Y: Son ramas creadas para el trabajo diario del proyecto. Cada rama queda asociada a una issue concreta, siendo esta rama aquella en la que se añadan y arreglen las funcionalidades definidas por la issue. Para facilitar la legibilidad, el formato a seguir es Issue#X_Y dónde X es un número (identificador numérico) e Y una más que breve descripción de la issue. Una vez el encargado de dicha issue considera que ha finalizado el trabajo asociado a esta rama, se encarga de incluirla en la rama 'development' para que el resto de integrantes confirmen el correcto funcionamiento y posteriormente se pase a 'master'.

La creación de cada rama Issue#X_Y debe hacerse a partir de la última versión de la rama development del proyecto.

Gestión de incidencias

La gestión de incidencias se realiza mediante la propia plataforma GitHub, apartado de Issues. Para cada incidencia, corrección o ampliación de funcionalidades, se crea una nueva issue dónde se especifican las particularidades del trabajo a realizar. Al miembro del equipo que le corresponda (bien por decisión del grupo o por iniciativa propia), se autoasigna dicha issue, siendo a partir de ese momento el responsable principal de la tarea.

Para facilitar la legibilidad de las Issues se hacen uso de diferentes etiquetas, que clasifican las issues según tipo y estado

  • Tipo: Las etiquetas utilizadas son enhancement y bug, para denotar si una issue es para realizar una ampliación de las funcionalidades y solventar algún problema/error.
  • Estado: Las principales etiquetas empleadas son on development y closed

Despliegue

Opera

Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Cabina_de_votación_1617_G1&oldid=5256»