CI/CD para projetos C# no GitHub Actions: guia completo

Introdução: por que CI/CD é importante para o desenvolvedor C#

No desenvolvimento de software moderno, testes manuais e deploy são ineficientes e arriscados. Cada vez que um desenvolvedor faz push de código para o repositório, surge a necessidade de garantir que a build não quebrou, os testes passam e o aplicativo está pronto para implantação. É aqui que o CI/CD (Continuous Integration / Continuous Deployment) entra em ação.

GitHub Actions é uma ferramenta de automação integrada no GitHub que permite criar workflows diretamente no seu repositório. É ideal para projetos C# (.NET), pois suporta runners Windows e Linux, além de ter um rico ecossistema de ações prontas (actions).

Neste artigo, vamos abordar como configurar um pipeline CI/CD completo para um projeto C# usando GitHub Actions: desde build e testes até a publicação de um pacote NuGet ou deploy de uma aplicação web.

Fundamentos do GitHub Actions: YAML e estrutura do workflow

Cada workflow no GitHub Actions é descrito em um arquivo YAML, armazenado no diretório .github/workflows/ do seu repositório. Vamos analisar a estrutura básica:

name: .NET CI/CD

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

jobs:  build:    runs-on: ubuntu-latest

    steps:    - name: Checkout code      uses: actions/checkout@v4

    - name: Setup .NET      uses: actions/setup-dotnet@v4      with:        dotnet-version: '8.x'

    - name: Restore dependencies      run: dotnet restore

    - name: Build      run: dotnet build --configuration Release --no-restore

    - name: Run tests      run: dotnet test --configuration Release --no-build --verbosity normal

Elementos-chave:

• on — gatilhos de execução (push, pull_request, schedule, etc.)
• jobs — conjunto de tarefas executadas em paralelo ou sequencialmente
• runs-on — sistema operacional para execução (ubuntu-latest, windows-latest, macos-latest)
• steps — sequência de comandos ou actions prontas

Importante: para projetos .NET, use a action actions/setup-dotnet especificando a versão do SDK. Isso garante que o ambiente terá a versão correta do .NET.

Configuração de testes e linting de código C#

Um CI/CD de qualidade não pode prescindir de testes automáticos e verificação de estilo de código. Vamos adicionar ao nosso workflow etapas de teste unitário e análise estática.

Testes unitários com xUnit e cobertura de código

Suponha que você tenha um projeto com testes em xUnit. Vamos adicionar uma etapa para gerar relatório de cobertura usando Coverlet:

- name: Run tests with coverage  run: |    dotnet test --configuration Release \      --no-build \      --verbosity normal \      /p:CollectCoverage=true \      /p:CoverletOutputFormat=opencover \      /p:CoverletOutput=./coverage.xml

- name: Upload coverage to Codecov  uses: codecov/codecov-action@v3  with:    files: ./coverage.xml    flags: unittests    fail_ci_if_error: false

Para isso, é necessário adicionar o pacote coverlet.collector ao projeto de testes. Exemplo de comando:

dotnet add package coverlet.collector

Análise estática com Roslyn Analyzers

Vamos adicionar verificação de código usando os analisadores integrados do .NET:

- name: Run Roslyn analyzers  run: dotnet build --configuration Release --warnaserror -p:RunAnalyzersDuringBuild=true

Também é possível usar ferramentas de terceiros, como SonarCloud:

- name: SonarCloud Scan  uses: SonarSource/sonarcloud-github-action@master  env:    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}    SONAR_TOKEN: ${{ secrets.SON