Con la integración continua en .NET, ¿es aceptable hacer referencia a archivos DLL de ensamblajes que cambian raramente?

7

Mi compañía está buscando implementar una solución de CI muy pronto, y me preocupa una cosa en particular ... estamos ampliando la escala, lo que significa que nuestras soluciones están creciendo con más proyectos. Una cosa que quería analizar es dividir los proyectos raramente modificados en un proyecto separado, y luego hacer que otros proyectos simplemente hagan referencia a la DLL compilada, en lugar de incluir los proyectos en sus soluciones.

Por ejemplo ...

  • / BLL / DataFramework
  • / BLL / OrmFramework
  • / BLL / OrmDataAdapter
  • / BLL / ...
  • / WebUI / MyWebSite

Los proyectos de datos y ORM rara vez se cambiarían, pero si no se hace referencia a ellos, los DLL aumentarán enormemente todas las soluciones.

En su lugar, me gustaría excluirlos del proyecto y hacer que se construyan en una carpeta de Bibliotecas (o algo similar), para que:

  • / BLL / ...
  • / Bibliotecas
  • / WebUI / MyWebsite

Donde están los ensamblados de ORM y de datos .DLLs en la carpeta de Bibliotecas.

Entonces la pregunta es ...

¿Hay alguna razón para que esto no funcione con la integración continua?

¿Podría tener una solución con estas clases que rara vez se actualizan y que se construirán en la carpeta de la biblioteca durante el CI, primero, y luego las otras soluciones?

Editar: Para que quede claro ... queremos mantener estos proyectos en el ciclo de CI, pero no hacer referencia directa a sus proyectos en todas las soluciones.

    
pregunta smdrager 17.04.2012 - 22:07

4 respuestas

2

Esto funcionaría. Hago algo similar porque tratamos esos proyectos raramente cambiados como Core Framework / Architecture dlls y existen en su propia solución. Las dll se publican en una ubicación de referencia y las otras soluciones hacen referencia a estas dll en esta ubicación según sea necesario.

Aunque rara vez se encuentra un error o se identifica un nuevo requisito, se programa un cambio para estos proyectos de Marco / Arquitectura y se crean, se prueban las unidades y se comprueban las integraciones de aquellos proyectos que los usan.

Una vez que se han completado las pruebas, se envían a la ubicación de referencia y otros proyectos las recogen en su siguiente compilación.

Todos los proyectos que no pertenecen a Framework / Architecture están en un ciclo de CI y nunca hemos tenido un problema con este enfoque.

Otra ventaja de este enfoque es que tiene una base de código única para estos proyectos de Framework / Architecture que facilita el control del acceso si tiene alguna IP y también para garantizar que todas las versiones de la aplicación que las necesitan se estén ejecutando en el misma versión.

    
respondido por el armitage 17.04.2012 - 22:26
1

No hay ninguna razón para que los ensamblados .NET referenciados no funcionen. Siempre que incluya correctamente los ensamblados .NET a los que se hace referencia en su sistema de control de origen, su servidor de integración continua no debería tener problemas en usarlos para construir sus soluciones de Visual Studio y proyectos subyacentes.

    
respondido por el Bernard 17.04.2012 - 22:29
0

Sí, esto funcionará.

¿Pero realmente quieres que tus repositorios se llenen con ensamblajes, que son mucho más grandes que los archivos de origen? ¿Por qué no simplemente construirlos? Mientras no uses Rebuild o cambies ninguno de los archivos de origen, será relativamente rápido ya que el compilador descubrirá que nada ha cambiado desde tu última compilación.

Si está utilizando VS10 o VS11, hay una opción más para compilar esas bibliotecas en los paquetes NuGet y las implementan en un repositorio local, lo que le permite un control total sobre las versiones. Este es el mejor de todos los mundos.

    
respondido por el pdr 17.04.2012 - 22:33
0

Funcionaría, y funciona (donde Yo trabajo :)).

Al usar servidores de compilación como Jenkins / Hudson u otro software similar, es posible configurar activadores de compilación para trabajos (por ejemplo, otras compilaciones).

Puede configurarlo de manera que cualquier cambio en el proyecto X active una compilación para X, así como compilaciones para Y, Z, ...

Para obtener más información, puede ir a página de inicio de Jenkin .

    
respondido por el Yam Marcovic 17.04.2012 - 22:33

Lea otras preguntas en las etiquetas