TFS y proyectos compartidos en soluciones múltiples

Question

Nuestro equipo .NET trabaja en proyectos para nuestra empresa que se dividen en distintas categorías. Algunas son aplicaciones web internas, otras son aplicaciones web externas (públicas), también tenemos aplicaciones internas de Windows para nuestros usuarios de oficinas corporativas y aplicaciones de Windows Forms para nuestras ubicaciones minoristas (tiendas). Por supuesto, porque odiamos la reutilización de código, tenemos un montón 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 distribuido así:

- = folder, | = Visual Studio Solution 
-SVN 
    - Internet 
     | Ourcompany.com 
     | Oursecondcompany.com 
    - Intranet 
     | UniformOrdering website 
     | MessageCenter website 
    - Shared 
     | ErrorLoggingModule 
     | RegularExpressionGenerator 
     | Anti-Xss 
     | OrgChartModule etc... 

Así que ..

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

Del mismo modo, nuestra solución de sitio web UniformOrdering tendría cada uno de estos proyectos incluidos en la solución también.

Preferimos tener una referencia de proyecto a una referencia .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á ahí. Además, esto nos permite construir cada solución y ver si los cambios en el código compartido rompen otras aplicaciones. Esto también debería funcionar bien en un servidor de compilación si estoy en lo correcto.

En SVN, no hay ningún problema con esto. SVN y Visual Studio no están vinculados de la misma manera que el control de origen de TFS. Nunca supimos cómo trabajar este tipo de estructura en TFS cuando lo usábamos, porque en TFS, el proyecto TFS siempre estuvo 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 queríamos hacerlo, teníamos que duplicar el código compartido en el repositorio de código fuente de cada 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". Fue suficiente para nosotros romper el trato al cambiar a SVN.

Ahora, sin embargo, nos enfrentamos a una verdadera reparación de nuestros procesos de desarrollo, y la Administración del ciclo de vida de las aplicaciones de TFS es bastante similar a lo que queremos y cómo queremos trabajar. Nuestro único problema 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 forma de evitarlo. problema.

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

Si has visto un artículo o una publicación sobre esto que puedes compartir conmigo, también sería útil.

Como siempre, estoy abierto a respuestas como "Usted está mirando todo mal, cabeza hueca, aquí está la forma en que debe hacerse.

Answer 1

Creo que hay algunos malentendidos aquí. En primer lugar, usted puede tener varias soluciones (tantas como desee) en un único proyecto TFS. Además, un único proyecto de Visual Studio puede tener cualquier cantidad de soluciones que se refieran a él.

En segundo lugar, ¿qué versión de TFS está utilizando? 2010 es diferente de 2005/08 en cómo maneja los proyectos TFS.

En 2008, hay varias maneras de abordar esto dependiendo de lo que desea sal de eso. Puede tener múltiples proyectos TFS o un solo proyecto TFS.

Comenzaré con múltiples.

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 ensamblados completados. Luego, asigne esos ensamblados a cualquier otro proyecto TFS en el que desee usarlos. Cuando realiza una actualización de funciones o correcciones de errores en la biblioteca compartida, simplemente combine la rama en cualquier otro proyecto TFS al que desee que entren las actualizaciones.

Esto le permite realizar cambios compartidos para una aplicación única 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 Visual Studio pueden referirse a proyectos fuera de su árbol base sin problemas. Ahora, al configurar cosas como Builds para cada solución, asegúrese de limitar el directorio desde el que el servidor de compilación extrae/mira. De esta forma, no lo hace creando uno de sus sitios internos cuando se realizaron cambios en un sitio externo.

Answer 2

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

Para utilizar su ejemplo para explicar nuestra configuración:

# = Project Collection, > = Team Project, | = VS project 
# SVN 
    > Internet 
     | OurCompany 
     | OurCompany2 
    > Intranet 
     | UniformOrdering 
     | MessageCentre 
    > Shared 
     | ErrorLogging 
     | RegularExpression 

Esto significa que el trabajo puede ser asignado (el uso de plantillas de Scrum en Sharepoint) a cualquiera de los proyectos de equipo (que son aplicaciones SAAS en nuestro caso) y el desarrollador puede optar por abrir uno o todos los proyectos de VS para realizar el trabajo.

La mayoría de los desarrolladores senior (aquellos que están en múltiples productos) tienen una VS Solution (quizás "WholeEnterprise.sln" para continuar la analogía) que contiene TODOS los diferentes proyectos VS y por lo tanto puede trabajar en cualquiera/todos ellos en cualquier momento. También podemos asegurarnos de que los proyectos se creen correctamente y todas las dependencias estén actualizadas antes de impulsar una actualización.

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