Git es el estándar de facto para los equipos de desarrollo de software ágil y de DevOps en lo referente a los sistemas de control de versiones y un elemento esencial de las cadenas de herramientas de DevOps. 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 los equipos de desarrollo ágil y de DevOps. Piensa en Git como un componente del desarrollo ágil y de DevOps; 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 funciona del mismo modo que lo hace tu equipo ágil y de DevOps (y el modo por el que debería esforzarse en trabajar).
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.
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 principal 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.
Consejo 2: Muchas ramas se pueden probar individualmente, así que aprovéchalo
Una vez que 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 y de DevOps con mejores resultados practican revisiones de código y configuran pruebas automatizadas (integración continua o entrega continua). 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 incorporación de cambios. En pocas palabras, una solicitud de incorporación de cambios es una forma de solicitar a otro desarrollador que haga una fusión 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 principal, ya que las ramas han variado.
Una rama de función de larga ejecución que no esté fusionada con la rama principal 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. 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 ocultas.
Consejo 3: Git proporciona transparencia y calidad en el desarrollo ágil
La historia de Git y de 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 principal, 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.
Adoptar una cadencia de publicación regular es fundamental para el desarrollo ágil. Para lograr que Git funcione con tu flujo de trabajo ágil, debes asegurarte de que tu rama principal 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.
