Taller de gestión de código (Parte III) (20/10/14)/(27/10/2014) - Grupo de Deliberaciones - 14/15
Contenido
Asistentes (20/10/2014)
- Julio Pineda Páez.
- Fco. Javier Reina Ponce.
- Salvador Herrera López.
- Edwin P. Arévalo Angulo.
- Daniel Toledo Villalba.
- Antonio León Carrillo.
- Raquel Cerrato Algaba.
- José María Caballero Alba.
Asistentes (27/10/2014)
- Rafael Rodriguez Osorio.
- Julio Pineda Páez.
- Fco. Javier Reina Ponce.
- Salvador Herrera López.
- Edwin P. Arévalo Angulo.
- Antonio León Carrillo.
- Raquel Cerrato Algaba.
- José María Caballero Alba.
Resultado (primera parte)
Describir la gestión de ramas del grupo y proyecto
En esta sección del taller que hemos realizado en esta iteración describimos la gestión de las ramas de nuestro proyecto: Para ello hemos realizado esta serie de capturas de pantalla para describir este proceso: Las operaciones realizadas serian hacer commit y hacer push como mostramos aquí:
Dotar al código de más funcionalidad
En el apartado en el que nos encontramos vamos a dotar a nuestro código de la funcionalidad necesaria como vemos a continuación: Creamos la rama documentos en nuestro repositorio git y nos situamos en ella.
Propuestas para la integración de sistemas
Aquí mostramos algunas propuestas para la integración de los sistemas. Añadimos el archivo que se vaya a necesitar. Subimos el archivo readme.md a nuestro repositorio de git.
Resultado (segunda parte)
Desarrollo del taller
En esta sesión, nos conformamos en grupos para discutir acerca de la primera versión de la gestión de ramas de nuestro proyecto para el entregable. Dos miembros del grupo se pusieron a trabajar sobre el código del proyecto que estamos desarrollando para perfilar ciertos aspectos del mismo, dotarlo de más funcionalidad y guardar los progresos en el repositorio.
El resto del grupo deliberó sobre las cuestiones que en el enunciado del taller se proponían. Se habló de cómo explicaremos los procesos, técnicas y herramientas involucrados en el código de nuestro proyecto. Al principio de las prácticas, la opción que se propuso para dicha gestión fue usar SVN, pero finalmente se decidió usar GIT debido a que es una herramienta más completa que SVN. Por tanto, la gestión de ramas y la aplicación de parches se hará mediante GIT. La decisión que se adoptó respecto a las ramas fue de crear tres: una principal, otra para documentación y otra para desarrollo.
También se trataron temas sobre el procedimiento a seguir para que los cambios fueran aprobados o descartados, así como será el patrón a seguir para el código fuente.
Respecto a la integración de todos los subsistemas se estuvo discutiendo durante unos minutos, pero no se llegó a nada en claro debido a la heterogeneidad de tecnologías utilizada por cada grupo para desarrollar sus subsistemas.
Al final del taller, le mostramos al profesor el progreso del trabajo hasta ese momento. El profesor nos recomendó usar con más frecuencia la herramienta de comunicación de GitHub, que fue la que elegimos para comunicarnos.
Preguntas para Agora Voting
- ¿Qué herramienta de control de versiones se utiliza en Agora Voting?