Diferencia entre revisiones de «Grupo de Frontend de Resultados(2014-15) - Iteración 5(2)»
| (No se muestran 12 ediciones intermedias de otro usuario) | |||
| Línea 4: | Línea 4: | ||
* [[Usuario:raqcumdia|Raquel María Cumplido Díaz]] | * [[Usuario:raqcumdia|Raquel María Cumplido Díaz]] | ||
* [[Usuario:josferbue|José Antonio Fernández Bueno]] | * [[Usuario:josferbue|José Antonio Fernández Bueno]] | ||
| − | |||
* [[Usuario:danferrom|Daniel Fernández Romero]] | * [[Usuario:danferrom|Daniel Fernández Romero]] | ||
| − | |||
* [[Usuario:alerodpal|Alejandro Rodríguez Palomar]] | * [[Usuario:alerodpal|Alejandro Rodríguez Palomar]] | ||
* [[Usuario:josocaalm|José Pablo Ocaña Almagro]] | * [[Usuario:josocaalm|José Pablo Ocaña Almagro]] | ||
| Línea 18: | Línea 16: | ||
=Entregable= | =Entregable= | ||
| + | |||
| + | ==Gestión de ''branches''== | ||
| + | |||
| + | En lo que se refiere a la gestión de ramas o ''branches'', se ha acordado mantener dos a lo largo del desarrollo del código fuente: | ||
| + | |||
| + | * La primera, dedicada al desarrollo de la API REST. | ||
| + | * La segunda, en la que se desarrollará lo relativo a la base de datos donde serán almacenados los resultados de las votaciones. | ||
| + | |||
| + | Opcionalmente, se añadirá una tercera rama en caso de que se necesiten hacer pruebas en el código. | ||
| + | |||
| + | Veamos ahora los criterios que se han seguido y/o se seguirán para llevar a cabo la creación, unión y eliminación de ''branches'': | ||
| + | |||
| + | * Creación: se realizará al empezar el desarrollo (excepto la de pruebas), para desacoplar el código y evitar errores de concurrencia. | ||
| + | * Unión (''merge''): tendrá lugar al finalizar el desarrollo para llevar a cabo las pruebas de integración y comprobar que todo funciona correctamente. También podrá ocurrir en el caso de que una rama de prueba quiera ser incorporada a una de las dos principales. | ||
| + | * Eliminación: no se plantea para las ramas principales (API, DB). Únicamente tiene sentido en el caso de que una rama de pruebas no se considere válida. | ||
| + | |||
| + | ==Gestión del código fuente== | ||
| + | |||
| + | Al comienzo del desarrollo del subsistema, se usó '''SVN''' como herramienta de gestión del código fuente, ya que los miembros del equipo de desarrollo estaban familiarizados con ésta. No obstante, tras realizar la [[Grupo_de_Frontend_de_Resultados(2014-15)_-_Práctica_2|práctica 2]] y la [[Grupo_de_Frontend_de_Resultados(2014-15)_-_Práctica_3|práctica 3]], en las cuales se ha explicado el funcionamiento de '''GIT''', y la mejora que supone con respecto a '''SVN''', se ha decidido cambiar a esta herramienta. | ||
| + | |||
| + | ==Gestión del proyecto== | ||
| + | |||
| + | Como herramienta de gestión de proyectos, como ya se vio en la [[Grupo_de_Frontend_de_Resultados(2014-15)_-_Práctica_1|práctica 1]], tras analizar diferentes opciones, se eligió '''RedMine'''. Es necesario puntualizar que esta elección es a nivel local, es decir, que no involucra a los demás subsistemas. | ||
| + | |||
| + | Para la comunicación con los demás grupos de trabajo, en primer lugar desde el grupo se propone usar la herramienta '''Teamwork'''. No obstante, tras comunicárselo a los grupos relacionados éstos prefieren que la comunicación con ellos se realice usando su foro de la wiki. | ||
Revisión actual del 19:55 12 nov 2014
Contenido
Asistentes
- Manuel Cabrera Coronilla
- Raquel María Cumplido Díaz
- José Antonio Fernández Bueno
- Daniel Fernández Romero
- Alejandro Rodríguez Palomar
- José Pablo Ocaña Almagro
Resultados
- Se propusieron preguntas para el encuentro con los miembros de Agota Voting vía IRC.
- Se produjo una nueva iteración que dio lugar a una mejora del subsistema.
- Solución de problemas existentes al intentar utilizar la tecnología de despliegue acordada.
- Primera versión del plan de gestión de ramas a aplicar durante el desarrollo del subsistema (susceptible a cambios).
Entregable
Gestión de branches
En lo que se refiere a la gestión de ramas o branches, se ha acordado mantener dos a lo largo del desarrollo del código fuente:
- La primera, dedicada al desarrollo de la API REST.
- La segunda, en la que se desarrollará lo relativo a la base de datos donde serán almacenados los resultados de las votaciones.
Opcionalmente, se añadirá una tercera rama en caso de que se necesiten hacer pruebas en el código.
Veamos ahora los criterios que se han seguido y/o se seguirán para llevar a cabo la creación, unión y eliminación de branches:
- Creación: se realizará al empezar el desarrollo (excepto la de pruebas), para desacoplar el código y evitar errores de concurrencia.
- Unión (merge): tendrá lugar al finalizar el desarrollo para llevar a cabo las pruebas de integración y comprobar que todo funciona correctamente. También podrá ocurrir en el caso de que una rama de prueba quiera ser incorporada a una de las dos principales.
- Eliminación: no se plantea para las ramas principales (API, DB). Únicamente tiene sentido en el caso de que una rama de pruebas no se considere válida.
Gestión del código fuente
Al comienzo del desarrollo del subsistema, se usó SVN como herramienta de gestión del código fuente, ya que los miembros del equipo de desarrollo estaban familiarizados con ésta. No obstante, tras realizar la práctica 2 y la práctica 3, en las cuales se ha explicado el funcionamiento de GIT, y la mejora que supone con respecto a SVN, se ha decidido cambiar a esta herramienta.
Gestión del proyecto
Como herramienta de gestión de proyectos, como ya se vio en la práctica 1, tras analizar diferentes opciones, se eligió RedMine. Es necesario puntualizar que esta elección es a nivel local, es decir, que no involucra a los demás subsistemas.
Para la comunicación con los demás grupos de trabajo, en primer lugar desde el grupo se propone usar la herramienta Teamwork. No obstante, tras comunicárselo a los grupos relacionados éstos prefieren que la comunicación con ellos se realice usando su foro de la wiki.
