Este artículo proviene de un motor de traducción automática.

Team Foundation Server

Información orientativa sobre bifurcaciones y combinaciones de Visual Studio TFS

Bill Heys

Descargar el ejemplo de código

Desde sus comienzos en 2006, el equipo de Rangers de ALM de Visual Studio haya operado dentro de la división de desarrollo de Microsoft para fomentar la colaboración entre los grupos de productos de Visual Studio, los servicios de Microsoft y de la Comunidad de Microsoft Most Valuable Professional (MVP). La visión del estándar del equipo Rangers es "acelerar la adopción de Visual Studio con las soluciones para características ocultas o instrucciones out-of-band" de según la funcionalidad que falta y quitar los bloqueadores de elementos de adopción de la dirección. La colaboración entre la variedad de expertos en tecnología y negocios permite que el Rangers que dotan a Comunidades compartiendo experiencias reales. (Se puede obtener más información acerca de los Rangers en msdn.microsoft.com/vstudio/ee358786.)

La Guía de ramificación 2010 (tfsbranchingguideiii.codeplex.com) de Visual Studio Team Foundation Server (TFS) consolida orientación práctica y profunda alrededor de la bifurcación y combinación con 2010 de TFS de Visual Studio, proporcionando las lecciones y laboratorios prácticos aprendidas de la Comunidad. En este artículo, le presentaremos a algunos de los escenarios de bifurcación avanzados que estamos trabajando para la próxima versión de la guía.

La bifurcación: «hoy estado de la nación»

Las instrucciones de bifurcación Rangers iniciado como un proyecto de Rangers después de que se publicaron a Visual Studio 2005 y 2005 de TFS. Esta primera versión de la Guía de Rangers se publicó en CodePlex en 2007.

En 2008, los Rangers dio comienzo el proyecto II de orientación para la bifurcación. Esta versión de la segunda, se reorganizan las instrucciones en un conjunto de documentos relacionados (principal, escenarios, Q & A, diagramas, pósters y así sucesivamente). Cada uno de los documentos secundarios se ha concebido para ampliar la orientación principal como se muestra en el documento principal ramificación. Directrices de bifurcación Cazador II se publicó en CodePlex finales de 2008.

En 2009, el equipo de Rangers nuevamente supuso un nuevo proyecto de orientación de la bifurcación: 2010 de instrucciones de bifurcación. Esta versión tercera que se centra en la que muestra muchas características nuevas de bifurcación en 2010 de Visual Studio y en 2010 de TFS.  Una nueva característica clave en 2010 es la visualización de la sucursal.

En parte debido a que la versión más reciente se titula Rangers Visual Studio TFS bifurcación guía 2010, ha habido alguna confusión aparente si esta guía se aplica exclusivamente a 2010 de Visual Studio. Queremos convertirlo en texto sin cifrar que las mejores prácticas y la orientación presentada en la Guía de 2010 documentos pueden seguir aplicándose a las versiones anteriores de Visual Studio y TFS. De hecho, el equipo de Rangers ha recibido votos positivos por personas que utilicen otras herramientas de administración de Control de código fuente (SCM).

Para el año 2011, el equipo Rangers nuevamente planea una actualización de las instrucciones de bifurcación Rangers.

Si quieres publicar preguntas, comentarios espontáneos o dudas en el sitio de CodePlex.

Bifurcación de metas y estrategias

Un objetivo clave de la bifurcación es proporcionar aislamiento entre secuencias paralelas de trabajo. En el actual Rangers bifurcación orientación 2010, solían centrarse más en el aislamiento de la versión que en aislamiento durante una iniciativa de desarrollo complejos.

En muchos casos, todas las actividades de desarrollo para la próxima versión de un producto pueden pertenecer a un equipo de desarrollo único. En este caso sencillo, desarrollo de una única sucursal necesaria para aislar el desarrollo de la estabilización continuo (rama principal) o (envío versiones de producción, junto con la revisión continuada y la compatibilidad de service pack) de la ingeniería sostenida.

Los Rangers obtener frecuentes acerca del soporte técnico para iniciativas de desarrollo más complejas donde una rama de desarrollo único no proporciona la suficiente flexibilidad o aislamiento para un mayor esfuerzo de desarrollo de producto. En la próxima versión de la Guía de bifurcación Rangers, iremos agregando mayor orientación en los escenarios de desarrollo complejos, como el equipo de desarrollo de características de direccionamiento.

Nos gusta separar el análisis de estrategias de bifurcación en dos áreas:

1. ¿Cómo mi software de de de organización desarrollar? ¿Disponemos de una estructura de equipo pequeños y sencillos o es necesario admitir los equipos más complejos con los esfuerzos de desarrollo en paralelo?
2. ¿Cómo mi software de de de la versión de organización a sus clientes, ya sea internos o externos? ¿Es necesario mantener varias versiones de lanzamiento? ¿Necesitamos proporcionar revisiones o service Pack?

En algunos escenarios, estrategia de lanzamiento de una organización puede influir en el proceso de desarrollo, particularmente la estructura de los equipos de desarrollo. A menudo, sin embargo, la complejidad del proceso de lanzamiento y la estrategia de bifurcación puede ser independiente de la complejidad del proceso de desarrollo y la estrategia de bifurcación.

Al diseñar una estrategia de bifurcación, considere la posibilidad de no sólo la estructura de ramas, sino también el proceso de bifurcación. Por ejemplo, en el plan de bifurcación básica que se describe en las instrucciones de bifurcación Rangers 2010, hay sólo tres ramas (principal, desarrollo y lanzamiento). Una buena estrategia de bifurcación describirá las relaciones de la sucursal (por ejemplo, Main es un elemento primario a la rama de desarrollo y la bifurcación de la versión).

Además, una estrategia de bifurcación debe describir el proceso implicado en la estructura de ramas. Por ejemplo, ¿con qué frecuencia se crean código en la rama principal? ¿Con qué frecuencia combinar el código (integración directa) desde la rama principal de las ramas de desarrollo? ¿Cuáles son las condiciones para la combinación de código (integración inversa) de una rama de desarrollo hacer a la rama principal y así sucesivamente? Analicemos algunos escenarios típicos de bifurcación.

El escenario de equipo de la característica

A menudo, las organizaciones necesitan una estrategia de bifurcación para apoyar los esfuerzos de desarrollo de grandes y complejos que implican a varios equipos de desarrollo o los equipos trabajar en paralelo. Caso de duda acerca de cuántos de desarrollo separadas de las sucursales son necesarios. Si tengo varias ramas de desarrollo, cuándo y cómo ¿se integra las características desarrolladas por un equipo con las características desarrolladas por otros equipos? Respuestas a estas preguntas se deben incorporar en una estrategia de bifurcación en el desarrollo.

Comencemos con la descripción de una iniciativa de desarrollo complejos. Aunque puede haber un calendario de publicaciones comunes para la iniciativa todo, puede haber varios equipos de características independientes que trabaja en hitos independientes. Como estas características son Finalizar y probar, deberá integrarse en la rama principal.

En un solo equipo, cada desarrollador utilice espacios de trabajo locales para aislar los cambios de otros equipos de su equipo. Las bifurcaciones son una buena manera de aislar los cambios realizados por un grupo de trabajo de los cambios realizados por otros grupos de trabajo en paralelo en el mismo producto de trabajo de equipo de características. Sin un equipo de características de aislamiento, los cambios realizados por un equipo pueden introducir cambios importantes que afectan a la velocidad de otros equipos.

Creación de la estructura de bifurcación para el equipo de características de aislamiento es relativamente sencilla. Pero, en primer lugar, es necesario planear cómo las ramas del grupo de trabajo se integrarán más adelante. ¿Agregamos una rama de integración de"" entre la rama principal y de las ramas del grupo de trabajo, como se muestra en de la figura 1?

Figura 1 de principal y las ramas de la integración

¿O se elimine la capa de integración y integran el grupo de trabajo cambia a otra forma? ¿Cuál es la recomendación?

Se recomienda reducir al mínimo el número de niveles en una jerarquía de bifurcación. Agregar una capa de integración entre principal y de las ramas del equipo de características de forma eficaz, duplica las combinaciones necesarias para mover los cambios entre la rama principal y sus características. Bifurcación de ayuda a aislar los cambios, pero el costo de la bifurcación es el esfuerzo resultante es necesario que combine código entre las ramas y resolver conflictos de combinación que siempre parecen que se presenten. Agregar una capa de integración duplica la probable que duplica el esfuerzo necesario para resolver conflictos de combinación y combinaciones.

Si ya no es preciso que la capa de integración, se reduce el número de capas en la jerarquía de bifurcaciones. ¿Pero, donde tiene lugar la integración de Feature equipo 1 y 2 del equipo de función y dónde se prueba la integración? A fin de mantener la rama principal lo más estable posible, evitar la introducción de cambios de integración no se hayan probado en la rama principal. Sin una integración capa, la combinación de características y la integración de las pruebas deben realizarse de forma controlada en las ramas del grupo de trabajo a sí mismos.

Se recomienda realizar diariamente se basa en la rama principal (estable) y, después de una buena generación diaria, haciendo una combinación de principal a las ramas de desarrollo (función). Don ' t comparar el código de una rama de la característica Volver al principal hasta que el código en la rama de la función es relativamente estable. En otras palabras, la función debe pasar las puertas de aseguramiento de calidad antes de que se combina con la principal.

Sólo cuando el código de una rama de la función se considera "listo para publicarse" o "preparado para compartir con otros equipos" debemos tendremos en cuenta esta rama de la característica de integración con Main o con otras ramas de la función. Figura 2 ilustra este proceso después de cada hito "listo para la versión".

Figura 2 de la bifurcación de la característica

Los siguientes son los pasos del proceso:

• Antes de combinar la rama de equipo de características 1 con Main, realice una combinación final (integración directa o FI) desde Main en la rama de equipo de características (1).
• Completar una prueba final de esta integración de código a partir de la principal con el código en la rama de equipo de características (1).
• Una vez que el código en la rama de equipo de características 1 es estable, combinar este código (integración inversa o RI) volver al principal.
• En este momento, el código de Main incorpora el código del equipo de características (1).
• Realizar una generación y prueba en Main, equivalente a la generación diaria. En la siguiente generación correcta de Main, combinar principal a cada una de las ramas del grupo de trabajo. Inicialmente, se generará en el código de equipo de características (1) se combine con el código de función de equipo 2.
• Probar la integración de código de equipo de características 1 con el código de la función de equipo 2 en la rama de la función de equipo 2.
• Cuando el código de función de equipo 2 está lista para el lanzamiento o preparado para compartir con otros equipos, combinar el código de función Team 2 volver al principal. Pero primero realizar una combinación final a partir de la principal en función de equipo 2 y probar la integración final.

Nota: Un requisito clave para omitir una capa de integración independiente es la capacidad para utilizar pruebas automatizadas para las aplicaciones integradas. Ayuda de pruebas automatizada reduce el impacto en el código de velocidad (es decir, una característica de productividad del equipo) como de las obras de equipo para identificar y resolver los problemas que surgen a partir de la combinación de muchos cambios en una rama.

Si no está disponible para probar cambios de la integración de las pruebas automatizadas, el riesgo es que velocidad de código de los grupos de trabajo se verá afectado negativamente cuando éstos comprometen la comprobación manual para identificar y resolver los errores. En este escenario, una organización puede considerar la adición de una capa de integración entre principal y de las ramas de la función. Como mencionamos anteriormente, la capa de integración puede producir un aumento de la combinación y la resolución de conflictos de combinación. Pero el beneficio podría ser que puede permitir la necesidad de esta capa para la integración con el menor impacto en la velocidad del código de los grupos de trabajo.

Una buena estrategia de bifurcación, requiere un sonido junto con un sonido en el proceso para garantizar la velocidad máxima del código para los grupos de trabajo al mismo tiempo mantener la estabilidad de la rama principal de la bifurcación de estructura de bifurcación.

Escenario de uso compartido de código común

Para compartir el código común entre proyectos es un reto para muchas organizaciones. Existen tres técnicas principales para compartir código entre proyectos o soluciones en Visual Studio:

• Vinculación de archivos
• Uso compartido de archivo binario (ensamblado)
• Uso compartido del código fuente

Como analizamos en otro lugar en este artículo, también existen varias técnicas para el aislamiento de código:

• Aislamiento de proyectos de equipo
• Aislamiento de la sucursal
• Aislamiento del área de trabajo

Elegir la estrategia de uso compartido de código correcta para su organización probablemente implica una combinación de técnicas de uso compartido de código y técnicas de aislamiento.

La vinculación de archivos: Se trata de una característica de Visual Studio (Agregar elemento existente), donde varios proyectos pueden compartir una referencia a un solo archivo de origen. Vinculación de archivos es más adecuada para proyectos pequeños con un número limitado de archivos que se comparte. (Esto se asemeja a compartir archivos de Visual Source Safe.)

Con la vinculación de archivos, hay sólo una versión del archivo de origen vinculado a mantener. Los cambios realizados en el archivo vinculado se reciben inmediatamente en todos los proyectos que se vincula al archivo. La desventaja de vincular el archivo es que los cambios realizados en el archivo vinculado deben coordinarse con todos los equipos de proyecto dependiente. Los cambios incluso cuidadosamente coordinados pueden provocar la cambios importantes en proyectos dependientes.

Binario de uso compartido (referencias de ensamblado): Con compartir binarios, una solución de Visual Studio hace referencia a código compartido común con referencias de ensamblado. En este caso, generar o compilar la solución dependiente también no compila el código de origen compartido común. Compilar proyectos dependientes más rápidamente utilizando las referencias de ensamblado en lugar de referencias del proyecto.

Los equipos que dispone del código común tengan total de propiedad y el control, lo que significa que el control, el control de versiones y la calidad del producto probablemente sea mejor y se evitan la bifurcación y la combinación de las complejidades en teoría.

Debido a que los equipos de reutilizar el código común Don tienen acceso al código fuente común, que son dependientes en el equipo de propietario para agregar características nuevas y resolver los errores en el código compartido común.

Los ensamblados para el código común pueden compartirse, cópielas en un recurso compartido de archivo conocidos que puede hacer referencia a proyectos dependientes. Los ensamblados firmados con posible que deba agregarse a la caché de ensamblados Global. Como alternativa, se pueden copiar los ensamblados desde el código común de proyecto de equipo a una carpeta bin bajo la rama del principal del proyecto dependiente.

El uso compartido de código fuente: Con el código de fuente compartida en Visual Studio, en un proyecto dependiente se utiliza una referencia de proyecto para el código compartido común. Cuando se genera la solución, se generan todos los proyectos, incluidos los proyectos de código compartido común. Tener muchas referencias de proyecto para el código compartido con proyectos complejos, puede aumentar significativamente el tiempo de compilación.

En este escenario, el código compartido común posee y administra un equipo en su propio proyecto de equipo de TFS. Para compartir este código común, la primera rama el código a una carpeta con el proyecto de equipo del proyecto (dependiente) requiere mucho como éste:

• Cree una carpeta de proyecto de equipo del proyecto dependiente denominado "Compartir" (por ejemplo, $\Product1\Share).
• Realiza una bifurcación la rama principal de la biblioteca común (por ejemplo, EnterpriseLibrary) para la carpeta compartida del proyecto dependiente, por ejemplo \Enterprise Library\Main de $ a $\Product1\Share\EnterpriseLibrary de sucursales.
• Agregue los proyectos de código adecuados comunes a la solución del proyecto dependiente.
• Crear referencias de proyecto del proyecto dependiente de los proyectos existentes de código común en la solución.

Nota: Ramas anidadas no son compatibles en 2010 de TFS. Un error de la sucursal anidados que puede surgir al intentar realizar una operación de bifurcación que provocaría una rama nueva que se creen (encima o debajo) una sucursal existente en la estructura de carpetas (consulteFigura 3*).*

Figura 3 de ejemplo de una rama anidada, lo que provoca un Error en Team Foundation Server 2010

Su organización necesita decidir si se deben permitir cambios en el código de origen compartido común dentro de cada proyecto dependiente. Para evitar que los cambios, después de la bifurcación de la biblioteca común de la nueva bifurcación se puede realizar de sólo lectura. Todos los cambios en el origen de código común, a continuación, se deben realizados en el proyecto de biblioteca común y a combinar en los proyectos de equipo de los proyectos dependientes.

Como alternativa, se pueden realizar cambios en el origen del código compartido dentro de un proyecto de equipo dependiente. Estos cambios se pueden combinar (mediante la integración inversa) en el proyecto de biblioteca común. Su organización necesita para administrar con cuidado para evitar las incompatibilidades que hacen que la combinación de estos cambios a la biblioteca común difícil o imposible, quizás como resultado varias copias del código compartido estos cambios.

Herramientas de la arquitectura y el modelado de escenario

En Visual Studio Ultimate, puede crear UML y modelos de capa que existen en sus propios proyectos de Visual Studio distintos y pueden contener muchos paquetes, tratar con las distintas partes de la solución (consulte la Guía de arquitectura de herramientas en la vsarchitectureguide.codeplex.com de y modelado de la aplicación en msdn.microsoft.com/library/57b85fsc.aspx).

Para explorar si la bifurcación y la combinación son posible con modelos, podemos crear un entorno de prueba simple con tres escenarios, como se muestra en de la figura 4.

Figura 4 de escenarios de evaluación en un entorno de prueba a la posibilidad de prueba de bifurcación y combinación

Podemos crear una rama principal, con una solución que contiene un proyecto de modelo con un diagrama de clase UML vacío como un proyecto estable hipotético. A continuación, nos podemos bifurcar Main Scenario1, Scenario2 y Scenario3 y luego bifurcar cada escenario a una rama de Dev1 y Dev2 que representa a los equipos de desarrollo, como se muestra en de la figura 5.

Figura 5 de del proyecto de equipo de BranchingDemo, tal como se ve en el Explorador de código fuente

¿Es obvio que tenemos ningún problema con la bifurcación, pero se puede Deshacer los cambios de integrate(merge) en el modelo de ?

En Scenario1, los equipos no realiza ningún cambio de modelo y sólo uno de los dos equipos se expande los modelos con Scenerio2. El RI resultante de las ramas de desarrollo a la rama de escenario asociado es incidentes con el modelo de Scenario1 no cambiado y el modelo de Scenario2 actualizado.

Scenario3 es un ejemplo más realista en ambos equipos actualización el modelo. Se crean dos clases de equipo de Dev1 y Dev2 (equipo) crea una clase.

El lector assiduous dará cuenta de que ambos equipos creación una clase de Class1, con operaciones diferentes.

Inversa de la integración de la primera de las ramas de desarrollo de dos a la rama Scenario3 da como resultado la falsa sensación de seguridad que la combinación será fácil. Pero cuando el segundo equipo combina los cambios realizados en la rama de Scenario3, los conflictos de bloque de (.classdiagram, .layout y .uml) de tres archivos el check-in, tal como se muestra en de la figura 6.

Figura 6 de una combinación produce conflictos debidos a los cambios realizados por los dos equipos de la clase Class1

Podíamos seleccione las opciones "Mantener la versión de rama de destino" o "Tomar versión de rama de origen" y contestar la pregunta de si la combinación es posible con un "Sí". Sin embargo, el resultado, sería un equipo muy descontento perder sus cambios. La alternativa es seleccionar la opción "Cambios en combinación de herramienta de fusión" para una combinación manual, que es poco práctico, poco intuitivas y propenso a errores para la mayoría de nosotros.

¿La bifurcación y la combinación de modelos de arquitectura, por tanto, es posibles, pero es recomendable? El problema con el modelo de UML es que las visualizaciones, por ejemplo, el diagrama de clase, se extienden a través de los tres archivos principales (.layout, .classdiagram y .uml), como se muestra en de la figura 7.

Figura 7 de visualizaciones reparten tres archivos de Main

El archivo .layout define el tamaño y las posiciones de las formas en el modelo. El archivo .uml es el modelo "maestro" y el archivo .classdiagram contiene una caché del contenido del archivo .uml, que está presente en el diagrama.

Combinaciones también son difíciles, como cambios normales en las herramientas de modelado están validadas y a menudo se manejan según la herramienta para evitar que los Estados no válidos. Esta validación no sucede en una combinación XML pura, lo que hace que el riesgo de la creación de modelos no válidos que no es posible que incluso abiertos.

Si cada equipo realiza los cambios sólo a los diagramas, y si estos cambios representan las clases de paquetes independientes, se podría reducir el problema, tal como aparecería la mayoría de los cambios en archivos independientes. A pesar de ello, inevitablemente habrá algunos casos en que se cambian las relaciones que cruzan los límites del paquete.

En realidad, algunos equipos deseará bifurcar al crear nuevas iteraciones del producto, lo que hace que la bifurcación de modelos, documentación y código fuente. Modelos como, por ejemplo, la actividad, la secuencia, la capa y el diagrama de clase son buenos ejemplos de modelos que evolucionan a lo largo de iteraciones, mientras que el equipo continúa con el estándar de desarrollo y mantenimiento. Por lo tanto, es posible que en modelos y a menudo será evolucionar en dos o más de las sucursales, lo que significa que nos encontramos el escenario de ramificación y el escenario de combinación a menudo un reto en algún momento.

Todos los modelos actuales son buenos candidatos para la bifurcación, pero ninguno es favorable para la combinación. Con la perspectiva de una combinación desafiante y propensa a error, la recomendación es doble:

• Para evitar una combinación mediante la definición de una vista de la solución y el modelo que representa las clases en paquetes separados. La arquitectura tooling guía propone una solución, muestra una vista de la figura 8y una vista del modelo, que se muestra en figura 9, en función de los paquetes. Algunos debe tener cuidado cuando los diagramas tienen contenido desde varios paquetes, que es posible para la clase, el componente y el caso de uso. En este caso, para evitar conflictos de totalmente, los usuarios deberán evitar modificar los metadatos de elementos que pertenezcan al paquete "externo".

  

  Figura 8 de la estructura propuesta de basado en paquetes tal como muestra la solución ver

  

  Figura 9 de la estructura propuesta de basado en paquetes como se ve en el Explorador de modelos UML

• Mantener modelos en una rama que no estará bifurcada, al igual que los componentes compartidos.

La reserva es visualmente y editar manualmente los modelos en una rama, utilizando las opciones de opciones "Mantener la versión de rama de destino" o "Tomar versión de rama de origen" como se muestra en de la figura 10.

Figura 10 de un modelo Manual Editar combinación

Por ejemplo, los modelos difieren en las dos ramas, como se muestra y se combinan manualmente (paso 3) al comparar visualmente de los modelos y actualizar manualmente el modelo que figura en la rama superior. La sucursal con el modelo consolidado, a continuación, está integrada en inversa a Main (paso 4) y las otras con el modelo obsoleto es inversa integrada (paso 5) con "Tomar la versión de rama de destino", al resolver conflictos de modelo.

En resumen, no hay ninguna historia para la combinación de modelo automática todavía. La estrategia recomendada es para evitar un escenario de sucursal y de correspondencia con los modelos o utilizar la edición de modelo visual y manual antes de la mezcla.

Ahora hemos introducido a un número de nuevos escenarios de bifurcación que puede encontrarse en un entorno complejo del mundo real. En el siguiente artículo de esta serie, investigaré los proyectos de equipo y las colecciones de proyecto de equipo.

Bill Heys es consultor de servicios de consultoría de Microsoft para América en Nueva Inglaterra. Como un Cazador de ALM de Visual Studio, Heys se especializa en desarrollar aplicaciones personalizadas y la administración del ciclo de vida de aplicaciones con Visual Studio. Su blog se encuentra en blogs.msdn.com/b/billheys.

Willy-Peter Schaub es un arquitecto de soluciones con el Rangers de ALM de Visual Studio en el centro de desarrollo de Microsoft Canad? Dado que el mid-'80s ha sido lucha por la simplicidad y facilidad de mantenimiento en ingeniería de software. Su blog se encuentra en blogs.msdn.com/b/willy-peter_schaub.

Gracias a los siguientes expertos técnicos para la revisión de este artículo: Marcel de Vries, Jens Jacobsen, Bijan Javidi y Alan Wills