Cabina de votaciones - 17 18 - G1

Miembros

• Dominguez Mena, Francisco José (coordinador)
• Chen, Na
• Gómez Campanario, Julio
• Gomez Angulo, Manuel Antonio
• Luna Monchul, Jesús Fernando

Objetivos

El objetivo de nuestro subsistema será la visualización de una votación por parte de un usuario autorizado para finalmente, tras responder, mandar su voto al subsistema de almacenamiento de votos mediante su API, con lo que será finalmente cifrado.

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.

Opera

Nuestro proyecto puede encontrarse en el siguiente enlace

Entorno de trabajo

• Lenguaje de desarrollo: python2.7
• Base de datos: MariaDB 10.0.31
• Framework: Django==1.4.7, djangorestframework==2.4.3, django-cors-headers==0.13, requests==2.4.3
• IDE: Eclipse Neon 4.3 con PyDev

Además, nuestro sistema contará con dos bases de datos en un docker de MariaDB, la primera, votaciones, con las tablas comunes a todos los subsistemas, y una segunda llamada cabina que contiene las tablas necesarias para el despliegue de un proyecto django.

Acceso a la informacióm

Accediendo a la base de datos mediante la Id de una votación, obtendremos sus datos y, una vez completado el voto, mediante la API del subsistema de almacenamiento de votos, se guardará.

- Envío del voto mediante método POST:

• Apartado en construcción hasta recibir la información del subsistema de almacenamiento de votos*

Usage Model

Gestion de Issues

Lo issues asignados a nuestro proyecto pueden encontrarse en: Issues

Procedimiento

Cada miembro será encargado de crear el issue correspondiente a su trabajo y los referentes a problemas en los que estén trabajando.Si se tuviese que escribir un issue referente a otro subsistema, será el coordinador el encargado de hacerlo.Además, cada miembro del equipo es encargado de la evolución de sus issues.

Proyectos

Los issues serán divididos en proyectos según su area: Funcionalidades, Incidencias, Base de Datos y Documentación, y tendrán las siguientes fases:

• To Do
• En progreso
• En espera/Con Problemas
• En revisión
• Hecho

Además, cada vez que un issue cambie de estado, este será reportado mediante un comentario en la descripción del issue. En caso de que pase a ser hecho, la descripción cerrará a su vez el issue.

Estructura

• Title: Pequeña descripción del problema o tarea. Si afecta a una clase en concreto, se incluirá su nombre.
• Comment: Se incluirá una descripción con el nivel de detalle suficiente para saber cómo surgió ese problema y así saber arreglarlo.
• Assignees: Persona asignada al issue (puede ser el creador u otro miembro del equipo al que este relacionado con el issue).
• Labels: Se contará con las siguientes etiquetas:
  • Temática: Base de datos, Documentación, Incidencia o Funcionalidad.
  • Prioridad: Critical, High, Medium, Low.
  • Estados: New, Accepted, Started, Fixed, Verified, Duplicate y Wontfix
  • Tipo: Bug y Mejora, si los hubiese.
  • Asignado a: assigned, unassigned.
• Millestone: Millestone 1, Millestone 2,.. etc.

Además, durante el proceso del issue las etiquetas deben ir cambiando según su estado.

Gestion de Ramas y Commits

• Antes cualquier duda a la hora de crear ramas, tendrá que comunicarse primero al coordinador del grupo.
• Habrá issues basados en la rama Development e issues en ramas features. Depende de su origen, se hará merge con una de ellas. Se explica en el apartado Merge.
• Solamente se hará commit a un código que haya supuesto una mejora respecto al último. No se hará commit de contenido que no aporte o no solucione ningún problema, por lo que todo commit estará relacionado con un issue del repositorio.

Ramas

Las ramas relacionadas con issues serán borradas tras hacer merge con development. Las ramas relacionadas con features no serán borradas.

• Master: Rama principal en la que solo se subirá contenido cuando se tenga una versión del software funcional. Serán las instantáneas del proyecto. Se versionarán mediante 1.0, 1.1.2, etc.
• Release: rama previa a la liberación del software.
• Development: Esta rama representará la evolución del proyecto. Sobre ella se crearán las copias, y será la antesala de la rama master. Una vez liberado el software de la rama Development, se hará merge con release.
• Features: Esta rama representa las nuevas funcionalidades que queremos añadir al sistema. Una vez terminada, harán merge con Development. En nuestro caso, contaremos con las siguientes ramas:
  • Internacionalizacion: Rama que contendrá la funcionalidad de la internacionalización de la web.
  • Previsualización: Rama que contendrá la funcionalidad de la vista de previsualización antes de enviar un voto.
  • Graficos: Rama que contendrá la funcionalidad de las mejoras gráficas con respecto al sistema heredado: responsive, nuevo header, etc.
• Issue_X: Rama que representa cualquier tarea no contemplada en la planificación inicial o problema que haya surgido. Se representará mediante el código del issue correspondiente. Una vez resuelto, se hará merge con Development.

Estructura del commit

• Primera línea: Línea resumen de lo que se ha hecho (no más de 70 caracteres):
  • Incidencia: arreglo de un bug o reestructuración de código.
  • Funcionalidad: Nueva funcionalidad.
  • Test: arreglos relacionados en los test.

Si el cambio es global se pasa al siguiente punto. En caso de que no, entre paréntesis se incluye la clase afectada. E.g: Fix (settings.py)

• Línea en blanco
• Mensaje: Descripción de la funcionalidad o fallo que se ha arreglado en contraste con el comportamiento que tenía anteriormente. No se usará los verbos en primera persona (“he cambiado el header y arreglado los test”, por ejemplo). Se usará del modo “Cambio de header y arreglo de test”.
• Línea en blanco
• Pie:
  • Closes #X (siendo X un issue). Si fuesen varios, closes #X, #Y

Merge

• Se harán mediante pull request que supervisará otro miembro del equipo.
• La descripción del pull request será lo más detallada posible indicando los cambios que haya realizado respecto a la rama con la que quiera hacer merge.
• Las ramas de features o issues harán merge, una vez hayan cerrado el issue, con la rama Development.
• Si el issue está relacionado con una feature, se hará merge con su rama feature correspondiente y posteriormente con Development.

Una vez la rama Development esté lista para ser liberada, se hará merge con la rama release.

• Release representa un pre-release anterior al master. Si una vez comprobado en la rama release todo funciona correctamente, se hará merge con la rama master y se crearán las release notes de dicha versión.
• Si la rama Development presentase algún problema, se crearía una nueva rama con su issue correspondiente y, una vez solucionado, volvería a hacerse merge con Development.
• Una vez hecho merge, se eliminará la rama si se corresponde con un issie. Las demás no serán borradas.

Pull Request

• Su etiqueta será unreviewed a la hora de su creación.
• Una vez revisado, el revisor modificará la etiqueta a reviewed y aceptará el pull request.
• El creador podrá hacer merge a las ramas correspondientes.
• En caso de necesitar arreglo de conflictos, lo realizará el creador del pull request mediante github y en caso de pasar el número de documentos, se hará en local y luego subido a la rama correspondiente.