CI/CD para projetos Go: GitHub Actions nível avançado

CI/CD Avançado para projetos Go com GitHub Actions

A automação de build, teste e deploy é a base do desenvolvimento Go moderno. Pipelines básicos são bons para começar, mas quando o projeto cresce, são necessárias técnicas avançadas: cache de dependências, jobs paralelos, builds matriciais para diferentes SOs e arquiteturas, publicação de artefatos no Docker Hub e deploy inteligente. Neste artigo, vamos abordar como configurar o GitHub Actions para um projeto Go em nível profissional.

1. Cache de módulos Go e binários

Cada execução do pipeline pode baixar dezenas de megabytes de dependências. Para acelerar o processo, usamos o cache embutido do GitHub Actions para go mod e o cache de build.

name: Go CI (avançado)on: [push, pull_request]

jobs:  build-and-test:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4

      - name: Instalação do Go        uses: actions/setup-go@v5        with:          go-version: '1.22'

      - name: Cache de módulos Go        uses: actions/cache@v4        with:          path: |            ~/go/pkg/mod            ~/.cache/go-build          key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}          restore-keys: |            ${{ runner.os }}-go-

      - name: Download de dependências        run: go mod download

      - name: Linter (golangci-lint)        uses: golangci/golangci-lint-action@v6        with:          version: latest

      - name: Testes com cobertura        run: go test -v -race -coverprofile=coverage.out ./...

      - name: Build do binário        run: go build -o myapp ./cmd/app

A chave hashFiles('**/go.sum') invalida o cache apenas quando as dependências mudam. O cache de build (~/.cache/go-build) mantém objetos compilados, acelerando a recompilação.

2. Builds matriciais: teste em diferentes versões do Go e SOs

Projetos Go frequentemente precisam funcionar em Linux, macOS e Windows, além de suportar várias versões da linguagem. A matriz (matrix strategy) permite executar jobs paralelos para cada combinação.

jobs:  matrix-test:    strategy:      matrix:        go-version: ['1.21', '1.22', '1.23']        os: [ubuntu-latest, macos-latest, windows-latest]    runs-on: ${{ matrix.os }}    steps:      - uses: actions/checkout@v4      - name: Instalação do Go ${{ matrix.go-version }}        uses: actions/setup-go@v5        with:          go-version: ${{ matrix.go-version }}      - name: Testes        run: go test ./...

Essa abordagem revela problemas de compatibilidade em diferentes plataformas. Para Windows, pode ser necessária configuração adicional de caminhos e quebras de linha. Adicione fail-fast: false para que os outros jobs continuem, mesmo se um falhar.

3. Publicação de imagem Docker e GitHub Release

Após testes bem-sucedidos, é lógico publicar artefatos: imagem Docker no Docker Hub (ou GitHub Container Registry) e binário no GitHub Release. Vamos considerar ambos os cenários.

Publicação de imagem Docker

Criaremos um job que é executado apenas após os testes e apenas em push para main ou criação de tag.

jobs:  docker:    needs: [build-and-test]    if: github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/v')    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4

      - name: Login no Docker Hub        uses: docker/login-action@v3        with:          username: ${{ secrets.DOCKER_USERNAME }}          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Build e push da imagem        uses: docker/build-push-action@v5        with:          context: .          push: true          tags: |            ${{ secrets.DOCKER_USERNAME }}/myapp:latest            ${{ secrets.DOCKER_USERNAME }}/myapp:${{ github.sha }}

Não se esqueça de