Elección de una estrategia de flujo de código

Es importante elegir una estrategia de flujo de código que se ajuste a la forma de trabajar del equipo. Tiene varias estrategias que se deben tener en cuenta. Al final del módulo, puede explorar las distintas opciones. El equipo web de Tailspin decide desarrollar una estrategia de flujo de código que se basa en Git y GitHub.

Cuando Mara configuró Azure Boards, ella y el equipo identificaron varias tareas iniciales que abordar. Una tarea era crear un flujo de trabajo basado en Git.

Se escuchará al equipo mientras deciden una forma mejor de colaborar. En la actualidad usan un sistema de control de versiones centralizado, pero el plan es cambiar a Git, un sistema distribuido.

Mara está trabajando con diligencia en sus características asignadas cuando entra Andy.

Andy: Hola, Mara. En la reunión de liderazgo de esta mañana se planteó que nuestro equipo y el equipo de desarrollo de juegos usan distintos sistemas de control de versiones. Para simplificar la forma en que compartimos los recursos entre los equipos, se nos ha pedido que pasemos a un sistema de control de versiones distribuido que pueda manejar mejor la colaboración.

Mara: Es bueno saberlo. Si lo recuerda, lo pusimos en nuestro panel. Ahora mismo estamos usando un sistema de control de versiones centralizado. Ahora nos funciona muy bien, pero estoy de acuerdo en que un sistema de control de versiones distribuido es una mejor opción cuando empecemos a compartir entre equipos y nuestro equipo sea más grande. En el panel también hay una tarea para aumentar la visibilidad de forma que todas las partes interesadas sepan lo que los demás hacen. Creo que un sistema de control de código fuente distribuido como Git también sería muy útil.

Andy: Hace tiempo que quiero probar Git. Pero nunca encuentro el momento adecuado. ¿Es difícil de aprender o configurar? Si parece razonable, quizás podríamos trabajar en ello ahora. Estoy cansado de tener que aplazar siempre las cosas. Y sería bueno poder ver lo que hace todo el mundo y tener acceso a la totalidad del repositorio. Bueno, ¿qué es exactamente?

Mara: Déjenme que lo explique y luego podrán decidir si les parece algo que queremos implementar de inmediato.

Mara y Andy se acercan a la pizarra para explicar el control de versiones.

Definición de Git y el control de versiones distribuido

Mara: El dibujo de la izquierda es el control de versiones centralizado como el que usamos ahora. Tenemos una versión central del código base en Control de versiones de Team Foundation (TFVC) que usa todo el mundo. Todos podemos trabajar en los archivos que tenemos que cambiar y, después, volverlos a fusionar mediante combinación (“merge”) en el repositorio principal cuando hayamos terminado con ellos.

Andy: Sí, y eso nos está funcionando. Bueno, excepto cuando me bloquearon esa vez que un cambio importante se combinó en el repositorio central.

Mara: —¡Perfecto! Se le ha bloqueado . Podríamos usar una estrategia de ramificación con TFVC para resolver el problema del bloqueo, pero según la configuración actual, es posible que la combinación se complicara ligeramente. Y cuando tuvimos ese cambio importante, , nadie pudo trabajar hasta que se resolvió. Ese problema siempre acecha porque todos usamos la misma copia del código.

A la derecha hay un dibujo del control de versiones distribuido. Seguimos teniendo un repositorio central , que es la versión estable del código base, pero cada desarrollador tiene su propia copia desde la que puede trabajar. Esto nos libera para experimentar y probar una variedad de enfoques sin afectar al repositorio central.

El control de versiones distribuido también garantiza que solo el código que funciona se fusiona mediante combinación en el repositorio central. Incluso podríamos configurar que el código no se pueda combinar hasta que se haya revisado.

Lo mejor de Azure DevOps es que funciona igual de bien tanto con los sistemas de control de versiones centralizado como el distribuido.

Andy: ¿Qué ocurre cuando más de una persona cambia el mismo archivo?

Mara: A menudo, Git puede combinar varios cambios de forma automática. Por supuesto, nos interesa que la combinación de los cambios genere siempre código que funcione. Cuando Git no puede combinar los cambios de forma automática, marca los conflictos directamente en los archivos para que una persona puede elegir qué cambios se deben aceptar.

Andy: En este momento, el código está almacenado en nuestro propio servidor. Si pasamos al uso del control de versiones distribuido, ¿dónde se almacenará el código?

Mara: Me alegro que me lo preguntes. Aquí es donde entra en juego el hospedaje.

¿Dónde puedo hospedar mi repositorio?

Mara: A la hora de decidir dónde hospedar los repositorios, tenemos varias opciones. Por ejemplo, se pueden hospedar en un servidor local, en Bitbucket o en GitHub. Bitbucket y GitHub son soluciones de hospedaje basadas en web. Podemos acceder a ellos desde cualquier lugar.

Andy: ¿Has usado alguna de ellas?

Mara: He usado GitHub antes. Tiene características que son importantes para los desarrolladores, como un acceso sencillo a los registros de cambios y características de control de versiones desde la línea de comandos o el portal en línea.

Andy: ¿Cómo funciona Git?

¿Cómo se trabaja con Git?

Mara: Como he mencionado antes, con los sistemas distribuidos los desarrolladores pueden acceder con libertad a cualquier archivo que necesiten sin afectar al trabajo de los demás desarrolladores porque tienen su propia copia del repositorio. Un clon es la copia local de un repositorio.

Cuando trabajamos en una característica o una corrección de errores, normalmente queremos probar diferentes enfoques hasta encontrar la mejor solución. Sin embargo, no es aconsejable probar el código en la copia del código base principal, porque es posible que no se quiera mantener los primeros intentos.

Para proporcionar una mejor opción, Git tiene una característica denominada bifurcación, donde se pueden mantener tantas copias como se quiera y combinar solo la que se quiere conservar. Esto mantiene la estabilidad de la rama principal.

Andy: Voy captando los conceptos. ¿Cómo se inserta el código?

¿Cómo llegan los cambios locales al código base principal?

Mara: en Git, la rama (“branch”) predeterminada o tronco se suele denominar main.

Cuando considere que el código está listo para fusionarse mediante combinación en la rama main del repositorio central compartido por todos los desarrolladores, puede crear lo que se denomina una solicitud de incorporación de cambios. Al crear una solicitud de incorporación de cambios, se indica a los demás desarrolladores que el código está listo para revisar y que se quiere combinar en la rama main. Cuando se aprueba la solicitud de incorporación de cambios, se convierte en parte del código base central.

¿Qué aspecto tiene un flujo de trabajo de bifurcación?

Andy: Todo esto parece complicado y difícil de aprender.

Mara: Git puede parecer abrumador debido a su eficacia, pero, después de acostumbrarse al flujo, se empieza a ver como algo natural.

Solo se usarán unos pocos comandos al día. A continuación, se muestra un resumen:

Andy: Parece un excelente punto de partida. Lo puedo asumir sin problema. Puedo aprender comandos más avanzados a medida que los necesite.