Diferencia entre revisiones de «Cabina de votaciones - 17 18»

Revisión del 17:57 5 dic 2017

Resumen del trabajo

Nuestro trabajo consistirá en realizar el apartado de cabina de votación que consiste en permitir mediante el uso de un conjunto de métodos la posibilidad de que los usuarios puedan votar anónimamente teniendo en cuenta las restricciones posibles que puedan existir.

Modelo de uso del repositorio

En esta sección se describirá cómo se gestionará el código fuente y otros productos resultados del trabajo realizado por el grupo.

Se dispone de dos repositorios, en uno de ellos se guardará la documentación del proyecto (https://github.com/EGC-G2-Trabajo-1718/egc-cabinas) y en el otro se pondrá el código del programa (https://github.com/EGC-G2-Trabajo-1718/cabina-de-votacion).

Commits

Los commits se realizarán cada día que se realice alguna tarea correspondiente con el proyecto y deben tener el siguiente formato:

 <razón>:<título>
 (<colaboradores>)
 <cuerpo>
 (IMPORTANTE
 <detalles importantes>)

Se describirán cada componente del formato ahora:
- razón: Consitirá en la causa de la subida del commit, que puede ser uno de los siguientes: fix (arreglo), add (funcionalidad añadida), doc (documentación de código o otros).
- título: Resumen, de menos de 20 palabras del commit.
- colaboradores: Miembros del grupo que han ayudado en la realización del trabajo.
- cuerpo: Explicación más en profundidad del contenido del commit.
- IMPORTANTE: Sección donde se describe un detalle importante.
- detalles importantes: Detalles a destacar para otros miembros del grupo.

Ramas

La gestión de ramas será la siguiente:
- master: Contendrá una versión funcionando y con las funcionalidades confirmadas por el equipo de integración. Se considera usable para producción.
- dev: Contendrá una versión en funcionamiento, pero puede contener problemas de código o conflictos con otras funcionalidades, necesitará un testeo en entorno de pre producción.
- <funcionalidad>: Esta rama contendrá una versión master del código y desarrollará una funcionalidad para la próxima versión del programa.
- <miembro>: Esta rama será personal para cada uno de los desarrolladores y no será modificada por otros miembros del grupo. Podrá contener código en cualquier estado (por ejemplo sin compilar correctamente).

El funcionamiento para pasar de una rama a otra será el siguiente. - miembro a funcionalidad: Los miembros que tengan asignada la funcionalidad podrán modificar y realizar merge de la rama personal a la funcionalidad.
- funcionalidad a dev: Para poder actualizar dev, se deberá realizar un pull request y se realizarán pruebas de que el funcionamiento de la funcionalidad es correcta).
- dev a master: Se realizará un nuevo pull request, donde se indicarán los cambios de una versión de master a otra. De nuevo pasará por un periodo de pruebas para asegurar que funciona de forma correcta.

Incidencias

Las incidencias realizadas a nuestro módulo deben seguir el siguiente formato:

 Título: (descripción breve del error, debe ser reconocible entre otros posibles errores, por lo que mencionar acción, resultado incorrecto...)
 Prioridad: (¿Es necesario tener la solución cuanto antes o es un pequeño detalle a arreglar?. Podrá tener los siguiente valores: Baja, Media, Alta)
 Descripción: (Descripción textual del error, un resumen del problema o mejora).
 (Si aplicable) Pasos para reproducir: (Lista de acciones que se debe realizar para que se produzca el error, cuanto más preciso mejor)