Git hace que el desarrollo de software sea pan comido

Tres consejos para hacer que Git encaje en tu flujo de trabajo de metodología ágil (y viceversa)

Laura Daly Laura Daly
Buscar temas

Git es el estándar de facto para el desarrollo de software ágil en lo que se refiere a los sistemas de control de versiones. Este proyecto de código abierto bien respaldado es lo suficientemente flexible como para soportar una gama de flujos de trabajo que satisfaga las necesidades de cualquier equipo de software. Su naturaleza distribuida (en vez de centralizada) le confiere características de rendimiento superiores y da a los desarrolladores la libertad de experimentar localmente y publicar sus cambios solo cuando están listos para su distribución al equipo.

Además de los beneficios de la flexibilidad y la distribución, hay funciones clave de Git que respaldan y mejoran el desarrollo ágil. Piensa en Git como un componente del desarrollo ágil; enviar cambios a la canalización de implementación puede ser más rápido que trabajar con versiones monolíticas y sistemas de control de versiones centralizados. Git trabaja del mismo modo que lo hace tu equipo ágil (y el modo por el que debería esforzarse en trabajar).

Consejo de experto:

Git es un sistema de control de versiones distribuido (DVCS). A diferencia de los repositorios CVS o Subversion (SVN), Git permite que los desarrolladores creen su propia copia personal del repositorio del equipo, que se aloja junto a la base de código principal. Estas copias se llaman bifurcaciones y, cuando se termina de trabajar en una bifurcación, es fácil volver a incorporar los cambios a la base de código principal.

Ramificación de Git | Orientador ágil de Atlassian

Consejo 1: empieza a pensar en las tareas como ramas de Git

Git entra en juego después de que se hayan concretado las funciones, se hayan añadido a una hoja de ruta de producto y el equipo de desarrollo esté listo. Llegados a este punto, nos desviamos un poco para dar un curso acelerado de desarrollo de funciones ágiles: los equipos de producto, diseño, control de calidad (QA) e ingeniería celebran una reunión de lanzamiento de funciones para llegar a un entendimiento compartido de lo que será una función (es decir, en los requisitos que tendrá), el alcance del proyecto y en qué tareas se tiene que desglosar la función para completarla. Estas tareas, que también se conocen como historias de usuario, se asignan entonces a los desarrolladores individuales.

Git empieza a encajar en tu flujo de trabajo de metodología ágil en este punto. En Atlassian, creamos una rama nueva para cada una de las incidencias. Tanto si se trata de una nueva función o de una corrección de error como si es una pequeña mejora a un código ya existente, todos los cambios de código tienen su propia rama.

La creación de ramas es sencilla y permite a los equipos colaborar fácilmente dentro de una base de código central. Cuando un desarrollador crea una rama, a todos los efectos cuenta con su propia versión aislada de la base de código en la que aplicar los cambios. Para un equipo ágil, esto significa que al dividir las funciones en historias de usuario y, después, en ramas, el equipo de desarrollo tiene la capacidad de asumir tareas de forma individualizada y trabajar de manera más eficiente en el mismo código, pero en repositorios distintos. Se acabaron las tareas duplicadas y, dado que los individuos son capaces de centrarse en pequeños trabajos en repositorios distintos al principal, no existen tantas dependencias que ralenticen el proceso de desarrollo.

Consejo de experto:

Existen otros tipos de ramificaciones de Git además de las ramificaciones de tareas, y no son mutuamente excluyentes. Puedes crear ramas para una versión, por ejemplo. Esto permite a los desarrolladores estabilizar y endurecer el trabajo programado para una versión concreta, sin retrasar a otros desarrolladores que están trabajando en futuras versiones.

Una vez que has creado una rama de publicación, tendrás que fusionarla regularmente con tu rama maestra para garantizar que el trabajo que has hecho relacionado con la función se refleje en las publicaciones futuras. Para minimizar la sobrecarga, lo mejor es crear la rama de publicación lo más cerca posible de la fecha de publicación programada.

Vista de detalles de rama de Git | Orientador ágil de Atlassian

Consejo 2: Muchas ramas se pueden probar individualmente, así que aprovéchalo

Una vez las ramas se consideran hechas y listas para las revisiones del código, Git desempeña otro papel clave en el workflow del desarrollo ágil: realización de pruebas. Los exitosos equipos ágiles practican revisiones de código y configuran pruebas automatizadas (integración continua o desarrollo continuo). Para ayudar con las revisiones de código y las pruebas, los desarrolladores pueden informar fácilmente al resto de su equipo de que el trabajo de la rama está listo para su revisión y de que esta debe hacerse a través de una pull request. En pocas palabras, una pull request es una forma de solicitar a otro desarrollador que haga un merge de una de las ramas en la rama principal y de informarle de que está lista para las pruebas.

Con las herramientas adecuadas, tu servidor de integración continua puede compilar y probar tus solicitudes de incorporación de cambios antes de que las fusiones. Así, tendrás la seguridad de que no surgirán problemas tras la fusión. Esta seguridad facilita la reorientación de las correcciones de errores y de los conflictos en general, dado que Git conoce la diferencia entre la rama y la base de código maestra, ya que las ramas han variado.

Consejo de experto:

Una rama de función de larga ejecución que no esté fusionada con la rama maestra puede dañar tu capacidad de ser ágil e iterar. Si tienes una rama de función de larga ejecución, recuerda que en realidad tienes dos versiones divergentes de tu base de código, lo que dará como resultado más correcciones de errores y conflictos. Sin embargo, la mejor solución es tener ramas de función de corta duración. Esto puede conseguirse desglosando las historias de usuario en tareas más pequeñas, planificando cuidadosamente los sprints y fusionando el código pronto para lanzarlo como funciones oscuras.

Consejo 3: Git proporciona transparencia y calidad en el desarrollo ágil

La historia de Git y la metodología ágil se basa en la eficacia, las pruebas, la automatización y la agilidad general. Una vez que hayas fusionado una rama con la rama maestra, tu flujo de trabajo de metodología ágil está terminado. Del mismo modo, fusionar código mediante las solicitudes de incorporación de cambios significa que cuando el código está terminado, tienes la documentación para saber con confianza que tu trabajo tiene luz verde, que otros miembros del equipo han aprobado el código y que está listo para su publicación. Esto permite que los equipos ágiles se muevan rápidamente y con confianza para publicar a menudo, lo cual es una característica de los grandes equipos ágiles.

Consejo de experto:

Adoptar una cadencia de publicación regular es fundamental para el desarrollo ágil. Para lograr que Git funcione con tu workflow ágil, debes asegurarte de que tu rama principal siempre está verde. Esto significa que si una funcionalidad no está lista, es mejor esperar a la siguiente publicación. Si pones en práctica ciclos de publicación más cortos, esto no debería suponerte, ni te supondrá, ningún problema.

A continuación
Branching