Selección de una estrategia de creación de ramas efectiva
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
La creación de ramas para los repositorios de Control de versiones de Team Foundation (TFVC) resulta útil para aislar el riesgo. Piense en los desafíos a los que se enfrentan normalmente los miembros del equipo cuando trabajan en un proyecto de software que cuenta con más de cinco o diez personas:
El grupo tiene uno (o quizá varios) equipos con distintas características y cada uno de ellos trabaja en un conjunto de funcionalidades razonablemente moderado. Cada equipo también depende, no obstante, de funcionalidades compiladas por otros equipos. Debe aislar el riesgo de los cambios introducidos por el trabajo hecho por cada uno de estos equipos y, finalmente, combinar todos los esfuerzos unidos en un único producto.
El equipo de prueba necesita una versión estable del código que va a probar y, simultáneamente, los desarrolladores de software deben seguir avanzando con nuevas características que pueden llegar a desestabilizar el producto de vez en cuando.
El software tiene dos versiones anteriores y una versión actual en curso. Aunque la mayor parte del esfuerzo de desarrollo se dedica a la versión actual, se deben admitir aún las versiones anteriores con eventuales lanzamientos de Service Pack, correcciones y revisiones de seguridad críticas, así como otros cambios.
En este artículo se exploran algunas estrategias comunes de creación de ramas para ayudarle a tomar la decisión correcta.
A diferencia de las ramas de Git, que tienen ámbito de repositorio, las ramas de TFVC tienen un ámbito de ruta de acceso y no son tan ligeras. Mantenga un nivel alto a la hora de crear ramas y créelas solo cuando necesite aislar código o versiones.
Solo principal
La estrategia Solo principal puede basarse en carpetas o tener la carpeta mainconvertida en una rama para habilitar características de visibilidad adicionales. Los cambios se confirman en la rama principal y, opcionalmente, se indican los hitos de desarrollo y versión con etiquetas.
RIESGO: la mutabilidad y la falta de historial con etiquetas TFVC pueden agregar riesgo de control de cambios.
Comience con la estrategia de creación de ramas "Solo principal", cree ramas de forma estratégica y adopte otras estrategias para evolucionar a estrategias más complejas según sea necesario.
Aislamiento de desarrollo
Cuando necesite mantener y proteger una rama main estable, puede crear una o varias ramas dev desde main. Esto permite el aislamiento y el desarrollo simultáneo. El trabajo se puede aislar en ramas de desarrollo por característica, organización o colaboración temporal.
Es posible que haya cambios en la rama main. Realice siempre la integración directa de main en la rama dev y resuelva los conflictos de fusión mediante combinación. Después, realice la integración inversa de los cambios de vuelta en main. Mantenga el mismo nivel de calidad entre las ramas. Compile y ejecute pruebas de comprobación de la compilación (BVT) en dev de la misma manera que en main.
NOTA: Con esta estrategia, es probable que los equipos conserven indefinidamente la rama dev, lo que podría generar un historial grande de vales de fusión mediante combinación.
Aislamiento de características
El aislamiento de características es una derivación especial del aislamiento de desarrollo, lo que le permite crear una o varias ramas de características desde main, como se muestra en la imagen, o desde las ramas dev.
Si necesita trabajar en una característica determinada, puede ser una buena idea crear una rama de características.
Asegúrese de que la duración del trabajo en la característica y la rama de características asociada sea de corta duración. Realice una integración directa de los cambios de la rama primaria con frecuencia. Realice la integración inversa de vuelta en el elemento primario solo cuando se cumplan algunos criterios acordados por el equipo, por ejemplo, la definición de Hecho. La reversión de características en main puede resultar costosa y podría restablecer las pruebas.
Aislamiento de versiones
El aislamiento de versiones introduce una o varias ramas release desde main. La estrategia permite la administración simultánea de versiones, varias versiones paralelas e instantáneas de código base en tiempo de lanzamiento.
Cuando la versión esté lista para bloquearse, es el momento de crear una rama para la versión.
No realice nunca la integración directa desde main. Use permisos de acceso para bloquear las ramas de versión, con el fin de evitar modificaciones no deseadas en una rama release. Es posible realizar una integración inversa de las revisiones que se realicen en la rama release de vuelta en la rama main.
NOTA: Ninguno de los escenarios de creación de ramas es inmutable, lo que explica que se produzcan revisiones de emergencia en ramas release. Amplíe cada estrategia para que se adapte a sus requisitos, pero tenga presentes la complejidad y el coste asociado.
Aislamiento de mantenimiento y versiones
La estrategia de aislamiento de mantenimiento y versiones introduce ramas servicing. Esta estrategia permite la administración simultánea del mantenimiento de Service Packs y las instantáneas de código base en tiempo de lanzamiento.
Use esta estrategia si necesita un modelo de mantenimiento para que los clientes actualicen a la próxima versión principal y Service Packs adicionales por versión.
Al igual que en el aislamiento de versiones, el aislamiento de mantenimiento y las ramas release se crean cuando la versión está lista para bloquearse. No realice nunca la integración directa desde main en servicing, ni desde servicing en release. Bloquee la rama release para impedir las modificaciones. Los cambios de mantenimiento futuros se pueden realizar en la rama servicing.
Cree ramas de mantenimiento y versión para versiones posteriores si necesita ese nivel de aislamiento.
Aislamiento de mantenimiento, revisiones y versiones
Aunque no se recomienda, puede seguir ampliando las estrategias mediante la introducción de ramas hotfix adicionales y escenarios de versión asociados.
En este punto, ha explorado correctamente algunos de los escenarios comunes de creación de ramas de TFVC. Puede ampliarlos o investigar otras estrategias, como alternar las características, es decir, activar y desactivar las características para determinar si una característica está disponible en tiempo de ejecución.
Q&A
¿Por qué las ramas deben ser de corta duración?
Al garantizar que las ramas sean de corta duración, los conflictos de fusión mediante combinación se reducen al mínimo, en la medida de lo posible.
¿Por qué es necesaria la estrategia de creación de ramas "Solo principal"?
Para adoptar DevOps, debe basarse en la automatización de la compilación, las pruebas y la implementación. Los cambios son continuos y frecuentes, y las operaciones Merge son más complicadas, ya que los conflictos generados por la fusión mediante combinación suelen requerir intervención manual. Por lo tanto, se recomienda evitar la creación de ramas y recurrir a otras estrategias, como la alternancia de características.
¿Por qué se deben quitar las ramas?
El objetivo debe ser introducir los cambios en main lo antes posible, para mitigar las consecuencias a largo plazo de la fusión mediante combinación. La abundancia de ramas temporales y sin usar provoca confusión y sobrecarga para el equipo.
¿Se pueden crear ramas de código base entre proyectos?
Sí. Aun así, no se recomienda, a menos que los equipos deban compartir el origen y no puedan compartir un proceso común.
¿Qué ocurre con la estrategia de promoción de código?
La estrategia de promoción de código se considera una reliquia de la era del desarrollo en cascada. Suele tener ciclos de pruebas largos, y equipos de desarrollo y pruebas independientes. Esta estrategia ya no se recomienda. Para obtener más información sobre esta estrategia, consulte la guía sobre la creación de ramas.
Al fusionar mediante combinación la rama dev con main, ¿por qué no se detectan cambios?
Es probable que haya omitido los cambios en las fusiones anteriores, por ejemplo, mediante la opción de resolución de conflictos keep source. Consulte Fusión mediante combinación de la rama de desarrollo en main: "No había cambios que fusionar mediante combinación" para obtener más información.
¿Hay similitudes entre las estrategias de creación de ramas de TFVC y Git?
La estrategia de creación de ramas de aislamiento de características de TFVC es similar a las ramas puntuales de Git.
Autores: Jesse Houwing, Marcus Fernandez, Mike Fourie y Willy Schaub de ALM | DevOps Rangers. Puede ponerse en contacto con ellos aquí.
(c) 2015 Microsoft Corporation. Todos los derechos reservados. Este documento se proporciona "tal cual". La información y las opiniones expresadas en este documento, incluidas las direcciones URL y otras referencias a sitios web de Internet, pueden cambiar sin previo aviso. Usted asume el riesgo de utilizarla.
Este documento no le proporciona ningún derecho legal sobre ninguna propiedad intelectual de ningún producto de Microsoft. Puede copiar y usar este documento para su uso interno de referencia.