Pregunta Organizar el código fuente en TFS 2010


Acabamos de poner en marcha TFS 2010. Migraremos nuestra fuente a TFS, pero tengo una pregunta sobre cómo organizar el código.

TFS 2010 tiene un nuevo concepto de colecciones de proyectos, así que he decidido que diferentes grupos dentro de nuestra organización obtendrán su propio grupo. Mi equipo desarrolla muchas aplicaciones web diferentes y tenemos varios componentes compartidos. También usamos algunos componentes de terceros (como telerik).

Claramente, cada aplicación web es su propio proyecto, pero ¿dónde pongo los componentes compartidos? ¿Debería cada componente estar en su propio proyecto con construcciones separadas y elementos de trabajo?

¿Existe una mejor práctica o forma recomendada de hacer esto específico para TFS 2010?


19
2018-04-21 16:20


origen


Respuestas:


La mejor práctica para esto es tener todo lo que necesita para construir una solución en su carpeta Main / Trunk. Usamos el siguiente formato:

 "Project 1"
   "DEV" (Folder)
      "Feature 1" (Branch)
      "Main" (Root branch)
   "Release" (Folder)
      "Release 1" (Branch)
   "RTM" (Folder)
      "Release 1.0" (Branch)
      "Release 1.1" (Branch)

Esto mantiene todas sus ramas en el mismo nivel para que no tenga ninguna duda sobre qué es una rama y cuál es una carpeta.

Esa es la estructura de su proyecto de equipo, pero ¿qué pasa con la estructura de la carpeta real en cada una de las ramas?

Main (Root branch)
  "Builds" (Folder that contains all of the MSBuild and Workflows for building)
  "Documents" (Folder that contains version specific documents)
  "Deployment" (Folder that contains config required for deployment | We use TFS Deployer from Codeplex)
  "Setup" (Folder contains all of the setup resources)
  "[Company].[Namespace].*" (Folders that contains a project)
  "Tools" ( Folder for all your nuts and bolts)
     "Toolname" (Folder for a specific tool or reference library)

La idea es que el equipo elija si usar una nueva versión de un producto externo o una biblioteca de referencia. El hecho de que un equipo pueda actualizar a una nueva versión de NUnit no significa que otro equipo elija no hacerlo, ya que son semanas de trabajo.

Por supuesto, tenga un proyecto central de "Herramientas" que siempre actualice con la última versión y su equipo realice el trabajo desde allí, pero no tenga dependencias externas. Hace una pesadilla hacer compilaciones automatizadas y hace que los desarrolladores se actualicen incluso si no es un buen momento. Además de eso, asegúrese de tratar cualquier dependencia externa como una herramienta incluso si proviene de otro equipo interno.

Referencias  TFS Deployer


13
2018-05-06 15:53



Tengo dos respuestas: qué hacemos y qué sugiero para ti.

Para nosotros, tenemos un conjunto de aplicaciones web que tienen MUCHOS componentes compartidos. Como tal, aunque se trata de aproximadamente 50 ensamblajes diferentes (proyectos VS) y 5-10 soluciones (dependiendo de cómo se mire), existe una superposición muy significativa entre todos ellos, lo que significa que queremos utilizar la fusión TFS por desarrollador en vez de que ramificar y fusionar esos recursos superpuestos. Como tal, en realidad guardamos todo esto en un solo proyecto TFS. Así es como tenemos nuestra configuración (los nombres han cambiado para que tengan sentido):

"Official Projects" (Collection)
    "Production Applications" (Project)
    "Technology Proof of Concepts" (Project)
    "Reference Projects" (Project) - this is a simple solution/projects using our architecture to make our architecture easier to understand as people join our team. Other reference apps will go here in the future.
    "TFS Configuration" (Project)
"Playground" (Collection)
    "John Doe" (Project)
    "Jane Doe" (Project)
    "Security Team" (Project)
    "Production Test" (Project)

En nuestra configuración, tenemos un lugar para el código de empresa oficial. Además, tenemos un área para que las personas se vayan de la risa sin tener miedo de arruinar nada mientras se pueden aprovechar los diversos beneficios relacionados con TFS.

Sin embargo, en su escenario, si estoy leyendo correctamente las líneas, sugeriría algo diferente. Mis suposiciones:

  1. Cada proyecto, aparte de tener algunas asambleas comunes (estoy pensando en el registro, la seguridad y otros ensambles de utilidades que se comparten en toda la empresa), son proyectos no relacionados.
  2. Los ensamblados compartidos / comunes no se modifican regularmente, por lo que puede utilizar referencias de DLL en lugar de referencias de proyectos, donde siempre está utilizando la última versión del código actualizada al minuto.
  3. (Asunción basada en TFS ya que todavía estoy aprendiendo) Puede ramificarse en Proyectos de la misma Colección pero no puede ramificarse en Colecciones.
  4. Además de los conjuntos compartidos mencionados anteriormente, no se comparte ningún otro código entre los equipos.

Entonces con estas suposiciones, iría con algo como esto:

"Common Resources" (Collection)
    "Source" (Project) - everything goes here such as logging assemblies, security assemblies, etc.
    "Version 1" (Project) - Branch as you "rev" your common assemblies so people have access to older versions.
    "Version 2" (Project)
    "Version 3" (Project"
    etc.
"Team 1" (Collection)
    "Project 1"
    "Project 2"
    "Project 3"
    "Project 4"
    "Project 5"
"Team 2" (Collection)
    "Project 1"
    "Project 2"
    "Project 3"
"Team 3" (Collection)
    "Project 1"
    "Project 2"
etc.

Haciéndolo de esta manera, se refiere a los ensamblajes comunes a través de referencias de DLL. Usted, como equipo o desarrollador de un proyecto específico, puede decidir cuándo comienza a usar una versión más nueva de un ensamblaje común. Para hacerlo, simplemente obtenga la última versión de la rama de esa versión y luego agregue una referencia a ella. Si mi suposición n. ° 3 es incorrecta, entonces con suerte puedes hacer algo mejor que eso. De lo contrario, cada proyecto tiene su propio espacio (que puede contener más de una solución VS / proyecto, lo que es una buena idea) y su equipo tiene su propia colección para mantenerse separado de los otros equipos.

Solo mi $ 0.02 vale ...


5
2018-04-23 15:51



Hemos adoptado un enfoque simple para los componentes de terceros y hemos creado un proyecto separado para ellos. Entonces, cuando otro proyecto necesita hacer referencia al ensamblado o DLL, ramificamos la carpeta en la que está el ensamblado, en una carpeta "ThirdParty" en el proyecto de destino.

Esto también nos brinda un mecanismo para implementar actualizaciones de ensamblados de terceros de forma gradual mediante una fusión directa desde la carpeta base.


4
2018-04-19 15:24



Use Workspaces, no solo funcionan en Team Collections, sino que funcionan con la mayoría de las técnicas de control de versiones.


2
2017-08-01 23:08