CI/CD para Java: configurações avançadas do GitHub Actions

Introdução: de pipelines básicos a soluções industriais

Um pipeline básico de CI/CD para um projeto Java é bom. Mas no desenvolvimento real, quando o projeto cresce para dezenas de módulos e a equipe é composta por vários desenvolvedores, um simples `mvn clean test` deixa de atender aos requisitos. Surgem questões: como acelerar o build? Como testar em diferentes versões do JDK? Como organizar a execução paralela de testes? Como publicar artefatos automaticamente no Docker Hub?

Neste artigo, abordaremos técnicas avançadas de configuração do GitHub Actions para projetos Java. Você aprenderá como transformar seu pipeline de uma sequência linear de etapas em um sistema poderoso, paralelo e otimizado de integração e entrega contínuas.

1. Builds matriciais: testando em múltiplos JDKs e SOs

Uma das principais tarefas do CI é garantir que seu código Java funcione em todas as plataformas suportadas. Executar testes manualmente no Windows, macOS e Linux com diferentes versões do JDK (11, 17, 21) é um luxo imperdoável. O GitHub Actions oferece uma solução elegante: builds matriciais (matrix builds).

Como funciona

Você define uma matriz de parâmetros (versões do JDK, sistemas operacionais), e o GitHub cria automaticamente um job separado para cada combinação. Todos eles são executados em paralelo.

Exemplo de configuração

name: Java CI Matrixon: [push, pull_request]

jobs:  build:    runs-on: ${{ matrix.os }}    strategy:      matrix:        os: [ubuntu-latest, windows-latest, macos-latest]        java: [11, 17, 21]        exclude:          - os: windows-latest            java: 21  # Exclui JDK 21 no Windows, se não for suportado      fail-fast: false  # Não interrompe os outros jobs se um falhar

    steps:      - uses: actions/checkout@v4      - name: Set up JDK ${{ matrix.java }}        uses: actions/setup-java@v4        with:          java-version: ${{ matrix.java }}          distribution: 'temurin'      - name: Build with Maven        run: mvn -B clean verify --file pom.xml

Pontos-chave:

• strategy.matrix — define as combinações de parâmetros.
• exclude — permite excluir combinações sabidamente não funcionais ou desnecessárias.
• fail-fast: false — se um job falhar, os outros continuam. Isso fornece uma visão completa da compatibilidade.

2. Cache de dependências: acelere o build em 2-3 vezes

Cada execução do pipeline começa com um ambiente limpo. Maven ou Gradle baixam todas as dependências dos repositórios novamente. Isso pode levar de 3 a 5 minutos. O cache resolve esse problema, salvando a pasta ~/.m2/repository (para Maven) ou ~/.gradle/caches (para Gradle) entre as execuções.

O GitHub Actions fornece a ação integrada actions/cache. A chave do cache é formada com base no arquivo de dependências (pom.xml). Se o arquivo não mudou, o cache é restaurado instantaneamente.

Exemplo para Maven

steps:  - uses: actions/checkout@v4

  - name: Cache Maven dependencies    uses: actions/cache@v3    with:      path: ~/.m2/repository      key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}      restore-keys: |        ${{ runner.os }}-maven-

  - name: Set up JDK 17    uses: actions/setup-java@v4    with:      java-version: '17'      distribution: 'temurin'

  - name: Build with Maven    run: mvn -B clean verify --file pom.xml

Importante: O cache deve vir antes da etapa de build. A chave hashFiles('**/pom.xml') garante que o cache seja atualizado apenas quando as dependências mudarem.

3. Execução paralela de testes e artefatos de build

Quando seu projeto contém centenas ou milhares de testes, e