Crear ramas de funcionalidades hacia la excelencia

O crea ramas de tareas hasta lograrlo. O ramas de versiones. Tú eliges.

Dan Radigan Dan Radigan

Prácticamente todos los sistemas de control de versiones de hoy en día admiten las ramas: líneas de trabajo independientes que parten de una base de código central. Dependiendo de tu sistema de control de versiones, la rama principal puede llamarse master, línea principal, línea predeterminada o tronco. Los desarrolladores pueden crear sus propias ramas a partir de la línea de código principal y trabajar independientemente pero en paralelo. 

¿Por qué molestarse en crear ramas?

Las ramas permiten a los equipos de desarrolladores colaborar fácilmente dentro de una base de código central. Cuando un desarrollador crea una rama, el sistema de control de versiones crea una copia de la base de código en ese momento. Los cambios realizados en la rama no afectan a otros desarrolladores del equipo. Esto es algo positivo, obviamente, debido a que las funcionalidades en desarrollo pueden crear inestabilidad, lo cual puede llegar a ser muy disruptivo si todo el trabajo ocurre en la línea de código principal. Sin embargo, las ramas no tienen que existir en un aislamiento solitario. Los desarrolladores pueden incorporar cambios de otros desarrolladores para colaborar en funcionalidades y asegurar que su rama privada no se separe demasiado del master.

Consejo de experto

Las ramas no solo son buenas para el trabajo con funcionalidades. Las ramas pueden aislar al equipo frente a cambios estructurales importantes, como la publicación de infraestructuras, bibliotecas comunes, etc.

Tres estrategias para crear ramas en equipos ágiles

Los modelos de creación de ramas a menudo difieren entre equipos, y son objeto de debate en la comunidad de software. Un tema importante es la cantidad de trabajo que debe permanecer en una rama antes de hacer el merge de vuelta al master. 

Ramas de versiones

Las ramas de versiones se refieren a la idea de que una versión esté contenida completamente en una rama. Esto significa que en una fase tardía del ciclo desarrollo, el gestor de la publicación de versiones puede crear una rama a partir del master (por ejemplo, “Rama de versión 1.1”). Todos los cambios de la versión 1.1 deben aplicarse dos veces: una vez a la rama 1.1 y luego a la línea de código master. Trabajar con dos ramas significa trabajo extra para el equipo y es fácil olvidarse de hacer el merge en ambas ramas. Las ramas de versiones pueden ser difíciles de controlar y de gestionar debido a que muchas personas trabajan en la misma rama. Todos hemos sufrido hacer el merge de muchos cambios diferentes en una única rama. Si debes realizar una rama de versiones, crea la rama lo menos separada posible de la publicación real. 

Warning:

Release branching is an important part of supporting versioned software out in the market. A single product may have several release branches (e.g., 1.1, 1.2, 2.0) to support sustaining development. Keep in mind that changes in earlier versions (i.e., 1.1) may need to be merged to later release branches (i.e., 1.2, 2.0). Check out our webinar below to learn more about managing release branches with Git.

Ramas de funcionalidades

Las ramas de funciones a menudo están asociadas con marcas de funcionalidades, "botones" que activan o desactivan una funcionalidad dentro del producto. Esto simplifica el despliegue de código en el master, el control de la funcionalidad cuando esta se activa y el despliegue inicial del código mucho antes de que la funcionalidad llegue a los usuarios finales. 

Consejo de experto:

Another benefit of feature flags is that the code can remain within the build but inactive while it's in development. If something goes awry when the feature is enabled, a system admin can revert the feature flag and get back to a known good state rather than have to deploy a new build.

Ramas de tareas

At Atlassian, we focus on a branch-per-task workflow. Every organization has a natural way to break down work in individual tasks inside of an issue tracker, like Jira Software. Issues then becomes the team's central point of contact for that piece of work. Task branching, also known as issue branching, directly connects those issues with the source code. Each issue is implemented on its own branch with the issue key included in the branch name. It’s easy to see which code implements which issue: just look for the issue key in the branch name. With that level of transparency, it's easier to apply specific changes to master or any longer running legacy release branch.

Dado que la metodología ágil se centra en las historias de usuario, las ramas de tareas se combinan bien con un desarrollo ágil. Cada historia de usuario (o corrección de bug) habita en su propia rama, de modo que es sencillo comprobar las incidencias en curso y las que están listas para publicarse. Si quieres profundizar más en las ramas de tareas (a veces denominadas ramas de incidencias o ramas por incidencia), toma unas palomitas y no te pierdas el seminario web que aparece más abajo. Es uno de nuestros seminarios más populares. 

El villano favorito de las ramas: el merge

Todos hemos padecido la dificultad de integrar varias ramas en una única solución racional. Generalmente, en los sistemas de control de versiones centralizados, como Subversion, el merge es una operación bastante complicada. Sin embargo, los nuevos sistemas de control de versiones, como Git y Mercurial, tienen un enfoque diferente para realizar el seguimiento de versiones de archivos en distintas ramas.

Las ramas suelen tener una vida corta, lo cual significa que su merge es más fácil y flexible en toda la base de código. Entre la posibilidad de hacer el merge de ramas frecuentemente y de forma automática como parte de la integración continua y el hecho de que las ramas de vida corta contienen menos cambios, el "infierno del merge" ya forma parte del pasado en los equipos que usan Git y Mercurial.

¡Por eso las ramas de tareas son tan increíbles! 

Validar, validar, validar

A version control system can only go so far in affecting the outcome of a merge. Automated testing and continuous integration are critical as well. Most CI servers can automatically put new branches under test, drastically reducing the number of "surprises" upon the final merge upstream and helping to keep the main code line stable.