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

Introdução: Por que projetos C# precisam de CI/CD?

O desenvolvimento de aplicações modernas em C# e na plataforma .NET exige não apenas código de qualidade, mas também um processo confiável de entrega ao usuário. Builds manuais, testes e deploys são não apenas lentos, mas também propensos a erros. É aqui que o CI/CD (Integração Contínua / Entrega Contínua) entra em cena — uma prática que automatiza todas as etapas do ciclo de vida do software.

O GitHub Actions é uma ferramenta integrada do GitHub que permite criar pipelines poderosos diretamente no repositório. Neste artigo, vamos abordar como configurar um CI/CD completo para projetos C# usando GitHub Actions: desde um build simples até o deploy automático. Você aprenderá a escrever configurações YAML, otimizar testes e evitar erros comuns.

Fundamentos do GitHub Actions para .NET

O que são workflow e job?

Workflow (fluxo de trabalho) é um processo automatizado que é acionado por um evento específico (push, pull request, criação de release). Ele é descrito no arquivo .github/workflows/*.yml. Um workflow consiste em uma ou mais jobs (tarefas), que são executadas em runners (máquinas virtuais). Cada job pode conter uma sequência de steps (etapas).

Para projetos C#, as etapas principais são: restauração de dependências (dotnet restore), build (dotnet build), execução de testes (dotnet test) e publicação (dotnet publish).

Modelo básico de workflow para .NET

Abaixo está um workflow mínimo para build e teste de um projeto C#. Salve este código no arquivo .github/workflows/dotnet-ci.yml.

name: .NET CI\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n\n    steps:\n    - name: Checkout repository\n      uses: actions/checkout@v4\n\n    - name: Setup .NET\n      uses: actions/setup-dotnet@v4\n      with:\n        dotnet-version: '8.0.x'\n\n    - name: Restore dependencies\n      run: dotnet restore\n\n    - name: Build\n      run: dotnet build --no-restore --configuration Release\n\n    - name: Run tests\n      run: dotnet test --no-build --configuration Release --verbosity normal

Análise das linhas principais:

\n
• actions/checkout@v4 — clona o repositório no ambiente de execução.
\n
• actions/setup-dotnet@v4 — instala a versão especificada do .NET SDK.
\n
• dotnet restore — baixa os pacotes NuGet.
\n
• dotnet build --configuration Release — compila o projeto no modo Release.
\n
• dotnet test — executa todos os testes da solução.
\n

Configuração avançada: cache e matriz de build

Cache de pacotes NuGet

Cada execução de workflow começa com um ambiente limpo. Para acelerar o processo, é possível armazenar em cache a pasta ~/.nuget/packages. Isso é especialmente útil para projetos grandes com dezenas de dependências.

steps:\n  - uses: actions/cache@v4\n    with:\n      path: ~/.nuget/packages\n      key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}\n      restore-keys: |\n        ${{ runner.os }}-nuget-\n  - run: dotnet restore

A chave do cache é construída com base no hash dos arquivos de projeto (.csproj). Se as dependências não mudaram, o cache será restaurado em segundos.

Matriz de build (Matrix Strategy)

Se sua aplicação precisa funcionar em diferentes versões do .NET ou sistemas operacionais, use a matriz. O GitHub Actions criará automaticamente uma job separada para cada combinação.

jobs:\n  build:\n    strategy:\n      matrix:\n        os: [ubuntu-latest, windows-latest]\n        dotnet: ['6.0.x', '8.0.x']\n    runs-on: ${{ matrix.os }}\n    steps:\n      - uses: actions/checkout@v4\n      - name: Setup .NET\n