Cómo crear tu propio servidor nuget y desplegarlo a Azure

Desde que trabajo con .Net he usado paquetes Nuget, normalmente eran públicos, de nuget.org, a medida que he ido experimentando cambios profesionales a nuevos proyectos, comencé a utilizar paquetes privados, propios del proyecto, en orígenes nuget privados.

Esto me ha llevado a plantearme la necesidad de hacerme con mi propio servidor nuget para mis proyectos personales, siendo una herramienta fantástica para alojar todo el código que normalmente necesito reutilizar. En esta entrada voy a explicar cómo hacerlo. 

Si no estas familiarizado con el uso de Nuget, y hablando de una forma informal, se trata de una manera de crear paquetes que contengan tu código y almacenarlos en un repositorio, de forma que puedas hacer referencia a ellos cuando sea necesario instalándolos en otros proyectos o soluciones, pudiendo utilizar ese código contenido en el paquete.

Los paquetes NuGet también te van a permitir tener varias versiones de un mismo paquete y especificar cualquier dependencia entre distintos paquetes, de forma que si instalas uno que tiene dependencia con dos más, los 3 serán automáticamente referenciados. Si ya utilizas NuGet Package Manager de Visual Studio, sabrás de lo que hablo.

Dado que en esta entrada voy a explicar como disponer de tu propio servidor nuget en Azure, necesitarás una suscripción válida en Azure. Si no la tienes pero quieres experimentar con lo que te expongo en esta u otras entradas sobre DevOps que iré creando, puedes crearte una cuenta gratuita, solo tendrá 30 días de duración y un crédito limitado. No obstante existen planes muy básicos de alojamiento de servicios web que siempre podrás utilizar, aún expirando este periodo, que podrás usar para tus pruebas.

Además el despligue de tu servidor a Azure lo voy a realizar desde una perspectiva de integración continua (CI, Continuous integration), por lo que también es recomendable que dispongas de una cuenta de Visual Studio Team Services y un Visual Studio 2015 (al menos) debidamente actualizado, para poder usar GIT, desde donde voy a realizar la integración. Podrías hacerlo con TFS con versiones anteriores de Visual Studio sin problemas, vinculandolo con Visual Studio Team Services.

Teniendo tu suscripción, lo primero será crear un servicio de tipo aplicación web en el tipo de plan que desees.

Selecciona + para desde el panel de “nuevos” seleccionar web, y luego en su panel seleccionar aplicación web, y en éste último panel completar los datos de tu aplicación, entre ellos la url, tu suscripción y el tipo de plan que deseas. Si expandes el menú de planes, se te mostrarán algunos por defecto, siempre podrás darle a mostrar todos para ver todas las opciones, incluidas las gratuitas.

El vinculo entre una aplicación web y un plan de hosting no es 1-1, si ya tienes un plan, puedes vincular al mismo tu nueva aplicación web, que pasará a consumir recursos de dicho plan.

Con la parte de Azure lista, ahora ve a tu Visual Studio y crea un nuevo proyecto de tipo Aplicación web ASP.Net vacía. No olvides marcar el checkbox “Crear nuevo repositorio Git”

De esta forma ya tendrás tu solución en un repositorio llamado nugetServerTest con una rama Master, todo aún en Git local.

A continuación instala el paquete nuget “Nuget.Server” en tu proyecto, y compila para ver todo es correcto con una build exitosa.

Tras compilar, abre el web.config y verás unas líneas relativas a la seguridad de tu repositorio nuget, como las siguientes:

Establece la propiedad requireApikey a true, y establece una contraseña apiKey para que solo quien conozca la apiKey pueda subir paquetes nuget a tu servidor.

Si con este proceso completado, lanzas tu aplicación en local, deberías estar viendo algo como esto:

Pues listo, tu servidor esta operativo, es hora de desplegarlo a Azure.

En Visual Studio ve a team explorer, y selecciona la opción sincronización. Te llevará a un menú para publicar tu repositorio GIT en un Visual Studio Team Services (VSTS) o en un repositorio remoto de GIT. En este caso estoy escribiendo para realizar esta instalación con CI en VSTS, por lo que selecciona esta opción.

Se te presentarán una serie de inputs para seleccionar tu cuenta en VSTS asociada a una cuenta de correo, y podrás darle un nombre a tu repositorio.

De esta forma ya tendrás tu repositorio disponible online en tu cuenta de VSTS. Así que ahora viene la parte de CI para desplegar tus build de este repositorio directamente a tu Azure.

En primer lugar ve a la sección de Builds de tu VSTS y crea una nueva definición de build.

Selecciona build de Visual Studio

En la primera tab, sobre tareas, selecciona la primera tarea de Get Sources y selecciona tu repositorio en VSTS, además de la rama sobre la que deseas realizar la intengración continua.

En la tercera tab, sobre triggers, es donde deberás habilitar la Integración continua, y asegurarte de que dicho trigger se dispara con los cambios en el repositorio adecuado sobre la rama adecuada.

De momento salva sin más. La opción de salvar mostrará salvar y encolar una build, date cuenta que tiene el simbolito para desplegar opciones como un select o dropdown, por lo que podrás seleccionar salvar sin lanzar build. Sobre las tabs de opciones, podrás editar el nombre de la build, debes recordar este nombre para seleccionarlo luego en las releases que harán el despliegue a Azure.

Ahora ve a la sección de releases y crea una nueva release.

Selecciona la opción siguiente:

Ahora selecciona el proyecto y el nombre de la build que usaste cuando creaste la definición de build. También puedes seleccionar un CD (Continuous deployment) para que tu código se despliegue siempre que la build termine de forma satisfactoria, o podrás ponerle despliegues periódicos o manuales a la release de las diferentes builds que generes. De momento he seleccionado CD y en el futuro crearé nuevas entradas DevOps para tratar estas diferentes opciones.

Ahora tan solo deberás seleccionar tu suscripción de Azure y el App Service que creaste al comienzo de esta entrada y salvar tu release.

Ahora siempre que lances una build de tu repositorio que contiene la solución con tu servidor nuget, ya sea manualmente o por introducir cambios en la rama master, una build se iniciará, y si su contenido es exitoso, se creará una release con el contenido de dicha build y se desplegará en tu site de Azure, de forma que tu servidor estará disponible en la url que definiste para tu site de Azure, manteniendo actualizando mediante integración continua.

Las releases de VSTS permiten muchas otras opciones, como despliegues sucesivos a diferentes internos manualmente, automaticamente, previa aprobación, programados a ciertas horas o ciertos días, o siempre que el anterior entorno tenga un despliegue satisfactorio. Las opciones que ofrece para llevar a cabo prácticas DevOps son muy amplias.

Espero que te haya servido de ayuda, y que si aún no estabas introducido en la perspectiva DevOps para tus desarrollos y sus despliegues, te animes a sumergirte en ello, de forma que te garantizo que disfrutarás aún más de lo que ya lo hacías programando tus proyectos.

Un saludo.

Deja un comentario