variable defaultworkingdirectory buildnumber artifactstagingdirectory tfs

defaultworkingdirectory - Proyecto TFS con múltiples soluciones de Visual Studio



system defaultworkingdirectory vsts (4)

Como lo predijo:

OurCompanyLibrary sería una solución de VS.

OurCompanyLibrary.Application1 ... OurCompanyLibrary.ApplicationN sería VS Projects dentro de esa solución.

OurCompanyLibrary.ApplicationX.dlls sería una referencia en OurCompanyIntranet y OurCompanyInternet VS Solutions.

No estoy seguro de entender tu problema.

Un Proyecto de Aplicación VS en OurCompanyLibrary se podría armar por separado produciendo su propio DLL que luego podría ser referenciado en las otras dos soluciones. Si el problema es tener todas las Aplicaciones bajo un Proyecto de Equipo VS (OurCompanyLibrary) entonces la respuesta sería crear un Proyecto de Equipo VS separado para cada Aplicación - OurCompanyLibrary1 para Application1, OurCompanyLibrary2 para Application2, etc. El desarrollo de cada Aplicación es entonces totalmente autónomo y separado de los demás.

Si el problema es que desea diferentes partes de la fuente en diferentes soluciones, entonces eso se logra agregando el proyecto a una solución. Sin embargo, esto significa que todas esas soluciones tienen todo el código fuente. Tenemos algo similar donde trabajo: - Tenemos una solución que tiene 2 proyectos: nuestra capa de lógica empresarial común y nuestra capa de acceso a datos común. Cada una de nuestras otras soluciones tiene esos proyectos incluidos. Esto significa que podemos editar el código fuente de cualquier solución.

No sé si algo de esto te ayudará, ¡pero buena suerte!

Nuestro equipo está considerando usar Team Foundation Server v.11 (2012) para administrar nuestros proyectos. Actualmente hacemos nuestra gestión de proyectos en hojas de cálculo. Nuestro equipo desarrolla software solo para clientes internos y hay una gran cantidad de recursos compartidos entre proyectos. También estamos usando SVN para nuestro control de la versión del código fuente.

Tenemos soluciones para diferentes partes de nuestras aplicaciones: Biblioteca común, Bibliotecas de aplicaciones (reglas comerciales, etc.), Sitio web de Intranet, Sitio web de Internet, Formularios de Windows. Aquí es cómo se ve nuestra estructura SVN

SVN -CommonLibrary (VS Solution) -Source -CommonLibrary.Core (VS Project) -CommonLibrary.Security (VS Project) -CommonLibrary.Web (VS Project) -OurCompanyLibrary (VS Solution) -Libraries (Projects within this solution reference these) -CommonLibrary.Core.dll -CommonLibrary.Security.dll -Source -OurCompanyLibrary.Application1 (VS Project) -... -OurCompanyLibrary.ApplicationN (VS Project) -OurCompanyIntranet (VS Solution) (MVC framework) -Libraries (Projects within this solution reference these) -CommonLibrary.Core.dll -CommonLibrary.Security.dll -CommonLibrary.Web.dll -OurCompanyLibrary.Application1.dll -Source -OurCompanyIntranet.Application1 (VS Class Library Project) -... -OurCompanyIntranet.ApplicationN (VS Class Library Project) OurCompanyIntranet.UI (VS Web Project) -OurCompanyInternet (VS Solution) (MVC framework) -Libraries (Projects within this solution reference these) -CommonLibrary.Core.dll -CommonLibrary.Security.dll -CommonLibrary.Web.dll -OurCompanyLibrary.Application1.dll -Source -OurCompanyInternet.Application1 (VS Class Library Project) -... -OurCompanyInternet.ApplicationN (VS Class Library Project) -OurCompanyInternet.UI (VS Web Project)

La razón para dividir el código en múltiples soluciones se debe a que podemos reutilizar las bibliotecas de aplicaciones en diferentes situaciones (aplicaciones Intranet, aplicaciones de Internet, aplicaciones Winform). Además, las soluciones de intranet e internet contienen múltiples aplicaciones. Esta es nuestra estructura actual. No estoy seguro de que esta sea la mejor estructura organizativa, pero funciona para nosotros.

El problema con el cambio a TFS es que un proyecto de equipo no puede tener partes en múltiples soluciones VS. Por ejemplo, configuraríamos un proyecto de equipo TFS para la aplicación 1, de modo que pudiéramos tener una acumulación de productos para esa aplicación. La Aplicación1 requiere cambios en OurCompanyLibrary, OurCompanyIntranet y OurCompanyInternet para completar la aplicación pero, al usar TFS, solo habría una Solución VS para Application1.

Aquí hay un ejemplo de cómo desarrollamos una aplicación. Todas las reglas de negocio y el modelo de dominio están almacenadas en la Solución OurCompanyLibrary VS. Cuando desarrollamos una aplicación, llámenos Application1, primero comenzamos a crear el modelo de dominio y las reglas comerciales en el proyecto OurCompanyLibrary.Application1 VS en OurCompanyLibrary VS Solution. Una vez que se desarrolla el modelo de dominio, pasamos a programar el lado UI de las cosas en OurCompanyIntranet y OurCompanyInternet VS Solutions. Estas soluciones son un sitio web de estilo MVC. OurCompanyIntranet contiene un proyecto web de VS OurCompanyIntranet.UI que contiene todas las vistas (archivos .aspx), css, javasciprt, etc. OurCompanyIntranet también contiene todos los modelos y controladores separados por aplicación (OurCompanyIntranet.Application1 en este caso). Organizar esto en TFS se convierte en un problema, porque queremos un Team Project para Application1, pero esa aplicación puede abarcar múltiples soluciones y no queremos tener código duplicado en todas partes al agregar las mismas OurCompanyIntranet y OurCompanyInternet VS Solutions al control de la fuente.

¿Cómo organizarías esto en TFS? ¿Hay alguna otra manera en que deberíamos organizar nuestra estructura de código que tendría más sentido? Cualquier artículo o sitio web que nos guíe en la dirección correcta sería de gran ayuda.

En primer lugar, no use múltiples Team Project, este es un gran error que todos cometen al principio. Para el tamaño de su equipo y lo que desarrolla: un proyecto de equipo es lo que necesita.

Usas dos proyectos de equipo cuando hay dos equipos de personas completamente diferentes, trabajando en un proyecto completamente diferente, con una metodología / proceso completamente diferente.

Con un proyecto de equipo, aún puede:

  • Tener muchas ramas (relacionadas o no).
  • Tener la administración de Source Control al nivel más bajo que necesites
  • Divida su proyecto en subcategorías (funcional, técnica, lo que sea que necesite) utilizando la ruta de área (que es un árbol de nodos) del elemento de trabajo. De esta forma, puede tener una gran cartera de pedidos de productos o dedicados.
  • Informes generales sobre su proyecto completo o sobre un área específica (aún utilizando la ruta del área, pero en Reporting Services)
  • Créanme sobre eso, es la mejor manera de ir y muchas personas (incluyéndome a mí la primera vez) cometen el error de utilizar múltiples proyectos de equipo y tienen que pagar el precio a partir de entonces. Lo que necesita es una buena estructura jerárquica de control de fuente y un buen árbol de ruta de área.

Acerca de las soluciones:

Tener una solución por componente principal de su proyecto no es malo, los desarrolladores pueden trabajar en un subconjunto dedicado del proyecto, para maximizar la productividad y reducir el acoplamiento entre los componentes.

Pero aún puede tener una solución global que haga referencia a todos sus proyectos y que se utilizará cada vez que necesite realizar cambios que afecten a todo su proyecto. Tener una solución global también es una manera fácil de construir todo tu proyecto sin dolor.

El problema aquí es sobre referencias de componentes cruzados , si un componente que desarrolla (por ejemplo, Aplicación1) necesita otro componente que desarrolle (por ejemplo, OurCompanyLibrary), entonces crea una dependencia entre ambos y Application1 debe hacer referencia a "ensamblados construidos" de OurCompanyLibrary.

Lo que implica ya sea:

  1. Debe crear una ubicación en algún lugar de su control de origen para almacenar los ensamblados construidos de todos los componentes a los que otros harán referencia. Mantenga un ciclo de compilación para liberar todo lo que respecta al orden correcto.

  2. Aproveche el nuevo estándar que es Nuget y configure un servidor Nuget interno (muy fácil de hacer) y cree sus propios paquetes Nuget para los componentes a los que otros harán referencia.

  3. La forma más fácil de hacerlo es incluir todas las dependencias desarrolladas internamente en la solución para asegurarse de que estén compiladas cuando sea necesario. Es fácil de hacer, pero su proyecto Application1 incluirá la mayoría de sus proyectos VS. No digo que sea una buena o mala manera de ir, es su decisión. En algún momento, la manera fácil es la mejor.

Cada forma tiene sus propios pros / contras, y solo tú puedes decidir cuál es la mejor opción.

Si desea tener un informe centralizado para toda la base de código, debe explorar la posibilidad de utilizar un TeamProject para alojar todo.
Para luego distinguir entre los diferentes componentes / partes, puede emplear áreas separadas dentro de este TeamProject.
Mira este artículo muy interesante, especialmente la sección Pros / Contras.