CI/CD para projetos Java: GitHub Actions do A ao Z

Introdução: Por que CI/CD é o padrão do desenvolvimento Java moderno

No mundo do desenvolvimento Java, a velocidade e a qualidade da entrega de código são críticas. Todos os dias, as equipes fazem centenas de alterações e, sem automação, o processo de integração se transforma em caos. CI/CD (Integração Contínua / Entrega Contínua) resolve esse problema: o código é automaticamente compilado, testado e implantado nos servidores.

A ferramenta GitHub Actions é uma solução integrada de CI/CD diretamente no repositório. Ela permite criar pipelines (workflows) em YAML que reagem a push, pull request ou outros eventos. Neste artigo, vamos abordar o ciclo completo de configuração de CI/CD para um projeto Java: desde o build básico até o deploy na nuvem.

Você aprenderá como acelerar o desenvolvimento, evitar erros e automatizar tarefas rotineiras. Vamos lá!

1. Fundamentos do GitHub Actions: estrutura do workflow

O que é GitHub Actions?

GitHub Actions é uma plataforma para automatizar fluxos de trabalho. Um Workflow (fluxo de trabalho) é um conjunto de etapas executadas quando um evento ocorre (por exemplo, um push na branch main). Cada workflow consiste em:

\n
• Event — gatilho (push, pull_request, schedule).
\n
• Jobs — tarefas executadas em máquinas virtuais (runner).
\n
• Steps — ações específicas (executar script, instalar dependências).
\n

Para um projeto Java, um workflow típico inclui: baixar o código, instalar o JDK, compilar com Maven/Gradle, executar testes e publicar artefatos.

Criando o primeiro workflow para Java

Crie na raiz do repositório a pasta .github/workflows/ e o arquivo ci.yml. Aqui está um exemplo mínimo para um projeto Maven:

name: Java CI with Maven\n\non:\n  push:\n    branches: [ main ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n\n    steps:\n    - uses: actions/checkout@v4\n    - name: Set up JDK 17\n      uses: actions/setup-java@v4\n      with:\n        java-version: '17'\n        distribution: 'temurin'\n    - name: Build with Maven\n      run: mvn clean compile\n    - name: Run tests\n      run: mvn test

Este workflow é executado em push ou pull request na main. Ele verifica se o código compila e se os testes passam. Se um teste falhar, o workflow termina com erro e você recebe uma notificação.

2. Configuração avançada: cache, matrizes e artefatos

Cache de dependências

Maven e Gradle baixam as dependências toda vez — isso é lento. O GitHub Actions suporta cache. Adicione uma etapa com actions/cache:

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

A chave do cache é baseada no hash do pom.xml. Se o arquivo não mudou, as dependências são restauradas do cache, reduzindo o tempo de build em 2 a 3 vezes.

Matriz de builds (Matrix Build)

Projetos Java frequentemente testam em várias versões do JDK e sistemas operacionais. Use a estratégia matrix:

jobs:\n  test:\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        java: [11, 17, 21]\n    steps:\n    - uses: actions/checkout@v4\n    - name: Set up JDK ${{ matrix.java }}\n      uses: actions/setup-java@v4\n      with:\n        java-version: ${{ matrix.java }}\n        distribution: 'temurin'\n    - name: Test with Maven\n      run: mvn test

O GitHub criará 3 jobs paralelos — para Java 11, 17 e 21. Isso garante a compatibilidade do código com diferentes versões do JDK.

Salvando artefatos

Após o build, o arquivo JAR pode ser salvo como um artefato para download manual ou uso em um job seguinte:

- name: Upload JAR artifact\n  uses: actions/upload-artifact@v4\n  with