version control - usar - Estructura TFS-¿Proyectos múltiples o proyecto único?
visual studio code tfs (6)
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.
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 solo sitio / sistema de proyecto, cada proyecto tiene una subcarpeta fuera de la raíz.
Con este tipo de configuración, nos preocupa perder mucha de la funcionalidad que TFS proporciona (seguimiento de fallas, informes de rutina, almacenamiento de documentos, etc.) porque todos los proyectos estarán en el mismo espacio de portal / proyecto y será difícil separar los boletos / artículos individuales del proyecto.
¿Alguien tiene experiencia con esto? ¿Cuál fue tu solución? ¿Te quedaste con TFS?
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 forman parte de su subcarpeta.
Dependiendo de la cantidad de fuente que administre, esto puede aumentar considerablemente sus tiempos de compilación.
El enfoque que adopté fue 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. Si bien las asignaciones del espacio de trabajo se vuelven "interesantes", permiten diferentes metodologías de diseño para diferentes proyectos y 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 para Team System ), al mismo el tiempo en que otro acaba de comenzar ...
La respuesta a esta pregunta requiere una planificación de su parte: cómo piensa usar TFS y cuál de esas capacidades tiene limitaciones inherentes al producto. Resumiría mi consejo como:
Necesitará [al menos] 1 proyecto de equipo por plantilla de proceso. Es decir, si dos equipos quieren adoptar / personalizar diferentes procesos, necesitarán separarse.
Una vez que se cumple la condición n. ° 1, es probable que no necesite tantos proyectos de equipo por separado como crea. El 90% de las características y configuraciones de TFS son de naturaleza jerárquica, lo que le permite abarcarlas de manera amplia o restringida según lo requiera cada uno de sus proyectos.
Para detalles completos, ver:
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.
Me doy cuenta de que este artículo es antiguo, pero TFS 2010 ahora es compatible con una función maravillosa llamada Team Project Collections, que es simplemente otro nivel de indirección o agrupamiento en la parte superior de los 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!
Great Link hablando más sobre Collections
http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
No soy un usuario de Sharepoint pero escucho su concepto muy similar a las colecciones de Sharepoint :)