Recientemente hice un tutorial sobre cómo usar Travis CI como herramienta para probar automáticamente el código que acabas de enviar o intentaste enviar a la rama master. Haciéndolo para ser compilado y probado y finalmente informarle el estado de ese cambio.

Pero podemos seguir haciéndolo mejor, por ejemplo, la biblioteca principal que se creó en el último tutorial, quiero hacerla pública usando el feed NuGet, para que todos puedan facilitar la operación en sus bibliotecas.

¿Pero cómo? ¿Cómo vamos a compilar, probar y luego publicar ese paquete en el feed para que todos lo descarguen en sus proyectos?

Bueno, ¡ese es este tutorial para 😁!

¿Qué hay de nuevo?

Casi no hay cambios con respecto al código, las cosas que necesitamos cambiar son el empaquetado, la publicación y luego cómo podemos automatizarlo.

CLI de .NET Core

Vamos a utilizar .NET Core CLI, lo usamos en el tutorial anterior con comandos como dotnet restore, dotnet build y dotnet test.

¡Ahora vamos a utilizar un nuevo conjunto de comandos!

dotnet nuget

Puedes consultar la documentación de este conjunto de herramientas directamente aquí, pero una breve explicación:

dotnet nuget es un conjunto de herramientas esenciales que incluyen instalar, restaurar, eliminar y publicar paquetes.

fuente NuGet

NuGet es el administrador de paquetes para .NET. Las herramientas cliente de NuGet brindan la capacidad de producir y consumir paquetes. La Galería NuGet es el repositorio central de paquetes utilizado por todos los autores y consumidores de paquetes.

NuGet es gratuito, por lo que puede registrarse, obtener su clave API y comenzar a cargar paquetes. Se cargarán, verificarán y luego se enumerarán para todos.

Obtener la clave API

Para cargar su paquete, necesitará obtener su clave API después de registrarse, así que vaya a la página de claves API y cree una nueva.

Ten en cuenta que la clave API tiene una caducidad de 365 días.

Luego copia tu clave y guárdala en algún lugar, como se dice en la página, no podrás volver a verla, y si no la guardaste tendrás que regenerarla.

Generar paquete NuGet

Ahora que tenemos la clave API, nuestro siguiente paso es generar ese paquete NuGet a partir de la solución, así que continúe y abra la solución donde tiene su biblioteca de clases.

Usaré la solución de mi último tutorial, que tiene una clase de biblioteca .NET Core llamada CalculatorCLI.Core.

Ahora vaya a propiedades del proyecto y luego a Paquete, verá mucha información sobre el paquete, como la versión del paquete, los autores, las descripciones y más.

Lo siguiente es llenar esto, realmente no tienes que llenar todo, pero los importantes y obligatorios son Package id, Package version, Authors y Description. Además, si intenta cargar el archivo usted mismo, le solicitará License, y tendremos que agregarlo también.

Luego puede guardar, haga clic derecho en el proyecto y seleccione Pack.

1>------ Build started: Project: CalculatorCLI.Core, Configuration: Debug Any CPU ------
1>CalculatorCLI.Core -> D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\netstandard2.1\CalculatorCLI.Core.dll
1>Successfully created package 'D:\Development\Personal\CalculatorCLI-demo\CalculatorCLI\CalculatorCLI.Core\bin\Debug\CalculatorCLI.Core.1.0.0.1.nupkg'.
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

El resultado mostrará que si todo está bien, imprimirá Successfully created package.

Usando dotnet

Como en el tutorial anterior, utilizamos diferentes comandos para construir y probar la solución. Ahora vamos a agregar más comandos para empaquetar y publicar los paquetes.

Esos comandos son:

1. dotnet pack -c <configuration>
2. dotnet nuget push <package> <k <apikey> -s <source>

Scripts de implementación

Como vamos a cambiar la forma en que será la compilación, creo que la mejor idea sería tener diferentes archivos, cada uno de los cuales contenga una definición de compilación dependiendo del entorno.

Entonces, creemos una carpeta llamada scripts con tres scripts bash en la raíz del repositorio.

scripts\compile.sh

#!/bin/sh

echo "Restoring..."
dotnet restore ".\CalculatorCLI\CalculatorCLI.sln"   

echo "Building..."
dotnet build ".\CalculatorCLI\CalculatorCLI.sln" -c Release

scripts\test.sh

#!/bin/sh

echo "Testing..."
dotnet test ".\CalculatorCLI\CalculatorCLI.sln" -c Release -v n

scripts\push.sh

#!/bin/sh

echo "Packing..."
dotnet pack ./CalculatorCLI/CalculatorCLI.Core/CalculatorCLI.Core.csproj -c Release

echo "Pushing..."
dotnet nuget push ./CalculatorCLI/CalculatorCLI.Core/bin/Release/*.nupkg -s "https://nuget.org" -k $NUGET_API_KEY

Mejorando el archivo .travis.yml

Ahora que tenemos el código fuente actualizado, sabemos los comandos que necesitamos usar, necesitamos integrar nuestra entrega continua con la integración continua. Con eso realmente no tenemos que hacer nada más que codificar, probar, revisar y enviar.

Lo que vamos a hacer ahora, al archivo .travis.yml, es lo siguiente:

1. Agrega diferentes stages
2. Cada stage depende de la rama
3. Si su compilación está en master, significa que el paquete debe actualizarse, por lo tanto, enviaremos nuestro paquete a los feeds de NuGet.
4. Si su compilación es una solicitud de extracción, aún verificaremos si la compilación se compila y probará, pero no la publicaremos.

Etapas

De su documentación:

Puede filtrar y rechazar compilaciones, etapas y trabajos especificando condiciones en su configuración de compilación (su archivo .travis.yml).

Puede encontrar más información sobre TravisCI stages en su página de documentación.

Entonces vamos a cambiar el archivo y agregar las etapas, que terminan así:

language:
    csharp
sudo: required
mono: none 
dotnet: 3.0

os:
  - linux
    
jobs:
  include:
    - stage: compile
      script: bash scripts/compile.sh

    - stage: test
      script: bash scripts/test.sh

    - stage: deploy-prod
      if: branch = master AND type = push
      name: "Deploy to NuGet"
      script: bash scripts/push.sh

Como pueden ver tenemos tres etapas diferentes compile, test y push, la cual la última solo se va a ejecutar cuando el branch sea master y no sea un pull request, solo un push.

Si no entiende esto, simplemente vaya a la documentación y se explica bastante fácilmente.

Teniendo esto en cuenta, todos los pull request no enviarán nada al feed de NuGet.

Configurar la clave API como variable de entorno

Vaya a la configuración de compilación de su repositorio y agregue una nueva variable de entorno, llamada NUGET_API_KEY cuyo valor es la clave de API copiada de la página NuGet.

Crea un pull request

Ahora que tenemos todo configurado, es hora de hacer un pull request y verificar si la compilación para esa solicitud de extracción ignora el último stage.

Verifica las compilaciones

Justo cuando realiza la solicitud de extracción, se pondrá en cola una compilación en el panel de TravisCI y, como puede ver, tenemos 2 compilaciones diferentes allí y no tres.

Ahora aceptemos el pull request y verifiquemos la compilación nuevamente para ver que ahora tenemos tres trabajos en lugar de dos.

Y tan pronto como pueda ver la compilación en cola, podrá ver los tres trabajos, incluido el Deploy-prod al final.

Tan pronto como se complete toda esta compilación, podrá ver en los registros que el paquete se envió a las fuentes.

Y obviamente puedes verlo en la página de NuGet.

Eso es todo

En este tutorial descubrimos cómo automatizar la entrega de nuestros paquetes NuGet. Usamos algunas herramientas como TravisCI, stages y dotnet nuget.

En mi opinión, incluso si es algo que llevaría tiempo configurar correctamente y podría ser demasiado complejo en algunos casos. Invertir tiempo en este tipo de técnicas para dejarlo todo perfecto y automatizado merece la pena.

Puedes encontrar el código fuente, con el archivo .travis.yml justo aquí, si tienes alguna pregunta, no dudes en contactarme en mi twitter.