Fusionando y dividiendo el código compartido entre proyectos en TFS

Question

Actualmente estoy a cargo de migrar nuestras aplicaciones asp.net de la fuente segura a TFS. Tenemos tres o cuatro aplicaciones muy similares (digamos comercio electrónico) que actualmente comparten una biblioteca principal (servicios, lógica comercial, entidades, acceso a datos, etc.).

Las aplicaciones son similares pero no idénticos por lo que una aplicación puede obtener un conjunto de características que los otros no recibirá etc.

Quiero detener el intercambio de código y en su lugar establecer sucursales (si es que se adapte a) por lo si cambio algo en la biblioteca principal de la Aplicación A, tendré que fusionar los cambios con las otras ramas en lugar de que ellos obtengan los cambios automáticamente. Esto para evitar sorpresas cuando actualiza desde su troncal y de repente el núcleo ha cambiado para otro proyecto y este proyecto se rompe de alguna manera.

¿Alguna sugerencia sobre cómo debo configurar esto en TFS? ¿Debería tener un Core "principal" que no se usa directamente en ningún proyecto que sea el padre de todos los otros núcleos, así que puedo enviar los cambios hasta uno desde un núcleo y luego distribuirlo a los otros núcleos? ¿Tiene sentido y sería fácil de configurar en TFS?

Answer 1

En respuesta a su comentario, le sugiero que lea en Feature branches en el sitio web CodePlex.

Escenario 4 - Poder para la función de
En este escenario, se crea una rama desarrollo, ejecutar trabajos en esa rama, y ​​luego fusionar su trabajo de nuevo en su árbol fuente principal. Usted organice sus ramas de desarrollo según las características del producto. El siguiente es una vista físico mostrando ramificación para el desarrollo de programas:

Mi equipo de proyecto

 Development -> Isolated development branch container 
     Feature A -> Feature branch 
      Source 
     Feature B -> Feature branch 
      Source 
     Feature C -> Feature branch 
      Source 
     Main  -> Main Integration branch 
      Source 

Nos estamos moviendo alos SS-TFS en un futuro próximo.

Como lo percibo, vamos a mantener nuestro repositorio SS en línea y comenzar de nuevo en TFS. Nuestro framework probablemente obtendrá su propio proyecto en TFS. Las unidades compartidas específicas del proyecto necesitarán fusionarse de vez en cuando.

---

La forma en que estructura su repositorio depende de su situación específica. Cada escenario de rama tiene sus ventajas y desventajas específicas.

• Cuántos proyectos
• Cómo muchos desarrolladores
• Son los desarrolladores dedicados
• ¿Necesita correcciones urgentes concurrentes
• ¿Necesita servicio de paquetes de

Tome un vistazo a la CodePlex branching guide para obtener toda la información que necesita para tomar una decisión informada sobre su estructura TFS. Imprima el cheat sheets y péguelos en su pared para una referencia rápida.

Antes de ejecutar su plan rama, prestar atención a este mensaje de advertencia - cada rama se crea no tiene un costo de modo que asegúrese de obtener algunos valor de la misma. Los mecanismos de que se ramifican en TFS se simplifican a un con un solo clic derecho. Sin embargo, el costo total de la bifurcación se paga mediante la reducción de la velocidad del código a principal, los conflictos de fusión y las pruebas adicionales pueden ser costosas.

Answer 2

Supongo que ya ha investigado si realmente necesita hacer que sus "copias" se separen de los proyectos del equipo. Recuerde que el concepto de TFS de un "Proyecto de equipo" es un contenedor de alto nivel MUY GRANDE. No es lo mismo que lo que la mayoría de las tiendas de informática considera un "Proyecto". Piense en "Microsoft Vista" u "Office 2007" como un proyecto, no, diga "Un nuevo lanzamiento del Sistema de cuentas por cobrar de la empresa XYZ" como un proyecto en el sentido de Team Project.

Tengo un cliente que se decidió por un solo proyecto de equipo para TFS. No hay nada de malo en esto, y es realmente el mejor escenario en muchas circunstancias.

Si realmente necesita un aislamiento muy fuerte entre sus copias de la aplicación (tal vez son clientes independientes y necesita una separación de seguridad muy fuerte) y debe tener proyectos de equipo separados.

Dicho eso, usted todavía, como ha indicado necesita compartir el código entre las instancias de su aplicación. Lo primero que recomiendo encarecidamente es alejarse del uso compartido de "Cortar y pegar". Yo realmente tratar de aislar el código compartido en una solución independiente y generar binarios para que (tal vez que ya has hecho esto!)

Esto se trata en los TFS CodePlex: http://tfsguide.codeplex.com/

Otro enfoque que he hecho para varios clientes, es tener un proyecto de equipo que contenga el código compartido. El "Build" crea los binarios para el código compartido, y el "Deploy" simplemente los copia en una "ubicación conocida" (es decir, UNC share en la máquina de compilación)

Para las aplicaciones que son "Consumers" of the " Marco "simplemente usamos el grupo de elementos" AdditionalReferencesPath "para incluir la ubicación de esa ubicación conocida.

Además, esta herramienta: http://tfsdepreplicator.codeplex.com/ puede ser útil. Esto le permitiría tener versiones automáticamente activadas para sus Proyectos de "Consumidor" siempre que se construya la solución "Marco".

Answer 3

Mi respuesta breve es que solo debe configurar un 'proyecto TFS' y simplemente organizar sus diferentes proyectos, es decirsus aplicaciones individuales, y cada biblioteca compartida, como carpetas separadas bajo ese único proyecto TFS. La alternativa es incluir compilaciones específicas (binarias) de las bibliotecas compartidas en cada aplicación individual; si lo hace, puede organizar cada aplicación en su propio proyecto TFS, aunque no puede fusionar los cambios ni ramificar esos proyectos sin utilizar el TFS. línea de comando (y algunos comandos no obvios para arrancar).

Answer 4

yo estaba tratando de determinar la misma información, esta guía en CodePlex es perfecto

http://vsarbranchingguide.codeplex.com/releases

Incluye terminología y los diferentes enfoques de flujo de trabajo de ramificación, así como hojas de trucos.