DEV Community

Cover image for Turbinando o Pipeline: Caches, Matrix Builds e Branch Protection (Parte 4)
Erick Gabriel dos Santos Alves
Erick Gabriel dos Santos Alves

Posted on

Turbinando o Pipeline: Caches, Matrix Builds e Branch Protection (Parte 4)

#github #angular #devops #infrastructure

Chegamos ao grande final da nossa jornada! Recapitulando o que construímos até aqui:

  1. Criamos um pipeline que testa e compila nosso Frontend (Angular) e Backend (.NET) em paralelo.
  2. Tiramos a automação da nuvem paga e colocamos em um Self-Hosted Runner gratuito.
  3. Automatizamos a criação de Tags e do Changelog.

Neste ponto, você já tem um processo melhor do que muitas empresas grandes por aí. Mas, se você observar os logs de execução, vai notar um gargalo frustrante: a instalação das dependências.

A cada push, seu robô perde minutos preciosos baixando a mesma pasta node_modules (o famoso buraco negro do universo) e os mesmos pacotes NuGet do zero. Hoje, vamos resolver isso e, de quebra, blindar a sua branch main contra códigos quebrados.

1. A Mágica do Cache

Em CI/CD, "Cache" significa guardar um backup das suas dependências da execução anterior. Se o seu arquivo package-lock.json ou .csproj não mudou, o GitHub Actions simplesmente restaura a pasta do cache em questão de segundos, pulando totalmente a etapa de download.

Otimizando o Frontend (Angular / Node)

Se você está usando a versão mais recente da action setup-node, o cache já vem embutido! Só precisamos ativá-lo e dizer onde está o nosso arquivo de lock, já que nosso projeto está dentro da pasta /frontend.

Vá no seu .yml da Parte 1 e atualize a etapa do Node.js:

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm' # Ativa o cache mágico!
          cache-dependency-path: './frontend/package-lock.json' # Aponta para a subpasta
Enter fullscreen mode Exit fullscreen mode

Pronto. Só de adicionar essas duas linhas, o tempo do seu npm ci vai cair drasticamente.

Otimizando o Backend (.NET / NuGet)

Para o C#, precisamos usar a action oficial de cache (actions/cache). Ela exige três coisas: o que salvar (caminho), como nomear o backup (key) e de onde tentar recuperar se não achar o exato (restore-keys).

Adicione este bloco logo ANTES da etapa de dotnet restore:

      - name: Cache NuGet Packages
        uses: actions/cache@v4
        with:
          path: ~/.nuget/packages
          # Cria uma chave única baseada no SO e nos arquivos de projeto
          key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj', '**/packages.lock.json') }}
          restore-keys: |
            ${{ runner.os }}-nuget-
Enter fullscreen mode Exit fullscreen mode

Na próxima vez que o pipeline rodar, a primeira execução ainda fará o download, mas salvará o cache no final. Nas execuções seguintes, você verá a magia da restauração rápida.

2. Testando Multiversos com Matrix Builds

E se você estiver construindo uma biblioteca ou ferramenta que precisa funcionar em múltiplas versões do Node (ex: 18 e 20) ou em vários Sistemas Operacionais simultaneamente?

Você não precisa copiar e colar o seu código YAML. Basta usar a estratégia de Matrix.

jobs:
  build-frontend:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18.x, 20.x, 22.x] # O GitHub vai rodar este Job 3 vezes simultaneamente!

    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
Enter fullscreen mode Exit fullscreen mode

Com a matrix, o GitHub Actions cria caminhos paralelos automaticamente. Se uma versão falhar e as outras passarem, você sabe exatamente onde está o problema de compatibilidade.

3. O Leão de Chácara: Branch Protection Rules

De que adianta ter um pipeline que roda testes incríveis se um desenvolvedor apressado pode simplesmente clicar em "Merge Pull Request" ignorando que tudo ficou vermelho?

A automação só é útil se for obrigatória. Para isso, usamos as Regras de Proteção de Branch.

  1. Vá na aba Settings do seu repositório no GitHub.
  2. Na barra lateral, clique em Branches.
  3. Clique em Add branch ruleset (ou edite a regra da sua branch main).
  4. Marque a opção Require a pull request before merging.
  5. O MAIS IMPORTANTE: Marque a opção Require status checks to pass before merging.
  6. Na barra de pesquisa que aparecer, digite os nomes exatos dos seus Jobs (ex: Build Angular App e Build & Test .NET API) e adicione-os como obrigatórios.

O Resultado: A partir de agora, o botão verde de Merge no GitHub ficará bloqueado. Ele só será liberado se o nosso GitHub Actions rodar, compilar o Angular, passar nos testes do .NET e retornar a luz verde.

Conclusão da Série

Parabéns! Se você aplicou os conceitos desta série de 4 partes, você evoluiu de "alguém que arrasta arquivos para o FTP" para um administrador de infraestrutura ágil, segura e profissional.

Dominar pipelines, gestão de secrets, runners locais e versionamento semântico são habilidades que diferenciam desenvolvedores de alto nível no mercado. O GitHub Actions é uma ferramenta incrivelmente poderosa que vai muito além de apenas subir código.

Como ficou a sua esteira de CI/CD? Qual foi o tempo que você conseguiu economizar usando o sistema de Caches? Compartilhe o link do seu repositório (ou os perrengues que passou configurando) aqui nos comentários!

Top comments (0)