Recentemente fiz um tutorial sobre como usar o Travis CI como uma ferramenta para testar automaticamente seu código que você acabou de enviar ou está tentando enviar para o branch master. Fazendo com que ele seja compilado e testado e finalmente informe o status dessa mudança.

Mas podemos continuar melhorando, por exemplo, a biblioteca principal que foi feita no último tutorial, quero torná-la pública usando o feed NuGet para que todos possam facilitar a operação em suas bibliotecas!

Mas como? Como vamos compilar, testar e depois publicar esse pacote no feed para que todos possam baixá-lo em seus projetos?

Bom, esse é o tutorial para 😁!

O que há de novo?

Quase não há mudanças em relação ao código, as coisas que precisamos mudar são a embalagem, a publicação e como podemos automatizá-lo.

CLI do .NET Core

Vamos usar o .NET Core CLI, usamos no tutorial anterior com comandos como dotnet restore, dotnet build e dotnet test.

Agora vamos usar um novo conjunto de comandos!

#dotnet nuget

Você pode verificar a documentação deste conjunto de ferramentas aqui, mas uma breve explicação:

dotnet nuget é um conjunto de ferramentas essenciais que inclui instalação, restauração, remoção e publicação de pacotes.

feed NuGet

NuGet é o gerenciador de pacotes para .NET. As ferramentas cliente NuGet fornecem a capacidade de produzir e consumir pacotes. A Galeria NuGet é o repositório central de pacotes usado por todos os autores e consumidores de pacotes.

O NuGet é gratuito, então você pode se inscrever, pegar sua chave de API e começar a fazer upload de pacotes. Eles serão carregados, verificados e listados para todos.

Obtenha a chave API

Para fazer upload do seu pacote, você precisará obter sua chave de API após a inscrição, então vá para a página de chaves de API e crie uma nova.

Lembre-se de que a chave de API tem validade de 365 dias.

Em seguida, copie sua chave e guarde-a em algum lugar, como dito na página, você não poderá vê-la novamente e, se não a salvou, terá que regenerá-la.

#Gerar pacote NuGet

Agora que temos a chave API, nossa próxima etapa é gerar esse pacote NuGet a partir da solução, então vá em frente e abra a solução onde você tem sua biblioteca de classes.

Usarei a solução do meu último tutorial, que possui uma classe de biblioteca .NET Core chamada CalculatorCLI.Core.

Agora vá para propriedades do projeto e depois Pacote, você verá muitas informações sobre o pacote como versão do pacote, autores, descrições e muito mais.

O próximo passo é preencher isso, você realmente não precisa preencher tudo, mas os importantes e obrigatórios são Package id, Package version, Authors e Description. Além disso, se você tentar fazer upload do arquivo sozinho, será solicitado License, precisaremos adicioná-lo também.

Depois você pode salvar, clicar com o botão direito no projeto e selecionar 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 ==========

A saída mostrará que se tudo estiver bem, será impresso Successfully created package.

Usando dotnet

Assim como no tutorial anterior, usamos diferentes comandos para construir e testar a solução. Agora vamos adicionar mais comandos para empacotar e publicar os pacotes.

Esses comandos são:

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

Scripts de implantação

Como vamos mudar a forma como será a compilação, acredito que ter arquivos diferentes, cada um deles contendo uma definição de compilação dependendo do ambiente, seria a melhor ideia.

Então vamos criar uma pasta chamada scripts com três scripts bash na raiz do repositório.

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

Melhorando o arquivo .travis.yml

Agora que temos o código fonte atualizado, sabemos os comandos que precisamos usar, precisamos integrar nossa entrega contínua com integração contínua. Com isso, não precisamos fazer nada além de codificar, testar, revisar e enviar.

O que vamos fazer agora, com o arquivo .travis.yml, é o seguinte:

1. Adicione stages diferente
2. Cada stage depende da filial
3. Se sua compilação estiver no master, significa que o pacote deve ser atualizado, portanto, enviaremos nosso pacote para os feeds do NuGet
4. Se sua compilação for uma solicitação pull, ainda iremos verificar se a compilação é compilada e testada, mas não iremos publicá-la.

Estágios

Da documentação deles:

Você pode filtrar e rejeitar compilações, estágios e trabalhos especificando condições em sua configuração de compilação (seu arquivo .travis.yml).

Você pode encontrar mais informações sobre o TravisCI stages na página de documentação.

Então vamos alterar o arquivo e adicionar as etapas, que fica assim:

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 você pode ver, temos três estágios diferentes compile, test e push, sendo que o último só será executado quando o branch for master e não for um pull request para ele, apenas um push.

Se você não entende isso, basta acessar a documentação e é explicado com bastante facilidade.

Com isso em mente, todos os pull request não enviarão nada para o feed do NuGet.

Configurando a chave API como uma variável de ambiente

Vá para as configurações de compilação do seu repositório e adicione uma nova variável de ambiente, chamada NUGET_API_KEY com o valor sendo a chave de API copiada da página NuGet.

Crie um pull request

Agora que temos tudo configurado, é hora de fazer um pull request e verificar se a compilação daquele pull request está ignorando o último stage.

Verifique as compilações

Assim que você fizer a solicitação pull, um build será enfileirado no painel do TravisCI, e como você pode ver, temos 2 builds diferentes lá e não três.

Agora vamos aceitar o pull request e verificar a compilação novamente para ver que agora temos três jobs em vez de dois.

E assim que você ver a compilação sendo enfileirada, você poderá ver os três trabalhos, incluindo o Deploy-prod no final.

Assim que toda a compilação for concluída, você poderá ver nos logs que o pacote foi enviado para as fontes.

E obviamente você pode ver isso na página do NuGet

#É isso

Neste tutorial, descobrimos como automatizar a entrega de pacotes NuGet. Usamos algumas ferramentas como TravisCI, stages e dotnet nuget.

Na minha opinião, mesmo que seja algo que levaria tempo para ser configurado corretamente e poderia ser muito complexo em alguns casos. Vale a pena investir tempo nesse tipo de técnica para deixar tudo perfeito e automatizado.

Você pode encontrar o código fonte, com o arquivo .travis.yml aqui, se você tiver alguma dúvida, sinta-se à vontade para entrar em contato comigo no meu twitter!