team - TFS y proyectos compartidos en múltiples soluciones.

tfs tutorial (2)

Creo que hay algunos malentendidos aquí. Primero, puede tener múltiples soluciones (tantas como desee) en un solo proyecto TFS. Además, un solo proyecto de Visual Studio puede tener cualquier cantidad de soluciones que se refieran a él.

Segundo, ¿qué versión de TFS estás usando? 2010 es diferente de 2005/08 en la forma en que maneja los proyectos TFS.

En el 2008, hay varias formas de abordar esto dependiendo de lo que quieras obtener. Puede tener varios proyectos TFS o un solo proyecto TFS.

Voy a empezar con multiples.

Configure un proyecto TFS para su código de tipo de biblioteca compartida y otros para cada proyecto regular que tenga. Como parte del proceso de desarrollo en esta biblioteca compartida, verifique los ensamblajes completados. Luego filtre esos ensamblajes en cualquier otro proyecto TFS en el que quiera usarlos. Cuando realice una actualización de características o una corrección de errores en la biblioteca compartida, simplemente fusione la rama en cualquier otro proyecto TFS en el que desee que se realicen las actualizaciones.

Esto le permite realizar cambios compartidos para una sola aplicación sin tener que presionarlos todos.

Si desea que un solo proyecto TFS contenga todo, solo agregue carpetas para cada proyecto de Visual Studio que desee. Las soluciones de estudio visual pueden referirse a proyectos fuera de su árbol base sin problemas. Ahora, al configurar cosas como las compilaciones para cada solución, asegúrese de limitar el directorio que el servidor de compilación obtiene de / watches. De esa manera, no tendrá que crear uno de sus sitios internos cuando se realizaron cambios en un sitio externo.

Nuestro equipo de .NET trabaja en proyectos para nuestra empresa que se clasifican en categorías distintas. Algunas son aplicaciones web internas, otras son aplicaciones web externas (también se enfrentan al público), también tenemos aplicaciones internas de Windows para nuestros usuarios de oficina corporativa y aplicaciones de Windows Forms para nuestras tiendas minoristas. Por supuesto, debido a que odiamos la reutilización del código, tenemos una tonelada de código que se comparte entre las diferentes aplicaciones. Actualmente estamos usando SVN como nuestro control de código fuente, y tenemos nuestro repositorio de esta manera:

Asi que..

La solución OurCompany.com en la carpeta de Internet tendría un proyecto de sitio web, y también incluiría los proyectos ErrorLoggingModule, RegularExpressionGenerator y Anti-Xss del directorio compartido.

De manera similar, nuestra solución de sitio web de UniformOrdering también incluiría cada uno de estos proyectos en la solución.

Preferimos tener una referencia de proyecto a una referencia de .dll porque, en primer lugar, si necesitamos agregar o corregir una función en el ErrorLoggingModule mientras trabajamos en el sitio web OurCompany.com, está justo ahí. Además, esto nos permite construir cada solución y ver si los cambios en el código compartido interrumpen cualquier otra aplicación. Esto debería funcionar bien en un servidor de compilación también si estoy en lo correcto.

En SVN, no hay problema con esto. SVN y Visual Studio no están vinculados entre sí como lo está el control de código fuente de TFS. Nunca supimos cómo trabajar este tipo de estructura en TFS cuando lo estábamos usando, porque en TFS, el proyecto TFS siempre estaba vinculado a una solución de Visual Studio. El repositorio de código fuente era un elemento secundario del proyecto TFS, por lo que si quisiéramos hacer esto, tuvimos que duplicar el código compartido en cada repositorio de código fuente del proyecto TFS. Como lo expresó mi compañero de trabajo, esto "rompe todas las mejores prácticas conocidas sobre la reutilización y simplicidad del código". Para nosotros fue suficiente para romper un acuerdo que cambiamos a SVN.

Ahora, sin embargo, nos enfrentamos a la solución de nuestros procesos de desarrollo, y la gestión del ciclo de vida de la aplicación de TFS está bastante cerca de lo que queremos y de cómo queremos trabajar. Nuestro único punto es el problema del código compartido.

Estamos evaluando otras soluciones comerciales y de código abierto, pero como ya estamos pagando por TFS con nuestras suscripciones a MSDN, y TFS es exactamente lo que queremos, REALMENTE nos gustaría encontrar una solución a este problema.

¿Alguien más ha enfrentado esto y ha encontrado una solución?

Si has visto un artículo o publicación en esto que puedes compartir conmigo, eso también ayudaría.

Como siempre, estoy abierto a respuestas como "Lo estás viendo todo mal, bonehead, AQUÍ ESTÁ la forma en que DEBE hacerlo.

Solo grabando esto con la esperanza de que ayude a alguien más algún día, me temo que soy demasiado tarde para responder su pregunta original;) Tenemos una situación muy similar, y su pregunta (y las respuestas posteriores) lo hizo muy fácil para nosotros para configurar TFS correctamente.

Para usar su ejemplo para explicar nuestra configuración:

Esto significa que el trabajo puede asignarse (utilizando plantillas Scrum en Sharepoint) a cualquiera de los Proyectos de Equipo (que son aplicaciones SAAS en nuestro caso) y el desarrollador puede elegir abrir cualquiera o todos los Proyectos VS para realizar el trabajo.

La mayoría de los desarrolladores senior (aquellos que están en varios productos) tienen una Solución VS (tal vez "WholeEnterprise.sln" para continuar con la analogía) que contiene TODOS los diferentes Proyectos VS y, por lo tanto, puede trabajar en cualquiera o todos ellos en cualquiera hora. También podemos asegurarnos de que los proyectos se compilen correctamente y que todas las dependencias estén actualizadas antes de realizar una actualización.

¡La estructura de esto en su sistema operativo de elección depende totalmente de usted! Algunos de nosotros hemos replicado la estructura de TFS, otros tienen una jerarquía totalmente plana ... Esto no parece hacer una diferencia al final del día.