Entorno de trabajo
En este apartado se describen las instrucciones a aplicar en el desarrollo del proyecto, y el flujo de trabajo de a seguir para incluir nuevas características.
El flujo de trabajo utilizado en el desarrollo del proyecto está basado en Gitflow. Este workflow nos permite un alto seguimiento de las características de nuestra aplicación, diferenciando el estado o fase en el que se encuentra cada una de ellas; y un muy buen control del versionado de las releases, permitiendo la inclusión de hotfixes para la resolución rápida de problemas en alguna release.
El funcionamiento de Gitflow es el siguiente:
- Se crea una rama de
developa partir demaster. - Las ramas de
releasese crean partir de una rama dedevelop. - Las ramas de
featuresse crean a partir de la rama dedevelop. - Cuando una
featurese completa se realiza unpull requesta rama dedevelop. - Cuando la rama de
releaseestá terminada se fusiona endevelopymaster. - Si se detecta un problema en
masterse crea una rama dehotfixdesde elmaster. - Una vez finalizada la revisión, se fusiona
hotfixendevelopymaster.
.svg)
El flujo de trabajo está basado en la utilización de dos ramas, que podríamos considerar como principales, master y develop, en lugar de una única de master.
La rama master almacena un historial de las releases publicadas, añadiendo una etiqueta por cada una de ellas. La rama develop almacena el historial completo de todos los cambios producidos en el proyecto, aquí se van incluyendo las nuevas features añadidas.
Las ramas de features contienen nuevas características a incluir en la aplicación. Las ramas de features, normalmente, se generan desde la última versión de la rama de develop, aunque, si fuese necesario, se podría generar desde una versión anterior de develop.
Cada feature está asociada a un issue abierto, luego cuando generamos una feature el nombre es feature-[id-issue].
git checkout develop
git checkout -b feature_branchUna vez finalizada la característica a implementar, se solicitará un pull request para que puede ser incluida en la rama develop.
Una vez que la rama develop ha incluido las características de la versión en curso, se crea una rama de release, a partir de develop. Al crear esta rama de release, se inicia el desarrollo de la siguiente versión, por lo que, únicamente, se podrá añadir documentación, corregir errores o realizar alguna tarea relativa a la release, pero nunca se podrá añadir una nueva característica. En este caso, habría que generar una nueva release.
Una vez que la release esté lista, se fusiona la rama en master, generando una etiqueta con el número de versión; se fusiona en develop, que puede haber avanzado mientras se terminaba la release, y se elimina la rama de release.
La utilización de está rama de release hace posible que se puedan seguir incluyendo características en el proyecto, mientras se termina de completar y revisar la release, lo que facilita el trabajo de varios equipos en diferentes releases.
Las ramas de hotfix se utilizan para poder corregir rápidamente errores en producción. El funcionamiento de las ramas de hotfix es muy parecido a las de release, una vez terminada la corrección, hay que fusionar la rama tanto en master, con un tag actualizado de la versión, como en develop (o en la rama de la versión actual, en caso de estar activa).
Las ramas de mantenimiento o "hotfix" se utilizan para parchear rápidamente los lanzamientos de producción. Las ramas de Hotfix son muy parecidas a las ramas de versiones y a las ramas de funciones, excepto que están basadas en master en lugar de en develop. Esta es la única rama que debe bifurcarse directamente del maestro. Tan pronto como se complete la corrección, debe fusionarse tanto en master como en develop (o en la rama de la versión actual), y el master debe estar etiquetado con un número de versión actualizado.
Disponer de una línea de desarrollo dedicada a la corrección de errores permite a su equipo abordar los problemas sin interrumpir el resto del flujo de trabajo ni esperar al siguiente ciclo de lanzamiento. Puede pensar en ramas de mantenimiento como ramas de liberación ad hoc que trabajan directamente con el maestro. Se puede crear una rama de hotfix utilizando los siguientes métodos:
Para implementar una nueva feature, hacer un branch de la rama develop y una vez terminada crear un pull-request a la rama develop. Las ramas de release y master, serán aprobadas únicamente por LOS ADMINISTRADORES.
Las etiquetas están agrupadas por temas y diferenciadas por colores. Esto facilita la asociación de issues por temática, simplemente, relacionando issues con etiquetas del mismo color, sin entrar en detalle en el contenido de la etiqueta.
Especifican la plataforma del issue. Al trabajar sobre diferentes plataformas es necesario poder definir issues específicos para alguna de ellas.
Describen problemas en el software, es conveniente utilizarlas con etiquetas de plataforma para acotar el problema lo máximo posible.
Issues relativos a experiencia de usuario o issues de diseño de la aplicación.
Descripción de la fase en la que se encuentra el issue. Nos sirve para poder mantener un control de calidad, y saber las características preparadas para incluir en producción.
Precisan revisión del issue por parte del equipo o algún miembro de él.
Actualizaciones sobre características o procesos funcionales, que aporta una mejora de rendimiento, calidad o automatización en el software.
Nuevas funcionalidades. Incluye tanto funcionalidades de la aplicación como cualquier documentación o proceso que se genere en el proyecto.
Especifican issues para los que no se tiene suficiente información. Requieren especificaciones o detalles extra, o precisan de la finalización de otro issue con el que genera una relación de dependencia.
Issues que se han solucionado, no aplican o han quedado fuera del alcance de la aplicación, no es necesario realizar acciones sobre ellos, pero se mantienen en la planificación como desestimados.
Cuando una nueva etiqueta sea necesaria:
- Si el tema se encuentra definido, añadir la etiqueta con una auto-descripción en el campo descripción de la misma.
- Si el tema no se encuentra definido:
- Crear el nuevo tema y añadirlo a la lista.
- Especificar el tema que trataran las etiquetas.
- Añadir la etiqueta con una auto-descripción en el campo descripción de la misma.
Cuando se asigna una etiqueta a un commit, Travis lanzará el proceso de compilación (Aunque en ocasiones falla debido a errores de comunicación al descargas las dependencias necesarias por parte de Android) y publicará el APK sin firmar en la página de releases del proyecto. Hemos automatizado este proceso para que no haya que hacer nada cuando una APK final este lista para ser distribuida.
Las releases para Android sin firmar se pueden encontrar aquí: https://github.com/juanmanuelcarrera/feelmusic/releases