Diferencia entre revisiones de «Administración de votaciones - 17 18 - G1»

De Wiki de EGC
Saltar a: navegación, buscar
m (→‎Entorno de trabajo)
 
(No se muestran 12 ediciones intermedias del mismo usuario)
Línea 2: Línea 2:
  
 
<ul>
 
<ul>
−
<li>Domingo Muñoz Daza (coordinador)</li>
+
<li>Domingo Muñoz Daza </li>
 
<li>Ana Rosa Aparicio Ramos</li>
 
<li>Ana Rosa Aparicio Ramos</li>
 
<li>Elvira García Ruiz</li>
 
<li>Elvira García Ruiz</li>
 
<li>Javier Centeno Vega</li>
 
<li>Javier Centeno Vega</li>
−
<li>Jose Manuel Pallero Hidalgo</li>
+
<li>Jose Manuel Pallero Hidalgo (coordinador)</li>
 
</ul>
 
</ul>
  
−
== Repositorio de GitHub ==
+
== Uso de Git ==
  
 +
=== Repositorio de GitHub ===
 
El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/AdminVotaciones-EGC-G1 enlace]
 
El repositorio de GitHub del equipo será accesible en este [https://github.com/Proyecto-EGC-G1/AdminVotaciones-EGC-G1 enlace]
 
Cualquier decisión importante añadida a él o cambio que pueda implicar al resto de grupos se notificará a los coordinadores previamente.
 
Cualquier decisión importante añadida a él o cambio que pueda implicar al resto de grupos se notificará a los coordinadores previamente.
 +
 +
=== Creando Issues ===
 +
Todos los detalles y procedimientos para crear una issue han sido detallados en el siguiente [https://docs.google.com/document/d/1ttf5kepdCb4eDvz0qcZvQxQdUMmq3SXKN91aQX7DTAs/edit?usp=sharing documento]
 +
 +
=== Haciendo merge entre ramas ===
 +
Para conseguir un historial con una visión limpia y clara del trabajo, es importante que al hacer merge de ramas funcionales se impida hacer fast-forward, de manera que podamos ver cómo ha evolucionado cada rama aunque esta sea sencilla. Para ello, nos ponemos en la rama en la que queremos fusionar la funcionalidad (develop), y se ejecuta el siguiente comando:
 +
 +
'''git merge funcionalidad --no-ff'''
 +
 +
=== Otros comandos útiles ===
 +
Muestra el historial de ramas en un gráfico:
 +
 +
'''git log --graph --decorate --oneline'''
  
 
== Entorno de trabajo==
 
== Entorno de trabajo==
−
La máquina virtual de desarrollo (descarga [https://drive.google.com/file/d/1QcyMX2CTODWyq4KWQSWc259S-sidhe4f/view?usp=sharing aquí]) hace posible que cada equipo de desarrollo pueda trabajar de manera local sin depender del resto de subsistemas. El puerto asignado para este subsistema es el 52001. Esta configuración de puertos se mantiene en el entorno de despliegue. Para acceder a algún servicio la URL consiste en <nowiki>http://localhost:<puerto></nowiki>. Ej: <nowiki>http://localhost:52000</nowiki> para acceder a la autenticación.
+
Nuestro entorno de trabajo será variado, ya que desarrollamos tanto desde Linux, como Windows y Mac, debido a los terminales de los componentes del grupo. Todos usamos Eclipse con el plugin Pydev para el desarrollo en Python, así como eGit para el control de versiones con eclipse.
 +
 
 +
[https://docs.docker.com/compose/django/#define-the-project-components Guía para crear el contenedor docker con Django]
 +
 
 +
== Tecnologías y Procedimientos ==
  
−
== Formatos y procedimientos ==
+
=== Tecnologías elegidas ===
−
De carácter optativo hasta el 30/11/17 y obligatorio a partir de dicha fecha distinguimos el formateado de los siguientes elementos:
 
−
=== Formato para detallar tecnologías elegidas ===
 
 
  '''Subsistema''': Administración de Votaciones
 
  '''Subsistema''': Administración de Votaciones
−
  '''Lenguaje/Herramienta''': Java 7  
+
  '''Lenguaje/Herramienta''': Python 2.7  
−
  '''Sistema de gestión de bibliotecas''': Maven
+
  '''Sistema de gestión de bibliotecas''': Pip
−
  '''Bibliotecas''': <Listado de bibliotecas usadas en el desarrollo.>
+
  '''Bibliotecas''':
−
     '''Nombre_Biblioteca1''': <versión>
+
     '''python-mysql''': latest
−
  '''Necesita Base de datos''': <Sí/No> (En caso afirmativo explicar cuál se está empleando y su versión)
+
    '''django''': 1.5
 +
  '''Necesita Base de datos''': Sí, MariaDB 10.1
  
 
=== Procedimiento de gestión de tareas, cambios e incidendias ===
 
=== Procedimiento de gestión de tareas, cambios e incidendias ===
−
 
+
Todos los procedimientos que seguimos en nuestro equipo están detallados en este [https://docs.google.com/document/d/1tH52WndD-j7og2Sdn1qNRSUsofQrI_fuDGaMcGlaACM/edit?usp=sharing documento]
−
Para la gestión de las incidencias, se usarán los Issues que GitHub permite gestionar en cada repositorio. El uso de estos Issues está basado en las diapositivas de clase de ([http://1984.lsi.us.es/wiki-egc/index.php/Teor%C3%ADa_-_17/18 Gestión de Incidencias]), haciéndose de la siguiente manera:
 
−
*Cada grupo es responsable de la gestión de sus Issues.
 
−
*Cada Issue representará una tarea o problema encontrado por el grupo.
 
−
*Cada Issue será situado en un proyecto interno al repositorio, siendo actualizado entre las fases TO DO, En progreso, En espera/Con problemas, En revisión y Hecho según corresponda a su avance.
 
−
*Para cada avance o actualización de un Issue, se hará un comentario dentro de éste especificando el cambio hecho, indicando su motivo si procede.
 
−
*Una vez terminado un Issue se debe cerrar con un comentario de cierre y cerrándolo en sí mismo tras colocarlo en la columna Hecho se su proyecto correspondiente.
 
−
*Cada Issue será etiquetado en función de su temática, prioridad, estado y tipo. Los tipos son Cambio/Mejora y Bug, que sólo se incluirán en dichos casos. Las temáticas son libres para cada subgrupo. Las prioridades son Critical, High, Medium y Low, y los estados son New, Accepted (sólo para cambios), Started, Fixed, Verified, Duplicate (cambios y bugs) y Wontfix (cambios y bugs).
 
−
*Las etiquetas de cada Issue deben ser actualizadas durante el avance del mismo, con su correspondiente actualización en el proyecto y su comentario pertinente.
 

Revisión actual del 18:54 4 ene 2018

Miembros

  • Domingo Muñoz Daza
  • Ana Rosa Aparicio Ramos
  • Elvira García Ruiz
  • Javier Centeno Vega
  • Jose Manuel Pallero Hidalgo (coordinador)

Uso de Git

Repositorio de GitHub

El repositorio de GitHub del equipo será accesible en este enlace Cualquier decisión importante añadida a él o cambio que pueda implicar al resto de grupos se notificará a los coordinadores previamente.

Creando Issues

Todos los detalles y procedimientos para crear una issue han sido detallados en el siguiente documento

Haciendo merge entre ramas

Para conseguir un historial con una visión limpia y clara del trabajo, es importante que al hacer merge de ramas funcionales se impida hacer fast-forward, de manera que podamos ver cómo ha evolucionado cada rama aunque esta sea sencilla. Para ello, nos ponemos en la rama en la que queremos fusionar la funcionalidad (develop), y se ejecuta el siguiente comando: 

git merge funcionalidad --no-ff

Otros comandos útiles

Muestra el historial de ramas en un gráfico: 

git log --graph --decorate --oneline

Entorno de trabajo

Nuestro entorno de trabajo será variado, ya que desarrollamos tanto desde Linux, como Windows y Mac, debido a los terminales de los componentes del grupo. Todos usamos Eclipse con el plugin Pydev para el desarrollo en Python, así como eGit para el control de versiones con eclipse.

Guía para crear el contenedor docker con Django

Tecnologías y Procedimientos

Tecnologías elegidas

Subsistema: Administración de Votaciones
Lenguaje/Herramienta: Python 2.7 
Sistema de gestión de bibliotecas: Pip
Bibliotecas:
   python-mysql: latest
   django: 1.5
Necesita Base de datos: Sí, MariaDB 10.1

Procedimiento de gestión de tareas, cambios e incidendias

Todos los procedimientos que seguimos en nuestro equipo están detallados en este documento

Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Administración_de_votaciones_-_17_18_-_G1&oldid=7154»