ASP.NET Deploy com GitHub Actions e Microsoft Azure

Continuous delivery e continuous deployment

CD pode significar Continuous Delivery ou Continuous Deployment. A entrega contínua tem um ritmo mais fixo, como releases diárias, semanais ou mensais, de acordo com o negócio.

Já o Continuous Deployment está um passo à frente. Nele, a publicação acontece sempre que as mudanças de código passam pelas etapas de integração.

Neste artigo, vamos cobrir o Continuous Deployment. Ou seja, cada push na branch master gera uma nova publicação automaticamente.

Azure CLI

A segunda instalação necessária é o Azure CLI. Ele habilita o comando az no terminal e permite criar e gerenciar recursos do Azure sem abrir o portal.

GitHub CLI

Em seguida, precisamos do GitHub CLI. Ele habilita o comando gh, que cria e clona repositórios direto do terminal.

Windows Terminal

Este item não é obrigatório, mas fica como recomendação. Se você usa Windows, o Windows Terminal torna o trabalho com várias abas e shells bem mais confortável.

Autenticando no Azure

Depois de instalar o Azure CLI, abra o terminal e faça a autenticação com o comando abaixo.

az login

Em seguida, o navegador abre a tela de login da Microsoft. Assim que você se autenticar, o terminal já estará conectado à sua conta.

Caso tenha mais de uma assinatura ativa, use az account list para listar as assinaturas. Depois, use az account set --subscription NAME para tornar uma delas a padrão.

Criando um resource group

Os resource groups agrupam os recursos de uma solução. Além de ajudar na organização, eles facilitam o gerenciamento de permissões, custos e exclusão em lote.

Para esta demonstração, vamos criar um grupo chamado aspnetghcdeploy.

az group create --location brazilsouth --name aspnetghcdeploy

A flag --location define a região do grupo. Neste caso, usamos o Brazil South.

Criando o plano e o Web App

O próximo passo é criar a aplicação, e para isso precisamos de um App Service Plan. Ele define a faixa de preço e os recursos do servidor que o app utiliza.

Vamos criar um plano usando a SKU gratuita, para não gerar cobranças durante os testes.

az appservice plan create --name aspnetghcdeploy --resource-group aspnetghcdeploy --sku FREE

Os preços variam conforme a região, o sistema operacional e o tier escolhido. Portanto, consulte a página de preços do App Service antes de levar a aplicação para produção.

Com o plano pronto, criamos o Web App com o comando az webapp create.

az webapp create --name aspnetghcdeploy --resource-group aspnetghcdeploy --plan aspnetghcdeploy

Pronto, neste momento já temos uma aplicação rodando em https://aspnetghcdeploy.azurewebsites.net/. O nome do app precisa ser único em todo o Azure, então adapte-o ao seu caso.

Para conferir todos os comandos disponíveis, consulte a referência oficial do Azure CLI.

Criando a aplicação ASP.NET Core

Vamos aproveitar para criar a aplicação. Para ter algo mais visual, usamos o template padrão do ASP.NET Core MVC.

cd aspnetghcdeploy
dotnet new mvc
dotnet new gitignore

O comando dotnet new gitignore cria um arquivo .gitignore com tudo o que um projeto .NET precisa. Essa dica chegou pelo Ruan Silva, nos comentários do canal do YouTube.

Enviando o código

Agora enviamos o código local para o GitHub com os comandos abaixo.

git add --all
git commit -m "First version"
git push -u origin master

Note que usamos a branch master no git push. Se preferir, você também pode fazer esse processo de forma visual pelo Visual Studio Code.

Neste momento, o código da aplicação padrão do ASP.NET Core MVC já aparece no seu repositório.

Armazenando as credenciais nos secrets

Como comentamos, essas informações não podem ficar expostas. O melhor lugar para guardá-las é a área de Secrets do repositório no GitHub.

Abra as configurações do repositório, acesse a seção de secrets e crie um novo segredo chamado AZURE_DEPLOY. O valor dessa chave é o JSON obtido no passo anterior.

O nome AZURE_DEPLOY não é reservado. Você pode usar qualquer nome, desde que ele não tenha espaços nem caracteres especiais.

Gatilho do deploy com GitHub Actions

Um workflow tem basicamente duas partes: on e jobs. A primeira define quando o fluxo roda, e a segunda define o que ele executa.

name: Deploy to Azure

on:

jobs:

A propriedade name dá nome ao workflow. Vale lembrar que, no YAML, a indentação importa, então mantenha exatamente o mesmo espaçamento.

Nesta aplicação, o deploy com GitHub Actions deve acontecer somente quando o código mudar na branch master. Mudanças em desenvolvimento, homologação ou outras branches não geram publicação.

name: Deploy to Azure

on:
  push:
    branches:
      - master

Como podemos notar, o disparo fica bem intuitivo. A cada push na branch master, o fluxo segue adiante.

Definindo a máquina do job

O primeiro passo é informar o sistema operacional da máquina que executa o job. Para isso, usamos o atributo runs-on.

Neste exemplo, teremos apenas um job, chamado build-and-deploy, que compila e publica o código.

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

Checkout e instalação do .NET

A máquina Ubuntu nasce apenas com o básico do sistema operacional. Portanto, precisamos baixar o código e instalar o .NET.

Aqui entra a grande vantagem das actions. Milhares de pessoas fazem deploy de aplicações ASP.NET Core no Azure todos os dias, e os passos repetitivos já existem prontos para reuso.

Com a palavra uses, reaproveitamos actions públicas no workflow. Para baixar o código, usamos a action checkout, mantida pelo próprio GitHub.

Em seguida, instalamos o .NET com a action setup-dotnet. O bloco with informa a versão do SDK.

    steps:
      - uses: actions/checkout@master

      - name: Set up .NET Core
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: "3.1.102"

Build e publish

Para compilar a aplicação, não precisamos de nenhuma action adicional. Afinal, o .NET já está instalado, então basta executar o dotnet build.

      - name: Build with dotnet
        run: dotnet build --configuration Release

Note a flag --configuration Release. Sem ela, a aplicação compilaria em modo Debug.

Da mesma forma, o dotnet publish gera os arquivos finais em uma pasta de saída, sem exigir outra action.

      - name: dotnet publish
        run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp

Login e deploy com GitHub Actions no Azure

Com o pacote pronto, precisamos autenticar no Azure. Nesse passo, a action azure/login usa a credencial guardada nos secrets do repositório.

      - name: Azure Login
        uses: azure/login@v1.1
        with:
          creds: ${{ secrets.AZURE_DEPLOY }}

Qualquer segredo do repositório fica criptografado. No YAML, você o acessa pela sintaxe ${{ secrets.KEY }}.

O último passo é o deploy com GitHub Actions propriamente dito, feito pela action azure/webapps-deploy. Veja o workflow completo.

name: Deploy to Azure

on:
  push:
    branches:
      - master

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@master

      - name: Set up .NET Core
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: "3.1.102"

      - name: Build with dotnet
        run: dotnet build --configuration Release

      - name: dotnet publish
        run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp

      - name: Azure Login
        uses: azure/login@v1.1
        with:
          creds: ${{ secrets.AZURE_DEPLOY }}

      - name: Deploy to Azure Web App
        uses: azure/webapps-deploy@v1
        with:
          app-name: "aspnetghcdeploy"
          slot-name: "production"
          package: ${{env.DOTNET_ROOT}}/myapp

O parâmetro app-name indica o Web App de destino. Enquanto isso, o package aponta para a pasta gerada pelo dotnet publish.