Biblioteca de classs referenceda por varios sitios web + ramificación de control de versiones

Considera lo siguiente –

Tengo una solución que consiste en proyectos múltiples:

  • DAL (Biblioteca de classs)
  • BusinessLogic (Biblioteca de classs)
  • Sitio web1 (Aplicación web)
  • Website2 (Aplicación web)

Tanto Website1 como Website2 comparten una reference a BusinessLogic, que a su vez hace reference al DAL.

Dado que estos son solo sitios web, no es necesario que realice un seguimiento de varias versiones, como tal, pero me gusta tener las siguientes twigs:

  • El maletero
  • Producción

Trunk es donde realizo todo mi trabajo de desarrollo y, una vez que todo está probado y listo para funcionar, me fusiono de Trunk to Production cuando un website se implementa realmente en los serveres de producción. Esto me permite archivar mi trabajo actual, verificar la twig de producción y resolver los principales errores que se encontraron después de la implementación e implementar inmediatamente la solución.

Mi problema es que, usando este enfoque, lo que vive en la twig de Producción no siempre es correcto. Digamos que realizo una actualización de BusinessLogic que es utilizada por Website1. Pasa las testings y se implementa. Si fusiono todos los proyectos en la twig Producción, entonces está mal porque Website2 no se implementó en producción en ese momento.

O bien, podría fusionar solo los proyectos relevantes para Producción. Entonces, en este caso, fusionaría Website1, BusinessLogic y DAL. Esto todavía está mal, sin embargo. Si tuviera que verificar la twig de producción para hacer el trabajo en el website2, tendría una versión más nueva de BusinessLogic y DAL que realmente existe en nuestros serveres de producción.

¿Cuál es el enfoque correcto aquí?

Puede haber muchas forms correctas, y siempre depende de lo que sea correcto para usted. Cada path tendría pros y contras, por supuesto.

Si desea dependencies de nivel de origen, cree varias twigs de producción por sitio, cada una incluye externa:

  • / Sitio1 / Producción
    • contenido del sitio
    • BusinessLogic [externo] -> / BusinessLogic / v1Branch
  • / Site2 / Producción
    • contenido del sitio
    • BusinessLogic [externo] -> / BusinessLogic / v1Branch
  • / BusinessLogic / v1Branch (de DevBranch)
  • / BusinessLogic / DevBranch

Así es como lleva a cabo la actualización de la versión:

  • Realice un cambio en BusinessLogic/DevBranch , BusinessLogic/DevBranch .
  • Branch it como BusinessLogic/v2Branch
  • Actualice Site2/Production 's external para que apunte a BusinessLogic/v2Branch
  • Build site2, testing e implementa.

Así que tendrás –

  • / Sitio1 / Producción
    • contenido del sitio
    • BusinessLogic [externo] -> / BusinessLogic / v1Branch
  • / Site2 / Producción
    • contenido del sitio
    • BusinessLogic [externo] -> / BusinessLogic / v2Branch
  • / BusinessLogic / v1Branch (de DevBranch)
  • / BusinessLogic / v2Branch (de DevBranch)
  • / BusinessLogic / DevBranch

Esto requiere un cierto nivel de cultura de desarrollo y cierta cantidad de administración de svn.

También puedes poner binarys en tales twigs svn, que es más o less el mismo esquema. En general, dicho enfoque se denomina twigs de proveedores .


Si prefiere dependencies binarias fuera del control de origen, puede utilizar el repository nuget local. Funciona igual que el oficial: usted crea una nueva versión, la publica en nuget y luego la deriva del sitio, la compilation y la implementación. Esto requiere un esfuerzo adicional de installation y mantenimiento, y es más apropiado para proyectos más grandes.

No debe usar un model de intercambio de código o promoción de código. Reduce la calidad y fuerza el retrabajo. En su lugar, busque crear una cartera de lanzamientos en la que cree un package para sus capas Business y Dal y consum las que están empaquetadas en las aplicaciones web.

El mejor enfoque para esto es usar un server de compilation y crear un package NuGet para su DAL consumido por Business Layer. Esto a su vez está empaquetado como un package NuGet que sus sitios web pueden consumir.

Su flujo de trabajo para get un cambio en la capa de negocios en su website es entonces:

  1. La solución Open Business Layer y make fix
  2. Registrarse y activar la creación de CI
  3. CI build crea y publica el package NuGet
  4. Abra la solución del website y actualice el package NuGet

Limpio y simple. No ramificar es una buena ramificación.