Una y otra vez me encuentro con equipos de desarrollo trabajando con tecnología .Net que guardan .dlls (librerías/packages) en repositorios de código fuente. Esto fue una práctica común en una época (lejana) y que yo mismo utilicé en algún momento. Pero desde la aparición de NuGet la gestión de librerías en en mundo .Net tomó un camino distinto.

Cuando uno tiene una dependencia de una librería a nivel binario, simplemente declara la dependencia en un archivo package.json y la herramienta NuGet se encarga de buscarlo en el repositorio binario y descargarlo. NuGet por default busca las librerías/paquetes en https://www.nuget.org/. Sin embargo hay dos casos donde seguramente no encontremos la librería en este repositorio:

• Si estamos usando librerías de terceros, puede que por algún motivo esos terceros no hayan publicado el correspondiente paquete en nuget.org y dependiendo del tipo de licencia del paquete puede que no tengamos derecho a publicarlo nosotros mismos en un repositorio abierto.
• Por otro lado es muy común hoy en día con el auge de los microservicios que uno tenga librerías propias que utilice en diversos proyectos de la organización y a menos que nuestros proyectos sean open source, es poco probable que querramos publicar esas librerías en nuget.org

Entonces, para estos dos casos la estrategia a seguir es utilizar un repositorio privado de binarios ya sea on-prem (instalando por ejemplo un Nexus) o utilizando algún servicio en la nube (como por ejemplo myget).

Si ponemos todo esto en contexto, una arquitectura de desarrollo de referencia podría incluir:

• Un servidor de repositorios de código fuente, por ejemplo alguna implementación de Git como GitHub, GitLab o BitBucket.
• Un servidor de CI/CD como Jenkins o TeamCity
• Un servidor de repositorios de binarios NuGet como Nexus, MyGet o Artifactory