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?
Paso 1: Al comenzar a trabajar en una característica o corrección de errores nueva, lo primero que hay que hacer es asegurarse de que empezar con el código base estable más reciente. Para ello, la copia local de la rama main se puede sincronizar con la copia del servidor. Esto extrae la copia local de todos los demás cambios de desarrollador que se insertaron en la rama main del servidor desde la última sincronización.
Paso 2: Para asegurarse de que se trabaja de forma segura en la copia del código, se crea una rama solo para esa característica o corrección de errores. Como puede imaginar, tener muchas ramas para todas las operaciones que se van a realizar podría ser difícil de recordar, por lo que usar una buena convención de nomenclatura es fundamental.
Antes de realizar cambios en un archivo, se extrae del repositorio una rama nueva para saber que se trabaja en los archivos de esa rama y no de otra. Se puede cambiar de rama en cualquier momento mediante la extracción de esa rama del repositorio.
Paso 3: Ahora ya puede realizar los cambios que quiera de forma segura, ya que solo se realizan en su rama. Mientras trabaja, puede confirmar los cambios realizados en la rama para asegurarse de no perder el trabajo y proporcionar una manera de revertir cualquier cambio realizado en las versiones anteriores. Antes de poder confirmar los cambios, tendrá que almacenar provisionalmente los archivos para que Git sepa cuáles están listos para confirmar.
Paso 4: El paso siguiente consiste en insertar, o cargar, la rama local en el repositorio remoto (por ejemplo, GitHub) para que otros usuarios puedan ver en lo que está trabajando. No se preocupe, esto todavía no combina los cambios. Puede insertar el trabajo con la frecuencia que quiera. De hecho, es una buena forma de crear una copia de seguridad del trabajo o de poder trabajar desde varios equipos.
Paso 5: Este paso es habitual, pero no obligatorio. Cuando esté satisfecho de que el código funciona según lo previsto, puede incorporar los cambios mediante “pull” o volver a fusionar mediante combinación con “merge” la rama main remota en la rama main local. Se han realizado cambios que todavía no están disponibles en la rama main local. Una vez que haya sincronizado la rama main remota con la suya, fusione mediante combinación con “merge” la rama main local en la rama de trabajo y vuelva a probar la compilación.
Este proceso ayuda a garantizar que la característica funciona con el código más reciente. También ayuda a asegurarse de que el trabajo se integrará sin problemas al enviar la solicitud de incorporación de cambios.
Paso 6: Ahora el código local se debe confirmar e insertar en el repositorio hospedado. Es lo mismo que los pasos 3 y 4.
Paso 7: Por fin está listo para proponer los cambios en la rama main remota. Para ello, se inicia una solicitud de incorporación de cambios. Cuando se configura en Azure Pipelines o en otro sistema de CI/CD, este paso desencadena el proceso de compilación y puede ver los cambios que se mueven a través de la canalización. Después de que la compilación se realice correctamente y otros usuarios aprueben la solicitud de incorporación de cambios, el código se puede combinar en la rama main remota. (Se trata de un usuario que puede combinar los cambios).
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:
| Category | Para realizar esta tarea | Usar este comando |
|---|---|---|
| Administración de repositorios | Crear un repositorio de Git | git init |
| Descargar un repositorio remoto | git clone |
|
| Rama | Crear una rama | git checkout |
| Almacenar provisionalmente los cambios y confirmarlos | Ver qué archivos han cambiado | git status |
| Almacenar provisionalmente archivos para la confirmación | git add |
|
| Confirmar archivos en la rama | git commit |
|
| Sincronización remota | Descargar una rama desde un repositorio remoto | git pull |
| Cargar una rama a un repositorio remoto | git push |
Andy: Parece un excelente punto de partida. Lo puedo asumir sin problema. Puedo aprender comandos más avanzados a medida que los necesite.