Para muchos de los administradores de proyectos es complicado muchas veces mantener el control de lo que sucede en tu sistema de control de versiones, este es un proceso problemático en algunos casos, dado que se generan errores y baja productividad por la mala entrega de productos finales o intermedios, lo que redunda en mayores costos y gastos al momento de crear el producto o servicio.

Además, esta situación puede aburrir a las personas que participan en el proyecto y al cliente, adicional a esto, se puede considerar el hecho que pueden quedar errores en el diseño, el código fuente del software, que muchas veces se dejan pasar hasta tener el producto esta en producción y empieza a ser usado por personas que han pagado por este producto y servicio ofrecido y esto si que es bastante critico para la continuidad del proyecto, por que acorta el ciclo de vida del producto en el mercado y la confianza con el cliente. Sobre el ultimo asunto luego hablaremos sobre el PQI que es muy importante en cada unidad productiva.

Es por ello que hemos tomado como base el diseño base propuesto por: Vincent Driessen en su articulo denominado: A successful Git branching model publicado el martes, 5 de enero de 2010 en su sitio web , para dar una visión nueva de lo que se puede hacer a nivel del sistema de control de versiones GIT en el día a día, para productos que debe ser publicados en tiendas de aplicaciones como Apple Store, Play Store, Amazon Store, Samsung Store o en servidores que utilizan el modelo SaaS o PaaS para poder que sus clientes y usuarios lo utilicen.

Vale la pena resaltar que aunque el modelo gráfico es similar al original, los cambios realizados en el gráfico pretenden que las personas encargadas de sistema de control de versiones puedan saber en cada momento que debe hacer y como debe mantener las ramas principales (Maestra / Origen) y Desarrollo activas y saber que las otras ramas pueden desaparecer sin que esto influya en el proceso que siguen en la organización.

GIT FLOW desde
SAV SOLUTIONS

Como puedes ver cada punto de color representa un compromiso (commit) que se realiza en cada una de las ramas , podrás notar que la rama maestra (master) solo tiene los compromisos que están funcionando en producción y que pueden utilizar los usuarios de producto o servicio, ya sea una versión mayor, una versión menor, una versión de corrección (sobre estas hablaremos luego).

Los compromisos de la rama desarrollo (develop) representan los avances del núcleo del producto su base principal , esta puede iniciar con las vistas creadas, la clase principal que conecta todas clases , el controlador de la vista principal y todos los demás componentes que reúnen las librerías y marcos de trabajo necesarios para el éxito del proyecto.

Los compromisos de la rama de características corresponde a los requerimientos específicos definidos por el usuario o cliente o dueño del producto, que luego de ser atomizados se implementan de forma corta en intervalos de tiempo como los sprint.

Es posible considerar que una característica mayor pueda ser una historia de usuario pues para llevar a cabo esta historia de usuario se deben realizar varias tareas puntuales que deben cumplirse en un intervalo de tiempo estrecho.

La pregunta que surge es: puede ser una historia épica de usuario una característica mayor? la respuesta es: difícilmente pues una historia épica de usuario tiene muchas historias de usuario pequeñas, que involucra muchos requerimientos funcionales, requerimientos de facilidad de uso, requerimientos arquitectónicos, requerimientos de pruebas unitarias, requerimientos de pruebas internas y personales, así que este tipo de historias de usuario tan grandes como las épicas, deben contemplarse con las historias que se representan en la rama de desarrollo (develop).

Es posible representar historias de usuario de baja prioridad en la rama de característica futura ya que pueden pasar varias historias de usuario de tamaño pequeño o mas importantes o historias de usuarios necesarias para que historia de usuario planteada como de baja prioridad se pueda implementar, también podría considerarse como una historia importante en una historia épica de usuario, que requiere de buenos acabados antes de la entrega, pudiendo hacer entregas parciales mientras esta se termina.

Esta característica futura podría estar en las versiones mayores como: 1.0, 2.0, 3.0, 4.0 y las historias de usuario detalladas, para las versiones intermedias como: 1.1, 1.2. 1.3, 1.4. y las historias de usuario muy detalladas y prioritarias para las versiones 1.1.1, 1.1.3, 1.3.4.

Para el caso de la rama de de producción o liberación, allí se registran los compromisos de las entregas hechas a los usuarios en las distintas tipos de entrega: alfa , beta, producción, dejando allí evidencia de cada cambio que se hace en el producto en el momento en que se realizan las inspecciones con pares , inspecciones externas, pruebas externas con usuarios o clientes, pruebas en las tiendas de aplicaciones como la de Apple Store, que tiene personas que hacen la revisión de los productos que se suben a la tienda, tiene sobre para pruebas de usuarios externas (Testflight) y envían recomendaciones para realizar ajustes al producto, todo esto antes de que lo usen los usuario que descargan las aplicaciones desde la tienda.

Una vez aprobada la aplicación por la tienda de aplicaciones o el dueño del producto o aprobada por el cliente que paga por el producto, se debe hace un compromiso tanto en la rama de desarrollo como en la rama maestra, esto con el fin de indicar que el producto debe continuar (desarrollo) y que también en un producto terminado que se puede usar (maestra).

Ahora, si después de todo este despliegue se siguen presentando errores identificados por los usuarios finales o reportados por las plataformas de análisis de errores con que cuentan las tiendas de aplicaciones o API’s especializadas en este campo, se puede crear una rama especialmente preparada para estos registrar los cambios a estos errores y responder rápido al cliente. En la rama de fijar errores puedes tomar el código fuente de la rama de maestra , realizar los cambios y enviar nuevamente a inspección ( liberación ) y luego a producción o si es un error mínimo de forma directamente a producción.

Ahora como puedes ver todas la rama que están en el gráfico, aparecen y desaparecen en el tiempo, así es desaparecen para evitar errores en el momento de mantener el código al día y evitar traer código de una rama antigua o tal vez una donde solo se hizo una prueba para una función en especial. Sí lo has pensado bien esta es la clave el éxito, solo mantener finalmente 2 ramas (Maestra y Desarrollo).

Espero te sirva para mantengas todo bajo control.

Agradecemos los comentarios que nos puedas hacer frente a esta publicación y así ayudar, para que sea mejor la experiencia de uso tanto tuya como para nosotros al momento de gestionar nuestros proyectos y crear buenos productos y servicios.

Si desea mas detalles sobre la utilización de este modelo, los comandos necesarios para implementarlo en su sistema de control de versiones, por favor llena el siguiente formulario y nosotros te haremos llegar la información a tu cuenta de correo electrónico.

Además si deseas estar enterado de nuevas formas de trabajo , sobre las mejoras que hacemos a nuestros productos y servicios, sobre los descuentos que hacemos en los precios de nuestros producto y mucho más sobre nuestra empresa y sobre el mundo de la economía, la ciencia, la tecnología, la salud y la innovación, suscríbete a nuestro blog, en el área inferior de esta publicación .