Crear estratégicamente una bifurcación
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
El código fuente es un recurso importante de la tarea de desarrollo. Pero administrar y desarrollar eficazmente los archivos de código fuente puede ser todo un reto cuando varios desarrolladores trabajan simultáneamente en actualizaciones de archivos. Puede utilizar un sistema de control de versiones para almacenar el código fuente en repositorios compartidos, aislar las tareas de desarrollo paralelas, integrar los cambios del código y recuperar las versiones anteriores del archivo. Un elemento clave del control de versiones es la bifurcación que permite el desarrollo simultáneo. Si crea una bifurcación estratégicamente, puede mantener el orden y la coherencia de varias versiones del software.
Team Foundation proporciona un sistema de control de versiones flexible y confiable. Puede utilizar el control de versiones de Team Foundation para administrar varias revisiones durante el desarrollo del código fuente, así como para administrar documentos, elementos de trabajo y otra información crítica en la que el equipo está trabajando.
¿Cómo administra el equipo el código mientras incluye varios cambios simultáneamente a través de varias versiones del proyecto?
Al trabajar con un sistema de control de versiones, debe considerar cómo configurar una estructura de bifurcación. Puede crear una bifurcación creando un reflejo del archivo de código fuente. A continuación, puede cambiar la bifurcación sin que afecte al origen. Por ejemplo, tal como se muestra en la estructura de bifurcación de la siguiente ilustración, la bifurcación MAIN contiene la funcionalidad completada que ha pasado correctamente las pruebas de la integración, y la bifurcación DEVELOPMENT contiene el código en el que se está trabajando. Cuando se completa una nueva funcionalidad en la bifurcación DEVELOPMENT y logra pasar las pruebas de integración, puede promover el código de la bifurcación DEVELOPMENT a la bifurcación MAIN. Este proceso se conoce como integración inversa. Al contrario, si fusiona mediante combinación el código de la rama MAIN con la rama DEVELOPMENT, el proceso se conoce como integración directa.
Para obtener más información sobre cómo crear y combinar bifurcaciones de código, vea la siguiente página en el sitio web de CodePlex: Team Foundation Server Branching Guide 2.0.
La bifurcación y la combinación implican los siguientes principios:
Cada bifurcación debe tener una directiva definida sobre cómo integrar el código en esta bifurcación. Por ejemplo, en la estructura de rama de la ilustración anterior, puede asignar un miembro del equipo para que posea y administre la rama MAIN. Este miembro es responsable de realizar la operación de bifurcación inicial, la integración inversa de los cambios de la bifurcación DEVELOPMENT a la bifurcación MAIN, y la integración directa de los cambios de la bifurcación MAIN a la bifurcación DEVELOPMENT. La integración directa es importante cuando la rama MAIN también integra los cambios de otras ramas.
La bifurcación MAIN debe contener código que haya pasado las pruebas de integración y que esté siempre preparado para una versión.
La bifurcación DEVELOPMENT (o trabajo) evoluciona constantemente porque los miembros del equipo protegen los cambios periódicamente.
Las etiquetas son instantáneas de los archivos de una bifurcación en un momento determinado.
Para obtener más información, consulte Uso de etiquetas para hacer una captura de los archivos.
Team Foundation Build permite elegir entre varios tipos de compilaciones para las bifurcaciones: manual, continua, controlada, gradual y programada. Se recomienda que la ramificación MAIN tenga un tipo de compilación de inserción en el repositorio validada. Esto significa que la bifurcación DEVELOPMENT debe pasar todos los requisitos exigidos para la bifurcación MAIN antes de poder confirmar una integración inversa. La bifurcación DEVELOPMENT debe ejecutar un tipo de compilación continua porque el equipo debe conocer lo antes posible cuándo afecta una nueva protección a esta bifurcación.
¿Con qué frecuencia debe realizar el equipo la integración inversa y directa?
Tal como muestra la siguiente ilustración, la integración inversa y directa se deben realizar al menos cuando complete un caso de usuario. Aunque cada equipo podría definir la finalización de manera diferente, la finalización de un caso de usuario generalmente significa que se completa la funcionalidad y las pruebas unitarias correspondientes. Puede realizar una integración inversa a la bifurcación MAIN únicamente después que las pruebas unitarias hayan comprobado la estabilidad de la bifurcación DEVELOPMENT.
Si tiene más de una bifurcación de trabajo (DEVELOPMENT), la integración directa de todas las bifurcaciones de trabajo se debe realizar tan pronto como se integre alguna de las bifurcaciones en la bifurcación MAIN. Dado que la bifurcación MAIN se mantiene estable, la integración directa es segura. Se podrían producir conflictos o errores en las bifurcaciones de trabajo porque no puede garantizar que las bifurcaciones de trabajo sean estables.
Es importante resolver todos los conflictos lo antes posible. Mediante una inserción en el repositorio validada para la rama MAIN, la integración inversa resultará mucho más sencilla, ya que los controles de calidad sirven para evitar conflictos o errores en esta rama. Para obtener más información, consulte Proteger una carpeta insertada en el repositorio por un proceso de compilación de inserción en el repositorio validada.
¿Cómo administra el equipo los códigos fuente que implementan diferentes casos de usuario?
Como muestra la siguiente ilustración, puede proteger periódicamente los cambios de una bifurcación de trabajo para completar un caso de usuario. Puede implementar al mismo tiempo varios casos de usuario en la misma bifurcación. Sin embargo, solo puede realizar una integración inversa en la bifurcación MAIN cuando complete todo el trabajo en curso. Se recomienda agrupar los casos de usuario que tengan un tamaño similar para que un caso de usuario grande no bloquee la integración de muchos pequeños. Puede dividir los dos conjuntos de casos de usuario en dos bifurcaciones.
¿Cuándo debe el equipo agregar una rama?
Debe crear bifurcaciones en las siguientes situaciones:
Cuando deba lanzar código en una programación o ciclo diferente al de las bifurcaciones existentes.
Cuando el código requiera una directiva de bifurcación diferente. Si crea una nueva bifurcación que tiene la nueva directiva, puede agregar valor estratégico a su proyecto.
Cuando se proporciona funcionalidad a un cliente y el equipo pretende realizar cambios que no afectan al ciclo de versiones planeado.
No debería crear una bifurcación para cada caso de usuario porque significa un alto costo para la integración. Aunque TFVC facilita la bifurcación, la sobrecarga de administrar bifurcaciones puede llegar a ser significativa si tiene muchas bifurcaciones.
¿Cómo administra el equipo los lanzamientos desde la perspectiva del control de versiones?
El equipo debería ser capaz de lanzar código al final de cualquier sprint. Mediante Team Foundation Server, se puede etiquetar una bifurcación para tomar una instantánea del código en un momento concreto. Como muestra la siguiente ilustración, se puede etiquetar la bifurcación MAIN para una versión. Esto permite devolver la bifurcación a su estado en este punto.
Como debe implementar actualizaciones en las versiones, la creación de una bifurcación para una versión ayuda al equipo a continuar trabajando de forma independiente en el siguiente sprint sin crear conflictos con futuras versiones. La siguiente ilustración muestra una bifurcación que contiene código para una actualización y que se integra de forma inversa en la bifurcación MAIN después de una versión al final del segundo sprint.
Cuando crea una bifurcación para una versión, debe crearla a partir de la bifurcación MAIN, que es la más estable. Si la crea a partir de una bifurcación de trabajo, puede causar problemas de integración, ya que no existe ninguna garantía de que las bifurcaciones de trabajo sean estables.