Fusión y ramificación de código compartido entre proyectos en TFS

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

Las aplicaciones son similares pero no idénticas, por lo que una aplicación puede tener un set de características, las otras no, etc.

Quiero detener el uso compartido de código y, en su lugar, configurar las twigs (si corresponde) así que si cambio algo en la biblioteca principal de la Aplicación A necesitaré combinar los cambios con las otras twigs 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?

En respuesta a su comentario, le sugiero que lea las Feature branches en el website de CodePlex .

Escenario 4 – Sucursal por característica
En este escenario, puede crear una twig de desarrollo, realizar trabajos en esa twig y luego fusionar su trabajo nuevamente en su tree fuente principal. Usted organiza sus twigs de desarrollo en function de las características del producto. La siguiente es una vista física que muestra la bifurcación para el desarrollo de características:

Mi proyecto de equipo

  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 

Alos estamos pasando de SS a TFS en el futuro cercano.

Según lo percibo, vamos a mantener nuestro repository de SS línea y comenzar de nuevo en TFS . Nuestro marco probablemente tendrá su propio proyecto en TFS . Las unidades compartidas específicas del proyecto deberán fusionarse de vez en cuando.


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

  • Cuantos proyectos
  • Cuantos desarrolladores
  • Están los desarrolladores dedicados
  • ¿Necesita reparaciones simultáneas?
  • ¿Necesita packages de service?

Eche un vistazo a la guía de bifurcación de CodePlex para get toda la información que necesita para tomar una decisión informada sobre su estructura de TFS. Imprima las hojas de trucos y péguelas en su panetworking para una reference rápida.

Antes de ejecutar en su plan de sucursal, preste atención a este post de advertencia: cada twig que crea tiene un costo, así que asegúrese de get algún valor de ella. La mecánica de la bifurcación en TFS se simplifica a un solo command de bifurcación con el button derecho. Sin embargo, el costo total de la bifurcación se paga mediante la networkingucción de la velocidad del código hacia los principales conflictos de fusión, y las testings adicionales pueden ser costosas.

Supongo que ya ha investigado si realmente necesita hacer sus "copys" de proyectos de equipo separados. 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 counts por cobrar de la empresa XYZ" como un proyecto en el sentido de Team Project.

Tengo un cliente que decidió 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 copys de la aplicación (tal vez sean clientes independientes y necesite una separación de security muy fuerte) y debe tener proyectos de equipo separados.

Dicho eso, aún así, como ha indicado, necesita compartir el código entre instancias de su aplicación. Lo primero que recomendaría encarecidamente es alejarme de compartir "Cortar y pegar". Realmente trataría de aislar el código compartido en una Solución separada y generar binarys para eso (¡quizás ya hayas hecho esto!)

Esto está cubierto en Codeplex TFS: http://tfsguide.codeplex.com/

Otro enfoque que he hecho para varios clientes es tener un proyecto de equipo que contenga el código compartido. La "compilation" crea los files binarys para el código compartido, y "Implementar" simplemente los copy en una "location conocida" (es decir, compartir UNC en la máquina de compilation)

Para las aplicaciones que son "Consumidores" del "Marco" simplemente usamos el grupo de elementos "AdditionalReferencesPath" para include la location de esa location 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".

Mi breve respuesta es que solo debe configurar un 'proyecto TFS' y simplemente organizar sus diferentes proyectos, es decir, sus aplicaciones individuales y cada biblioteca compartida, como carpetas separadas bajo ese único proyecto TFS. La alternativa es include comstackciones 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 command (y algunos commands no obvios para arrancar).

Estaba tratando de determinar la misma información, esta guía en codeplex es perfecta

http://vsarbranchingguide.codeplex.com/releases

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