Diferencia entre revisiones de «Grupo de Visualización de resultados(2014-15) - Iteracion 6»
(→Resultados) |
(→Resultados) |
||
| Línea 9: | Línea 9: | ||
== Resultados == | == Resultados == | ||
Actualmente todo el código de nuestro sistema se encuentra en master dentro del repositorio y no existen ramas, en este repositorio solo se ha hecho un commit inicial, dado que el código ha sido traspasado del sistema anterior al nuevo proyecto de redmine en nuestro servidor propio. | Actualmente todo el código de nuestro sistema se encuentra en master dentro del repositorio y no existen ramas, en este repositorio solo se ha hecho un commit inicial, dado que el código ha sido traspasado del sistema anterior al nuevo proyecto de redmine en nuestro servidor propio. | ||
| + | |||
| + | |||
| + | == Gestión de código (Memoria de proyecto) == | ||
| + | |||
| + | Lo primero a decidir para gestionar correctamente el código es elegir la herramienta de gestión de código a utilizar. Para ello estudiamos los pros y contras de tres herramientas: Github, Redmine y Jira. Finalmente salió como elegida Redmine, ante la posibilidad de instalarlo en un servidor privado. | ||
| + | En cuanto a la gestión de ramas, al principio trabajamos sobre una sola rama dividiendo el trabajo en tres carpetas. Una para el HTML + CSS, una para la creación de estadísticas y otra para la obtención de datos internos. Viendo que esta no fue una buena prácticas, se decidió seguir el siguiente modelo de gestión. | ||
| + | |||
| + | AQUÍ VA LA IMAGEN!! | ||
| + | |||
| + | Por lo tanto, tendremos una rama Master donde tendremos las versiones estables de nuestro sistema. Estas versiones serán funcionales. Por otro lado, tendremos una rama de desarrollo, la cual se unirá al Master cuando demos por finalizada una versión, y una rama por cada característica nueva que se le quiera añadir al sistema. | ||
| + | Externamente, a nivel del proyecto de Agora@us se está trabajando en ramas diferentes. Nosotros tendríamos la opción principalmente de trabajar en la misma rama que el Frontend de Resultado, pero no se ha hecho así por no tener los objetivos claros desde el principio del proyecto. Podríamos integrarnos ahora con este módulo pero hemos decidido no hacerlo debido al impacto que supone, ya que nuestro código se encuentra en una versión bastante avanzada y a que cada grupo está usando una tecnología diferente. | ||
| + | También hemos decidido que los Check out serán no reservados, debido a que en ocasiones se trabajará en paralelo y esto podría suponer un problema. | ||
| + | La aprobación de los cambios y la gestión de conflicto será realizada por el desarrollador que vaya a realizar el commit o el push. Si es necesario, para los conflictos se utilizará herramientas diff para determinar que parte del código será la definitiva. | ||
| + | Hemos establecido también, que a la hora de realizar un commit debemos de anotar en el apartado de comentario los cambios realizados sobre el código. | ||
| + | En cuanto a los roles, solo establecemos dos. Por una parte tendremos al Administrador que será Alejandro Ojeda, y por otro el grupo de los Usuarios, que será conformado por el resto de los integrantes del grupo. | ||
Revisión del 19:47 27 oct 2014
Asistentes
- Moustaid, Hicham
- Gómez Barrera, Rubén
- Rico Ruiz, Javier
- Velázquez Caballero, Daniel
- Sánchez Crespo, Juan Luis
Resultados
Actualmente todo el código de nuestro sistema se encuentra en master dentro del repositorio y no existen ramas, en este repositorio solo se ha hecho un commit inicial, dado que el código ha sido traspasado del sistema anterior al nuevo proyecto de redmine en nuestro servidor propio.
Gestión de código (Memoria de proyecto)
Lo primero a decidir para gestionar correctamente el código es elegir la herramienta de gestión de código a utilizar. Para ello estudiamos los pros y contras de tres herramientas: Github, Redmine y Jira. Finalmente salió como elegida Redmine, ante la posibilidad de instalarlo en un servidor privado. En cuanto a la gestión de ramas, al principio trabajamos sobre una sola rama dividiendo el trabajo en tres carpetas. Una para el HTML + CSS, una para la creación de estadísticas y otra para la obtención de datos internos. Viendo que esta no fue una buena prácticas, se decidió seguir el siguiente modelo de gestión.
AQUÍ VA LA IMAGEN!!
Por lo tanto, tendremos una rama Master donde tendremos las versiones estables de nuestro sistema. Estas versiones serán funcionales. Por otro lado, tendremos una rama de desarrollo, la cual se unirá al Master cuando demos por finalizada una versión, y una rama por cada característica nueva que se le quiera añadir al sistema. Externamente, a nivel del proyecto de Agora@us se está trabajando en ramas diferentes. Nosotros tendríamos la opción principalmente de trabajar en la misma rama que el Frontend de Resultado, pero no se ha hecho así por no tener los objetivos claros desde el principio del proyecto. Podríamos integrarnos ahora con este módulo pero hemos decidido no hacerlo debido al impacto que supone, ya que nuestro código se encuentra en una versión bastante avanzada y a que cada grupo está usando una tecnología diferente. También hemos decidido que los Check out serán no reservados, debido a que en ocasiones se trabajará en paralelo y esto podría suponer un problema. La aprobación de los cambios y la gestión de conflicto será realizada por el desarrollador que vaya a realizar el commit o el push. Si es necesario, para los conflictos se utilizará herramientas diff para determinar que parte del código será la definitiva. Hemos establecido también, que a la hora de realizar un commit debemos de anotar en el apartado de comentario los cambios realizados sobre el código. En cuanto a los roles, solo establecemos dos. Por una parte tendremos al Administrador que será Alejandro Ojeda, y por otro el grupo de los Usuarios, que será conformado por el resto de los integrantes del grupo.
