Iteración del taller de gestión de código III (Autenticación 2014-15)

Asistentes

Asistió	Miembro del grupo
✓	Daniel Ayala Hernández
✓	Daniel de los Reyes Leal
✓	Alejandro Sánchez Medina
✓	Juan Carlos Roldán Salvador
✓	Fidel Mazo Delgado

Resultado

Se han tomado en grupo las siguientes decisiones que determinan la manera en la que se llevará a cabo la gestión de ramas del grupo de manera independiente a los demás:

• Se crearán ramas según las funcionalidades que haya que implementar, creando una rama por cada nueva funcionalidad. No se ha escogido una división en ramas basada en la arquitectura debido al reducido tamaño del subsistema, que causa una arquitectura muy simple. Sin embargo, al división en funcionalidades plantea un problema: la repetición de trabajo. Por ejemplo: dos funcionalidades necesitan acceder a una lista de usuarios, por lo que los dos miembros encargados de implementar la funcionalidad realizan el mismo trabajo por duplicado. Para solucionar esto, se pretende crear una rama de cambios globales dedicada a cambios que puedan ser útiles para todos los miembros, de manera parecida a una rama de parches pero sin enfocarla a la resolución de fallos, sino al desarrollo. Esta rama se usará principalmente para métodos de acceso a la base de datos. También habrá una rama de parches que funcionará de la misma manera pero solo será usada para realizar cambios relacionados con la corrección de errores.
• Si en algún momento en una rama es de utilidad código perteneciente a otra rama, se hará un merge de esta última en la rama que puede utilizar el código (sin borrar ninguna de las dos). Si hay algún conflicto no relacionado con el código que se quiere pasar de una rama a otra, permanecerá siempre el código de la rama original. De esta manera, se pretende evitar la repetición de trabajo cuando es menos obvio la utilidad de este para todo el grupo, de manera que no se haya usado la branch de cambios globales. Para que esto sea posible, se requiere que los miembros del equipo puedan identificar trabajo que es posible que ya haya realizado otro miembro del grupo. Se actuará de igual manera cuando dos funcionalidades estén relacionadas y una necesite a parte de la otra.
• Se realizará un merge que incluya los cambios de una rama en la rama principal cuando se haya terminado la funcionalidad a la que está dedicada cada rama, cerrándose la rama dedicada a la funcionalidad. Con la exepción de la rama de cambios comunes, que nunca se cerrará, pero cuyos cambios se reflejarán siempre en las otras ramas.
• Todos los miembros del equipo tendrán derechos de escritura y lectura de todas las ramas. Teniendo en cuenta el tamaño reducido del equipo y el proyecto, se ha llegado a la conclusión de que administrar los permisos que correspondería a cada miembro sería poco útil (es poco probable que un miembro del equipo realice un cambio innecesario e inesperado en una rama que no le corresponde) y consumiría más tiempo que cualquier pequeño problema que pueda causar la falta de restricciones. Además, de esta manera, un miembro del grupo puede revisar y fácilmente corregir un error en una rama correspondiente a una funcionalidad asignada a otro miembro (siempre y cuando este error sea obvio y la corrección no pueda causar problemas). En general, se facilita la colaboración a la hora de desarrollar funcionalidades.
• Siempre que se haga un cambio considerable se hará commit al respositorio remoto central, para que todos los miembros del equipo dispongan lo antes posible del código actualizado.
• Siempre que se realice un parche sobre el código (una modificación que no añada nuevas funcionalidades), la descripción de esta será BUGFIX: seguido del bug que se pretende corregir, y la plataforma sobre la que se produzca dicho bug, en caso de que haya una concreta.

En lo referente a la gestión de ramas desde un punto de vista que englobe el sistema completo, debido a las limitaciones de tiempo no ha sido posible comentar con los grupos las distintas posibilidades. Sin embargo, se ha mencionado la posibilidad de usar un repositorio común en el que cada grupo trabaje con una parte correspondiente a su subsistema.

Actualización: A día 27/10/2014, se han realizado las actividades del taller correspondientes a la gestión del taller de comunicación entre grupos. Se propuso la posibilidad de usar un repositorio común en el que cada grupo usara una rama (que a su vez podría luego dividirse en más ramas). Cuando un grupo necesitara usar algo desarrollado por otro grupo, se trasladarían los cambios de la rama a la del grupo que necesita el otro sistema.