Cómo versionar los resources que se comparten en los proyectos

Usamos Team Foundation Server y tenemos numerosos proyectos de aplicaciones web ASP.NET. Cada una de las aplicaciones web utiliza un sistema de administración de contenido personalizado que hemos desarrollado internamente. El CMS es en sí mismo, una aplicación web ASP.NET.

Cuando se implementa, el CMS reside en un subdirectory, como "/ Admin". El CMS está compuesto por files .aspx y ascx, y los ensamblajes correspondientes están, por supuesto, ubicados en el contenedor.

En la actualidad, los files CMS existen por separado para cada aplicación web en control de fuente. En otras palabras, existe una carpeta "Admin" en cada aplicación web que depende del CMS. Esto plantea obvios desafíos ya que las actualizaciones del CMS se deben distribuir a cada sitio dependiente. Mi trabajo es automatizar / simplificar el process.

Actualmente no realizamos comstackciones automatizadas. Tengo un conocimiento limitado de la ramificación de control de fuente en TFS y no estoy seguro de que sea aplicable en este escenario. ¿Cuál es la mejor manera de garantizar que los proyectos dependientes reciban los últimos ensamblajes y marcas del proyecto CMS? Gracias por adelantado.

Parece que el # 2 (de 'bambú') es la solución que estoy buscando. Dado que el código compartido ya reside en cada proyecto individual, ¿puede describir brevemente el process que seguiré para "ramificar / compartir" el CMS? Además, vale la pena señalar que no quiero que los files .cs se propaguen a los proyectos dependientes, solo el marcado y los ensamblajes. ¿Esto cambia la estrategia? ¿Debería crear primero un evento de compilation en el proyecto compartido para copyr los files requeridos en una carpeta "Versión" y luego ramificar la carpeta de Lanzamiento?

Hay algunas maneras populares de manejar este escenario.

  1. Asigne el proyecto TFS para las cosas compartidas a cada espacio de trabajo de las aplicaciones y luego incluya el proyecto compartido en cada solución de aplicaciones. Utilice este método si desea que todos los equipos / aplicaciones obtengan los cambios compartidos de inmediato cuando comstackn, ya que también recibirán lo último compartido.

  2. Succionar / Compartir las cosas compartidas en cada tree de control de fuente de las aplicaciones. Esto es fácil de hacer en TFS. Esto es realmente bueno si cada equipo / aplicación desea controlar cuándo obtienen lo último compartido. Esto mantiene a los equipos en condiciones de hacer lo suyo hasta que estén listos para integrar las cosas compartidas.

Generalmente siempre prefiero el # 2. Pero realmente depende de los detalles de cómo necesita / desea trabajar.

No estoy seguro acerca de TFS, pero en la mayoría de los sistemas de control de origen, puede compartir código en varias ubicaciones. Los cambios en cualquier copy compartida se reflejan en todos. En el nivel de Visual Studio, aparecerán como piezas de código independientes.

Cada una de sus aplicaciones web (soluciones) contiene un proyecto que está compuesto en su totalidad por el código compartido. Normalmente, el código fuente se comparte y se convierte en parte del process de compilation. Podría compartir la DLL resultante, pero la mayoría de las personas no obtienen files DLL de control.

Si no tiene la fuente de las partes compartidas, es probable que la installation del código en el GAC se convierta en su única opción para crear una pieza compartida.

Tenemos una biblioteca compartida que se utiliza con varios de nuestros proyectos. Luego agregamos una reference a la biblioteca compartida, no el proyecto real …

Luego debe agregar la ruta referenceda al xml de compilation, para que su server TFS sepa dónde está ubicado el file .dll. Cada vez que se realiza una nueva construcción para el proyecto, copy la versión más reciente de compartida en el contenedor para el proyecto.

Todos nuestros proyectos, incluido Shanetworking, tienen 4 sucursales: Desarrollo, Integración, Puesta en escena y Producción. Entonces, cuando necesitamos hacer cambios en nuestra biblioteca Compartida, lo hacemos en su twig Desarrollo porque está aislada. Una vez que estamos contentos, fusionamos nuestros cambios en integración. Construimos una integración compartida, y luego creamos los proyectos que se vean afectados por el cambio. Esto es cuando comenzamos a probar las otras aplicaciones para ver si nuestros cambios han causado algún error. Asi que…

  1. Un lugar para hacer cambios en la biblioteca compartida
  2. Fusión en una sola sucursal, no múltiples sucursales en cada proyecto.
  3. El uso de Shanetworking es tan fácil como agregar una reference
  4. Un solo proyecto y una versión de Shanetworking se pueden pasar de Desarrollo a Producción sin afectar a ninguno de los otros proyectos. La versión .dll de Shanetworking se copy a la carpeta bin del proyecto. Una vez que se realizan los cambios en otro proyecto, obtendrá la versión más reciente cuando se pase por sus twigs.