Cuando abordamos un proyecto de desarrollo de software, casi invariablemente, vamos a tener referencias externas. Estas referencias pueden ser de otras compañías, como puedan ser componentes tipo Entity Framework, Unity, Log4Net, ELMAH, etc. estas referencias, en el caso de Visual Studio, lo tenemos resuelto mediante NuGet, que casi seguro que todos conocéis, y que facilita la vida a la hora de compilaciones automatizadas, despliegues, y montar los entornos de desarrollo.
Sin embargo, cuando hablamos de dependencias de nuestros propios componentes la cosa a veces se complica más, ya que son componentes que frencuentemente tienen unos ciclos de despliegue más cortos, teniendo nuevas versiones más rápido. Así mismo nos tenemos que asegurar, que al obtener las dependencias durante las compilaciones y despliegues, sea las versiones correctas.
A pesar de que en algunos entornos nos encontramos con soluciones como parpetas compartidas de referencias, ramas de control de código fuente con las dependencias, si bien en un modo básico esto puede llegar a funcionar, siempre estamos añadiendo un trabajo extra a la hora de montar los entornos, y lo que es más importante, a la hora de asegurar que durante el desarrollo, compilación y despliegue, estemos usando la versión correcta.
Para solucionar estos problemas, del modo más eficiente y automático posible, os propongo dos distintas aproximaciones:
AIT Dependency Manager
Esta extensión de Visual Studio, desarrollada por los MVP de Visual Studio Neno Loje y Sven Huberth, nos permite crear ficheros Xml de configuración de dependencias, que nos permite traer las dependencias de: control de código fuente, resultados de una Team Build, carpetas compartidas.
Los ficheros de configuración son de este estilo:
<Dependencies>
<Dependency Type="BinaryDependency">
<Provider Type = "BuildResult">
<Settings Type="BuildResultSettings">
<Setting Name="TeamProjectName" Value="DemoScrum" />
<Setting Name="BuildDefinition" Value="SolutionRefs" />
<Setting Name="BuildNumber" Value="SolutionRefs_20120305.2" />
<Setting Name="RelativeOutputPath" Value=".Lib"/>
</Settings>
</Provider>
</Dependency>
</Dependencies>
También, mediante otro componente desarrollado por ellos, nos permite usar unas plantillas de Team Build personalizadas, para poder interpretar y resolver las dependencias en las compilaciones automatizadas.
La verdad es que el componente funciona bastante bien (aún tiene algunos defectos), pero la principal dificultad que he encontrado es el desplegar el componente en todas las máquinas, configurar las definiciones de build con ese componente adicional, en definitiva, una configuración inicial bastante manual, y tediosa. ¿Por qué investigué esta opción? inicialmente por hacer de beta tester
Por ello, mi recomendación va más por la siguiente opción:
Servidor propio de NuGet
Al igual que podemos usar dependencias de terceros desde NuGet, también podemos montar nuestro propio servidor NuGet, y la verdad es que me ha, hasta sorprendido, la “sencillez” de montarlo.
Todo lo que tenemos que hacer es crearnos en Visual Studio un proyecto ASP.NET vacío, e instalar, desde el propio NuGet el paquete NuGet.Server, esto configurará el sitio web con todo lo necesario para albergar nuestro servidor propio de NuGet, creando, dentro de el, un directorio “Packages” por defecto, que será donde dejaremos nuestros paquetes propios *.nupkg. Este sitio web lo desplegaremos a cualquier servidor de IIS coroporativo que tengamos.
El siguiente paso es, en nuestros Visual Studio, configurar nuestro servidor NuGet como una fuente de confianza, esto lo hacemos desde Tools / Options en Visual Studio, si, aquí también tenemos configuración, pero de un modo bastante más estándar e integrado.
A partir de aquí, cuando vayamos a agregar nuevas dependencias, via NuGet, podremos explorar las que hayamos agregado a nuestro servidor corporativo, ya sean nuestras o de terceros, creando de este modo el servidor de dependencias estándar.
Por supuesto, tenemos un modo de publicar nuestros paquetes como dependencias directamente desde Team Build, para esto os recomiendo este componente: http://nugetter.codeplex.com/, y por supuesto revisad la documentación de como crear un paquete NuGet y todo lo que nos permite como ejecución de PowerShell de configuración de proyectos (algo que no tenemos con la primera opción).
En definitiva, también tiene algo de trabajo de configuración, pero de un modo mucho más estándar dentro del propio Visual Studio, basándonos en algo que casi todo desarrollador de Visual Studio conoce como es NuGet.
Conclusión
Ya no tenéis excusa para empezar a tener un buen ciclo de vida de vuestras dependencias, mi recomendación como ya os he dicho es la creación de vuestro propio servidor de NuGet, pero si esto no es posible, la primera opción os puede ayudar bastante.
Así que ya sabéis, si queréis gestionar vuestras dependencias entre proyectos, aquí tenéis una base, que seguro os iremos contando en próximos artículos más detalladamente.
Amigo, lo de Neno mola, pero el NuGet como server local es la mejor opción siempre 😀
IMHO 😉
Saludos
Totalmente de acuerdo Bruno 🙂
Interesante tu post =). Gracias por el aporte.
En retribución te recomiendo le des un vistazo a TeamCity de JetBrains.
Un saludo.