English version / Versão em inglês: "GitHub Actions for .Net Full Framework: Build and Test".

É possível criar GitHub Actions de Build e Test para projetos .Net Full Framework?

✅ Sim, é possível! E vou te mostrar como eu fiz.

Mas antes, um pouco de contexto. 💭

Recentemente tive que mexer em uma base de código legado de um projeto em .Net Full Framework.

O código estava versionado no GitHub e apresentava um fluxo de pull request e code review para integração de código na branch principal. Porém, não havia checks para verificação do código que estava sendo integrado, o que permitiria que códigos que não compilassem, ou que quebrassem os testes unitários, fossem incluídos na nossa branch principal sem nenhum alerta.

A ausência do feedback rápido sobre a saúde do código integrado gerava insegurança nos desenvolvedores durante a aprovação dos pull requests, pois problemas inseridos por meio da adição de novos códigos poderiam demorar muito mais tempo do que o desejado para serem identificados.

Com o intuito de melhorar nosso fluxo de trabalho, pensei em criar um workflow de CI com GitHub Actions para acelerar o fluxo de feedback durante as nossas integrações de código.

Ao verificar a documentação das GitHub Actions, percebi que não havia nenhum template para a criação de um fluxo voltado ao .Net Full Framework. E então fiz a mesma pergunta do início do texto:

 
É possível criar GitHub Actions de Build e Test para projetos .Net Full Framework?
 

Ao longo de minha jornada de pesquisa, descobri alguns recursos, oficiais e da comunidade:

• setup-msbuild;
• setup-nuget;
• Setup-VSTest.

A utilização destas actions me possibilitou criar o fluxo de CI para .Net Full Framework que é disparado a cada nova integração via push ou pull request na branch main, conforme arquivo ci.yml abaixo:

Entendendo a action criada

Abaixo, explicação passo-a-passo do arquivo ci.yml:

1. Nome da GitHub Action.
   

    name: Build and Tests
   

2. Estabelecendo que as actions devem ser executadas quando houver pushes e criação de pull requests para a branch main (branch default deste projeto).
   

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

3. O build e teste serão executados em um sistema operacional Windows, afinal estamos lidando com .Net Full Framework (que não oferece suporte a outros sistemas operacionais).
   

    jobs:  
      build:    
        runs-on: windows-latest
   

4. É definida a seção que vai agrupar todos os passos executados, detalhados nos próximos items.
   

        steps:      
   

5. Faz o checkout do código.
   

          - uses: actions/checkout@v2
   

6. Faz o setup do MSBuild para uso posterior.
   

          - name: Setup MSBuild
            uses: microsoft/setup-msbuild@v1
   

7. Faz o setup do Nuget para uso posterior.
   

          - name: Setup NuGet
            uses: NuGet/setup-nuget@v1.0.5
   

8. Faz o setup do VSTest para uso posterior.
   

          - name: Setup VSTest
            uses: darenm/Setup-VSTest@v1
   

9. Navega para o workspace do GitHub para iniciar o restore, build e teste da aplicação.
   

          - name: Navigate to Workspace
            run: cd $GITHUB_WORKSPACE
   

10. Usa o nuget para fazer restore dos pacotes utilizados pela aplicação.
    

           - name: Restore Packages
             run: nuget restore Sandbox.sln
    

11. Compila o código do projeto com o msbuild, em modo release.
    

           - name: Build Solution
             run: |
               msbuild.exe Sandbox.sln /p:platform="Any CPU" /p:configuration="Release"
    

12. Executa os testes do projeto Sandbox.Tests.dll, utilizando o vstest.console.exe.
    

           - name: Run Tests
             run: vstest.console.exe .\tests\Sandbox.Tests\bin\Release\Sandbox.Tests.dll
    

Resultados

Após a implantação do nosso CI, basta abrirmos um PR para ver o resultado da nossa implementação.

PR aberto, actions pendentes de execução

Ao abrir um PR, agora podemos ver que alguns checks estão pendentes de execução.

PR aberto, actions executadas

Após a execução dos nossos checks, o resultado já é mostrado na própria página do PR. Dá pra perceber que após verificar que os checks estão ok, o botão de Merge pull request ganhou até um destaque.

Detalhes das actions executadas

Ao analisar a aba de checks, é possível verificar passo-a-passo a execução. Se houvesse qualquer falha, nessa página seria possível verificar qual passo quebrou e analisar os logs para identificar o erro.

Se ficou curioso pra navegar em uma página com os detalhes das execuções das actions, aqui você encontra uma execução com sucesso, e aqui encontra uma execução com falhas.

Projeto completo

Ficou curioso sobre o projeto? Este aqui é o repositório onde todo o código está disponível:

Por favor, considere deixar uma ⭐ no repositório se ele te ajudar! ❤️

Conclusão 🎯

Lidar com código legado pode ser muito complicado, então propor melhorias no fluxo de trabalho pode nos ajudar a mudar drasticamente a realidade do projeto, ao incentivar o feedback rápido e mitigar pontos de insegurança que prejudicam o time de desenvolvimento.

As GitHub Actions são ferramentas muito úteis para automação de processos de CI. Apesar de não conter um template inicial na documentação oficial, é possível criar workflows com GitHub Actions para .Net Full Framework, graças às actions oficiais e também às criadas e disponibilizadas pela comunidade.

Eu tive algum trabalho para conseguir viabilizar meu pipeline de CI, se você tiver qualquer problema na implementação do seu e quiser compartilhar nos comentários deste post, ficarei feliz em poder ajudá-lo.

Um abraço! 😉 😘

…

⚠️ Vale lembrar que, antes de utilizar o workflow, é importante consultar se ele e as suas dependências estão de acordo com as políticas do projeto onde você deseja aplicá-los. ⚠️