Crear ramas de funcionalidades hacia la excelencia

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

Dan Radigan Dan Radigan
Buscar temas

Prácticamente todos los sistemas de control de versiones de hoy en día admiten las ramas; es decir, 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 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 esa rama no afectan a otros desarrolladores del equipo. Esto es algo positivo, obviamente, ya que las funciones que están en desarrollo pueden crear inestabilidad, lo cual podría llegar a ser muy disruptivo si todo el trabajo ocurre en la línea de código principal. No obstante, las ramas no tienen por qué estar aisladas: los desarrolladores pueden incorporar cambios de otros desarrolladores para colaborar en funciones y conseguir a la vez que su rama privada no se separe demasiado de la principal.

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 suelen ser distintos según el equipo y son objeto de debate en las comunidades de software. Un tema importante es la cantidad de trabajo que debe permanecer en una rama antes de volver a fusionarla con la principal.

Ramas de versiones

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

Advertencia:

Las ramas de publicación son una parte importante para controlar las versiones de software en el mercado. Un único producto puede tener varias ramas de publicación (por ejemplo, 1.1, 1.2, 2.0) para fomentar un desarrollo sostenible. Ten en cuenta que los cambios realizados en versiones anteriores (por ejemplo, 1.1) podrían tener que fusionarse con ramas de publicación posteriores (por ejemplo, 1.2, 2.0, etc.). Echa un vistazo al seminario web que encontrarás más abajo para obtener más información sobre la gestión de ramas de publicación con Git.

Ramas de funcionalidades

Las ramas de función suelen estar asociadas con marcas de función, conmutadores que activan o desactivan una función dentro del producto. Esto simplifica la implementación de código en la rama principal, el control de la función cuando esta se activa y la implementación inicial del código mucho antes de que la función llegue a los usuarios finales.

Consejo de experto:

Otra ventaja de los indicadores de funciones es que el código puede permanecer inactivo en la compilación durante su desarrollo. Si algo sale mal al activar la función, un administrador del sistema puede revertir su indicador para volver a un estado bueno conocido en lugar de implementar una nueva compilación.

Ramas de tareas

En Atlassian, nos centramos en un flujo de trabajo de rama por tarea. Cada organización tiene una forma natural de dividir el trabajo en tareas individuales en un gestor de incidencias, como Jira Software. Así, las incidencias se convierten en el punto de contacto central del equipo para esa tarea. La ramificación de tareas, también conocida como ramificación de incidencias, conecta directamente esas incidencias con el código fuente. Cada incidencia se implementa en su propia rama con la clave de incidencia incluida en el nombre de la rama. Ver qué código implementa cada incidencia es muy sencillo: solo hay que buscar la clave de incidencia en el nombre de la rama. Con tal nivel de transparencia, es más fácil realizar cambios concretos en la rama principal o en cualquier rama de publicación anterior que lleve más tiempo.

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 error) 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), ve a por 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

Un sistema de control de versiones tiene muchas más limitaciones para afectar el resultado de una fusión. Las pruebas automatizadas y la integración continua también son fundamentales. La mayoría de los servidores de integración continua ponen las nuevas ramas a prueba de manera automática, lo que reduce enormemente el número de "sorpresas" en la fusión final en el repositorio remoto y contribuye a la estabilidad de la línea de código principal.

A continuación
Git branching video