CI/CD para C#: configurando pipeline do zero para preguiçosos e ocupados

CI/CD para C#: como parar de fazer deploy manualmente e começar a viver

Se você ainda compila seu projeto C# localmente, envia os builds por FTP e reza para que nada dê errado — tenho novidades para você. Em 2025, fazer isso é vergonhoso. Até para um pequeno pet-project.

CI/CD não é mágica de seniors que ganham 300k, mas sim um conjunto de scripts que fazem a rotina por você. Hoje vamos configurar um pipeline CI/CD completo para C# do zero. Sem enrolação, com exemplos reais e análise de erros.

A propósito, se você programa em Python — no nosso pythonlib.ru também temos guias de automação. Mas hoje vamos trabalhar com C#.

O que é CI/CD e por que é importante para o desenvolvedor C#

CI (Continuous Integration) — é quando cada commit seu no Git é automaticamente compilado e testado. Nada de "funciona na minha máquina".

CD (Continuous Delivery/Deployment) — é quando, após uma compilação bem-sucedida, o código vai sozinho para o servidor (ou para a nuvem).

Para C#, isso é especialmente relevante: a compilação com dotnet build pode diferir em máquinas diferentes, e os testes todo mundo esquece de rodar. CI/CD resolve ambos os problemas.

Escolhendo a ferramenta: GitHub Actions vs GitLab CI vs Jenkins

Para começar, recomendo GitHub Actions. Por quê?

\n
• Gratuito para repositórios públicos (sim, para C# também)
\n
• Não precisa instalar servidor
\n
• Ações prontas para .NET
\n
• YAML — fácil de ler
\n

Se você usa GitLab — o princípio é o mesmo, a sintaxe é parecida. Jenkins deixamos para o inferno corporativo.

Escrevendo o primeiro pipeline para um projeto C#

Crie na raiz do repositório o arquivo .github/workflows/dotnet.yml. Sim, o arquivo deve estar exatamente nesta pasta.

Aqui está um pipeline mínimo funcional que compila o projeto e executa os testes:

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    - 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

Analisando passo a passo:

\n
• on: push — o pipeline é executado ao fazer push para main ou develop
\n
• runs-on: ubuntu-latest — compilamos no Linux (C# com .NET Core/8+ funciona em qualquer lugar)
\n
• setup-dotnet — instala a versão necessária do .NET SDK
\n
• dotnet restore — restaura os pacotes NuGet
\n
• dotnet build — compila a versão de release
\n
• dotnet test — executa todos os testes do projeto
\n

Após o push, acesse a aba Actions do seu repositório — você verá o pipeline em execução. Se os testes falharem, receberá um status vermelho e um e-mail.

Adicionando code coverage (porque testes sem cobertura são ficção)

Um pipeline bonito deve mostrar quanto código está coberto por testes. Para C#, usamos coverlet em conjunto com ReportGenerator.

Primeiro, adicione os pacotes NuGet ao projeto de teste:

dotnet add YourTestProject.csproj package coverlet.collector\ndotnet add YourTestProject.csproj package coverlet.msbuild

Agora, atualize a etapa de testes no pipeline:

    - name: Run tests with coverage\n      run: |\n        dotnet test --no-build --configuration Release \\\n          /p:CollectCoverage=true \\\n          /p:CoverletOutputFormat=opencover \\\n          /p:CoverletOutput=./TestResults/coverage.xml\n\n    - name: Install ReportGenerator\n      run: dotnet t