Crear ramas de funcionalidades hacia la excelencia

O crea ramas de tareas hasta lograrlo. O ramas de publicación. 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: 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 maestra, 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 funciones 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 extraer cambios de otros desarrolladores para colaborar en funciones y asegurarse de que su rama privada no se separe demasiado de la maestra.

Consejo de experto

Las ramas no solo son buenas para el trabajo con funciones. Las ramas pueden aislar al equipo frente a cambios estructurales importantes, como la actualización de marcos de trabajo, 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 volver a fusionarla con la maestra. 

Ramas de versiones

Las ramas de publicación se refieren 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 publicación creará una rama a partir de la maestra (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 maestra. Trabajar con dos ramas significa trabajo extra para el equipo y es fácil olvidarse de fusionar con 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 debes hacer una rama de publicación, crea la rama 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 a menudo están asociadas con marcas de función, "botones" que activan o desactivan una función dentro del producto. Esto simplifica la implementación de código en la rama maestra, 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 de esa unidad de trabajo. 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 fácil: 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 maestra 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. Tradicionalmente, en los sistemas de control de versiones centralizados, como Subversion, la fusión 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 fusión es más fácil y flexible en toda la base de código. Entre la posibilidad de fusionar ramas frecuente y automáticamente como parte de la integración continua y el hecho de que las ramas de vida corta contienen menos cambios, el "infierno de la fusión" 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