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 suficiente flexible como para soportar una gama de flujos de trabajo que satisface 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 en el canal 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 debe esforzarse en que así sea).

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 en 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. Sin embargo, hablando en términos generales, se trata de 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 (piensa en requisitos), el alcance del proyecto y qué tareas de las que necesita la función se tienen que desglosar 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, de una corrección de error como de 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, cuenta con su propia versión aislada de forma eficaz 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 de 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 publicación, por ejemplo. Esto permite a los desarrolladores estabilizar y endurecer el trabajo programado para una publicación concreta, sin retrasar a otros desarrolladores que están trabajando en futuras publicaciones.

Una vez que has creado una rama de publicación, tendrás que fusionarla regularmente con tu rama maestra para garantizar que el trabajo con las funciones 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 terminadas y listas para las revisiones del código, Git desempeña otro papel clave en el flujo de trabajo del desarrollo ágil: la realización de pruebas. Los equipos ágiles con éxito 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 solicitud de extracción. En pocas palabras, una solicitud de extracción es una forma de solicitar a otro desarrollador que fusione una de tus ramas en la rama maestra 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 extracción 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 solicitudes de extracción significa que cuando el código está terminado, tienes la documentación para saber con confianza que tu trabajo está 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: un signo de un gran equipo ágil.

Consejo de experto:

Adoptar una cadencia de publicación regular es fundamental para el desarrollo ágil. Para lograr que Git funcione con tu flujo de trabajo de metodología ágil, debes asegurarte de que tu rama maestra siempre está verde. Esto significa que, si una función 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