Diferencia entre revisiones de «Cabina de votaciones - 17 18»
(→Commits: Mejorado el estilo) |
(→Ramas: Mejorado el estilo) |
||
| Línea 29: | Línea 29: | ||
== Ramas == | == Ramas == | ||
La gestión de ramas será la siguiente: | 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 | + | - master: Contendrá una versión funcionando y con las funcionalidades confirmadas por el equipo de integración. Se considera usable para producción. <br/> |
| − | - 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. | + | - 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.<br/> |
| − | - <funcionalidad>: Esta rama contendrá una versión master del código y desarrollará una funcionalidad para la próxima versión del programa. | + | - <funcionalidad>: Esta rama contendrá una versión master del código y desarrollará una funcionalidad para la próxima versión del programa. <br/> |
| − | - <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). | + | - <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).<br/> |
El funcionamiento para pasar de una rama a otra será el siguiente. | 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. | + | - miembro a funcionalidad: Los miembros que tengan asignada la funcionalidad podrán modificar y realizar merge de la rama personal a la funcionalidad.<br/> |
| − | - 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). | + | - 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).<br/> |
| − | - 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. | + | - 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.<br/> |
Revisión del 20:32 27 nov 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 (
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.
