Estrategias de Git Branching

Standard

workflow

Hola a todos, para esta semana les quiero hablar de el manejo de Branches (Ramas) y el importante rol que tiene en el Plan de Control de Versiones.

Hoy en día casi todos los sistemas de control de versiones ofrecen un sistemas de líneas de ramas independientes en un sistema de código centralizado. Dependiendo del ecosistema que tengas debes adaptar el manejo de ramas con tus equipos de trabajo. Nosotros en Hunabsys tomamos ventaja de esto y este artículo es darles un panorama de lo que evaluamos y estamos usando hoy en día.

Por qué tomarnos la molestia de una estrategia de branching?

El manejo de ramas le permite a los equipos de desarrolladores el colaborar fácilmente dentro de un repositorio central. Cuando un desarrollador crea una rama, el sistema de control de versiones crea una copia del código base en cierto punto en el tiempo. Los cambios en las ramas no afectan a los otros desarrolladores del equipo. Esto es bueno, obviamente, porque nuevas características en desarrollo pueden crear inestabilidad, lo cual puede crear un caos si eso para en la línea principal de código. Pero las ramas no deben de “vivir” de manera solitaria. Los mismos desarrolladores pueden fácilmente jalar cambios de otros desarrolladores a sus ramas y colaborar en las nuevas características y asegurarse que sus ramas privadas no varíen mucho de la rama master, o principal.

Tip. No solo uses las ramas para trabajar en los desarrollos. Las ramas pueden aislar al equipo de cambios de arquitectura importantes como la actualización de frameworks, bibliotecas en común, etc.

Tres Estrategias de Git Branching para Equipos Ágiles

Los modelos de branching a veces difieren entre los equipos, y generan muchos debates entre la comunidad. Aún así estos modelos sirven para clasificarlos. Uno de los temas principales es que tanto trabajo debe permanecer en una rama antes de hacer el merge (integrar) de vuelta con master.

Branching por Releases (liberaciones)

El Branching por Liberaciones se refiere a la idea de que una liberación es mantenida completamente en una rama. Esto significa que tarde en el ciclo de desarrollo, el administrador de liberaciones creará una rama desde master (ej. “1.1 development branch”). Todos los cambios para la liberación 1.1 necesitan ser aplicados dos veces: una vez que la rama 1.1 y luego a la rama master. El trabajar con dos ramas representa un trabajo extra para el equipo y es fácil de olvidar el hacer merge sobre las dos ramas. Las ramas por liberación pueden ser pesadas y difíciles de manejar a medida que más gente esté trabajando en esa rama. Todos hemos tenido sentido el dolor de tener que integrar muchos cambios diferentes en una rama simple. Si tu tienes que crear una rama de liberación, crea la rama lo más cercano posible a la liberación actual.

El Branching por Liberación es una parte importante del soporte de software versionado en el mercado. Un solo producto puede tener varias versiones de liberación (ej. 1.1, 1.2, 2.0) para apoyar a sostener el desarrollo.

Branching por Features (características)

Muchos equipos ágiles que buscan por un modelo de ramas más flexible se han movido de ramas por liberaciones ramas por características. Un modelo de ramas por características mantiene todos los cambios de una característica en particular dentro de una rama. Cuando la característica está totalmente probada y validada por pruebas automáticas, entonces la rama es integrada en master.
Las ramas por liberaciones a menudo son usadas con banderas de características, las cuales te permiten habilitar o deshabilitar una característica dentro de un producto. Esto hace fácil el desplegar el código en master y controlar cuando una características es activada, haciendo fácil inicialmente desplegar el código mucho antes que la característica sea expuesta a los usuarios finales.

Branching por Tareas (Task o Issue)

Cada organización tiene una manera natural de dividir el trabajo en tareas individuales dentro de un administrador de tareas.
Estas tareas se vuelven el punto de contacto central del equipo para esa pieza de trabajo.
El Branching por Tarea, conecta directamente estas tareas con el código fuente. Cada tarea es implementada en su propia rama con su identificador incluido en el nombre de la rama. Es fácil el ver que código implementa que tarea: sólo tienes que mirar la llave de la tarea en el nombre de la rama. Con ese nivel de transparencia, es fácil el aplicar cambios específicos a master o cualquier otra rama de liberación.
Dado que todas los equipos ágiles usan Historias de Usuario, las ramas por tarea se llevan bien con el desarrollo ágil.
Cada historia de usuario (o bug fix) vive en su propia rama, haciendo fácil de ver que tareas están en progreso y cuales están listas para liberar.

El principal problema con el branching, los Merges. (Integraciones)

Todos hemos experimentado el dolor de tratar de integrar multiples ramas en un proyecto digamos sensible. Tradicionalmente, los sistemas de control centralizados como Subversion han hecho los merges una operación muy difícil y dolorosa. Pero con sistemas de control de versiones más nuevos como Git y Mercurial toman un enfoque diferente al manejar las versiones de archivos que viven en diferentes ramas.
Las ramas tienden a tener una vida corta, haciéndolas más fácil de integrar y más flexibles a través del código base. Entre las habilidades de integrar ramas de manera frecuenta y automática como parte de una Integración Continua (CI en inglés), y el hecho de que las ramas de vida corta simplemente contienen unos pocos cambios, los problemas con las integraciones se vuelven cosas del pasado para los equipos que estmos usando Git o Mercurial.
Esto es lo que hace el Branching por Tareas tan atractivo!

Valida, valida, valida

Un sistema de control de versiones lo más que puede llegar en el resultado es hasta la integración (merge). La automatización de pruebas y la integración continua son igual de críticos. La mayoría de los servidores de integración continua (CI en inglés) pueden poner nuevas ramas en pruebas de manera automática, reduciendo drásticamente el número de “sorpresas” antes de que la integración final se haga y te ayuda a mantener la línea principal de código estable.

Nota: Opciones con GitHub y BitBucket

GitHub y BitBucket son un par de sistemas de social coding, que se enfocan en el flujo de rama por tarea, la ventaja que tienen estos sistemas es que te ofrecen un enfoque integral. Por un lado tienen el control de versiones, ofrecen los servicios de un Issue Tracker (Tareas o Buts), te permiten hacer referencias a estos issues en los comentarios de los commits, y te ofrece mecanismos automatizados para la creación de ramas con base en estos issues. Si cuentas con un sistema de estos en tu compañía deberías estar usando ya el Branching por Tareas.

Qué estrategia usamos en Hunabsys?

En Hunabsys estamos en un paso previo a las Ramas por Tareas al implementar ramas de trabajo por Sprint y por Usuario en Git.
Nuestras liberaciones en nuestro marco ágil son por Sprint y debido a que estamos en proceso de automatizar las creaciones de ramas desde nuestro sistema de Administración de Proyectos, decidimos dividir los espacios de trabajo por participante del equipo de Scrum. Esto nos ha permitido trabajar de manera más rápida y activamente estar integrando a la rama del Sprint al terminar cada tarea que vamos terminando.
Entre más nos tardábamos en actualizar nuestras tarjetas de nuestros tableros Kanban e ir a integrar en la rama del sprint, más dolorosa se volvía la integración. Por lo que lo hicimos parte de nuestro proceso diario de desarrollo, por cada tarjeta de tarea terminada, significa un commit más que debe de quedar integrado en la rama del sprint, lo cual en un futuro cercano nos tendrá dará información de rastreabilidad del flujo de actividades terminadas con sus respectivos commits.
Por otro lado también usamos los tags que te ofrece Git para ir marcando las líneas base de los proyectos que vamos liberando.

Espero que este artículo te sirva para replantear tu estrategia de branching en tus equipos de trabajo y nos vemos en el siguiente post.

Leave a Reply

Your email address will not be published. Required fields are marked *