CI/CD para projetos C#: GitHub Actions do A ao Z

Introdução: Por que CI/CD é o padrão no desenvolvimento .NET moderno

O desenvolvimento moderno em C# e na plataforma .NET é impensável sem automação. Executar manualmente builds, testes e deploys é um caminho para erros, perda de tempo e atrasos em lançamentos. CI/CD (Continuous Integration / Continuous Deployment) resolve esses problemas, tornando o processo de entrega de código previsível e rápido.

GitHub Actions é uma ferramenta de automação integrada no GitHub, ideal para projetos C#. Ela permite configurar um pipeline diretamente no repositório usando arquivos YAML. Neste artigo, abordaremos o ciclo completo: desde o build básico até a publicação de um pacote NuGet e o deploy de uma aplicação web.

1. Fundamentos do GitHub Actions para .NET

O que são workflow e job?

Workflow é um processo automatizado que é acionado por um evento (push, pull request, schedule). Um workflow consiste em um ou mais jobs (tarefas) que são executados em runners (runner — uma máquina virtual com Ubuntu, Windows ou macOS).

Cada job é composto por steps (etapas), que podem executar comandos shell ou usar actions prontas do marketplace.

Primeiro workflow: build de um projeto .NET

Crie na raiz do repositório a pasta .github/workflows e o arquivo build.yml:

name: Build .NET Project

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    
    - name: Setup .NET
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: '8.0.x'
    
    - name: Restore dependencies
      run: dotnet restore
    
    - name: Build
      run: dotnet build --no-restore --configuration Release
    
    - name: Run tests
      run: dotnet test --no-build --configuration Release --verbosity normal

Este workflow é executado a cada push ou pull request na branch main. Ele restaura as dependências, compila o projeto em Release e executa os testes. Se qualquer etapa falhar, o workflow será interrompido e você verá um status vermelho no PR.

2. Configuração avançada: matriz de builds e cache

Matriz de versões do .NET

Para verificar a compatibilidade com diferentes versões do .NET, use uma matriz (matrix):

jobs:
  build:
    strategy:
      matrix:
        dotnet-version: ['6.0.x', '7.0.x', '8.0.x']
        os: [ubuntu-latest, windows-latest]
    runs-on: ${{ matrix.os }}

    steps:
    - uses: actions/checkout@v4
    - name: Setup .NET ${{ matrix.dotnet-version }}
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: ${{ matrix.dotnet-version }}
    - run: dotnet build --configuration Release
    - run: dotnet test

O runner executará o build para cada combinação de SO e versão do .NET em paralelo. Isso economiza tempo e garante compatibilidade multiplataforma.

Cache de dependências

Restaurar pacotes NuGet toda vez leva tempo. Ative o cache:

- name: Cache NuGet packages
  uses: actions/cache@v4
  with:
    path: ~/.nuget/packages
    key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}
    restore-keys: |
      ${{ runner.os }}-nuget-

- name: Restore dependencies
  run: dotnet restore

Agora, em execuções repetidas, os pacotes serão restaurados do cache se os arquivos .csproj não forem alterados.

3. Publicação de pacote NuGet no GitHub Packages

Se você desenvolve uma biblioteca em C#, pode publicá-la automaticamente no GitHub Packages ao criar um release.

Workflow para publicação

name: Publish NuGet Package

on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v4
    
    - name: Setup .NET
      uses: actions/setup-dotnet@v4
```