Estructura TFS: ¿proyectos múltiples o proyecto único?

Question

Nuestra pequeña tienda de desarrollo está buscando migrar nuestros proyectos de VSS a TFS, y estamos evaluando TFS frente a otros (aún no hemos apretado el gatillo). La naturaleza de nuestra tienda de software es tal que tenemos más de 100 proyectos en VSS que van desde pequeños proyectos de una sola persona hasta aplicaciones masivas para toda la empresa.

Estamos tratando de determinar cómo estructurar nuestros proyectos en la transición y, en su mayor parte, hemos decidido poner todo en un sitio/sistema de proyecto con cada proyecto teniendo una subcarpeta fuera de la raíz.

Con este tipo de configuración, nos preocupa perder mucha de la funcionalidad que proporciona TFS (seguimiento de errores, scrum burndowns, informes, almacenamiento de documentos, etc.) porque todos los proyectos estarán en el mismo portal/espacio del proyecto y será difícil separar las entradas/artículos del proyecto individual.

¿Alguien tiene experiencia con esto? ¿Cuál fue tu solución? ¿Te quedaste con TFS?

Answer 1

La respuesta a esta pregunta requiere una cierta planificación de su parte: cómo piensa usar TFS, y cuál de esas capacidades tiene limitaciones inherentes en el producto. Resumiría mi consejo como:

1. Necesitará [al menos] 1 proyecto de equipo por plantilla de proceso. Es decir, si dos equipos quieren adoptar/personalizar diferentes procesos, necesitarán separarse.

2. Una vez que se cumpla la condición # 1, es probable que no necesite tantos proyectos de equipo por separado como crea. El 90% de las características de TFS & son de naturaleza jerárquica, lo que le permite abarcarlos de manera amplia o restringida según lo requiera cada uno de sus proyectos.

Para más detalles, véase:

• http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=Guidance%20for%20Structuring%20Team%20Projects
• http://blogs.msdn.com/richardb/archive/2007/05/01/tfs-team-project-whitepaper.aspx
• http://msdn2.microsoft.com/en-us/library/aa974183(vs.80).aspx

Answer 2

Es cierto que para obtener todos los beneficios de TFS, es mejor utilizar proyectos separados, pero esos beneficios deben sopesarse con los gastos administrativos asociados con la administración de muchos proyectos. Hace años, utilicé Visual Source Safe ... Después de dejar Microsoft, cambié a Subversion. Después de regresar a Microsoft, estoy usando TFS y hasta ahora estoy muy contento con él.

La guía de proceso, los informes, el seguimiento de errores integrado y la integración IDE ajustada satisfacen mis necesidades perfectamente. Además, el TFS SDK permite algunos escenarios de extensibilidad interesantes.

Answer 3

He utilizado varios proveedores de SCC y hemos establecido en TFS todas las características que otros no tienen. Correlación de errores, CI y pruebas automatizadas ciertamente encabezaron la lista de beneficios.

En cuanto a si usa proyectos múltiples o no, yo diría que depende de si los proyectos comparten algún código común. Tendemos a utilizar un proyecto TFS para todos los activos de código "relacionados", por lo que si tenemos varias soluciones diferentes que hacen cosas similares y comparten una gran cantidad de código, usamos un solo proyecto TFS. Si no tienen nada en común, se convierten en proyectos separados.

Answer 4

No estoy seguro de si esto se solucionó en 2008 pero en 2005 cuando construyó un proyecto que era una subcarpeta de un proyecto raíz, MSBuild extraerá todo el árbol fuente del proyecto raíz, incluso los archivos que no son parte de tu subcarpeta

Dependiendo de la cantidad de código fuente que administre, esto puede aumentar considerablemente los tiempos de compilación.

Answer 5

El enfoque que he adoptado es tener un proyecto TFS para cada agrupación lógica de ensamblajes. Así que tenemos un proyecto marco que contiene ensamblajes comunes a todas nuestras aplicaciones, luego tenemos un proyecto separado para nuestro sistema de cotizaciones , otro para el sistema de costos y demás. Mientras que las asignaciones del espacio de trabajo se vuelven "interesantes", permite diferentes metodologías de diseño para diferentes proyectos, en diferentes escalas de tiempo, por lo que un equipo puede estar a la mitad de un sprint (la mayoría de los proyectos usan Scrum for Team System), al mismo tiempo que otro está comenzando ...

Answer 6

Soy consciente de este artículo es viejo, pero TFS 2010 ahora es compatible con una función de llamada maravillosa Team Project Collections que es simplemente otro nivel de indir ección o agrupación en la parte superior de Proyectos.

Esto hace que sea mucho más fácil crear proyectos de equipo sin obstruir su espacio de nombres y fomenta una mejor organización.

Gran Enlace a hablar más sobre Colecciones

http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx

que un no es un usuario de SharePoint pero escucho su concepto muy similar a las colecciones de Sharepoint :)