Gitflow, trunk flow, commit a master y rezar flow, Githubflow y todos los demás flujos de trabajo están orientados a proyectos de desarrollo web generalmente. Si buscamos por internet ninguno mencionan cómo funcionaría en una aplicación movil.
En el desarrollo de aplicaciones móviles el principal condicional para que el flujo se vea alterado es el tiempo que se tarda en que una versión esté disponible para el público. Esto debido a que las tiendas, tanto en Android como en IOs requieren un tiempo para poder revisar la aplicación.
Este tiempo de espera hace que sea mucho más difícil la aplicación de flujos que impliquen probar funcionalidades en producción y si algo falla, hacer un rollback.
Para solventar estos problemas, en la empresa para la que trabajo hemos adoptado un flujo distinto para las aplicaciones en Android y IOs.
Este flujo es una combinación entre Github flow y un flujo basado en sabores.
Generalmente se tiene la siguiente notación para las ramas:
developfeature/<some-feature>bugfix/<some-bug>Como será obvio, la rama
develop debe contener todo lo que vaya a la Google Play Store. El problema es que a veces existen features que se necesitan probar en los canales de interna y beta por un buen tiempo sin embargo, no podemos descuidar el canal de producción con otros fixes y features.Ahora se propone usar una notación para features que son inestables y que se deben probar en los diferentes canales, estas serán las ramas de flavors.
Las ramas flavor contendrán todo lo que existe estable en develop, además de una feature que se está tratando de probar.
La diferencia de las ramas feature y flavor es que desde las ramas flavor si se puede sacar versión hacia la Play Store, y el tiempo de vida puede ser más prolongado.
Lo ideal es que el tiempo de vida de la rama flavor sea lo más corto posible, y una vez que la funcionalidad se ha probado correctamente se pueda integrar con develop.
Además tener en cuenta que no todas las features requerirán de probarse aparte, quedará a criterio de los programadores si la features es suficientemente grande como para crear un flavor.
En resumen:
develop: Rama principal. Se pueden sacar versiones desde aquí.
feature/<some-feature>: Ramas que se crean para nuevas funcionalidades. Se incorporaran a las versiones cuando se integren endevelop
bugfix/<some-bug>: Ramas con fixes. Se incorporaran a las versiones cuando se integren endevelop
flavor/<some-big-feature>: Ramas que se crean para features demasiados grandes y posiblemente inestables. Deberán contener el código en develop y además la funcionalidad adicional. Se puede sacar versión de estas ramas mientras están en pruebas.
Las ventajas de esto son:
- El canal de producción estará estable
- Se puede probar la funcionalidad en los demás canales e incluso con un porcentaje de usuarios
- Si ocurre un bug en las pruebas, siempre se tendrá develop