CI/CD para proyectos Go: GitHub Actions nivel avanzado

CI/CD avanzado para proyectos Go con GitHub Actions

La automatización de la compilación, las pruebas y el despliegue es la base del desarrollo moderno en Go. Los pipelines básicos son buenos para empezar, pero cuando el proyecto crece, se requieren técnicas avanzadas: caché de dependencias, trabajos paralelos, compilaciones matriciales para diferentes SO y arquitecturas, publicación de artefactos en Docker Hub y despliegue inteligente. En este artículo, analizaremos cómo configurar GitHub Actions para un proyecto Go a nivel profesional.

1. Caché de módulos Go y binarios

Cada ejecución del pipeline puede descargar decenas de megabytes de dependencias. Para acelerar el proceso, utilizamos el caché integrado de GitHub Actions para go mod y el caché de compilación.

name: Go CI (avanzado)on: [push, pull_request]

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

      - name: Instalación de Go        uses: actions/setup-go@v5        with:          go-version: '1.22'

      - name: Caché 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: Descarga de dependencias        run: go mod download

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

      - name: Pruebas con cobertura        run: go test -v -race -coverprofile=coverage.out ./...

      - name: Compilación del binario        run: go build -o myapp ./cmd/app

La clave hashFiles('**/go.sum') invalida el caché solo cuando cambian las dependencias. El caché de compilación (~/.cache/go-build) guarda los objetos compilados, acelerando la recompilación.

2. Compilaciones matriciales: pruebas con diferentes versiones de Go y SO

Los proyectos Go a menudo deben funcionar en Linux, macOS y Windows, además de soportar varias versiones del lenguaje. La matriz (matrix strategy) permite ejecutar trabajos paralelos para cada combinación.

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: Instalación de Go ${{ matrix.go-version }}        uses: actions/setup-go@v5        with:          go-version: ${{ matrix.go-version }}      - name: Pruebas        run: go test ./...

Este enfoque detecta problemas de compatibilidad en diferentes plataformas. Para Windows, puede ser necesaria una configuración adicional de rutas y saltos de línea. Agregue fail-fast: false para que los demás trabajos continúen incluso si uno falla.

3. Publicación de imagen Docker y GitHub Release

Después de las pruebas exitosas, es lógico publicar los artefactos: la imagen Docker en Docker Hub (o GitHub Container Registry) y el binario en GitHub Release. Veamos ambos escenarios.

Publicación de imagen Docker

Crearemos un trabajo que se ejecute solo después de las pruebas y solo al hacer push a main o al crear una etiqueta.

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: Inicio de sesión en Docker Hub        uses: docker/login-action@v3        with:          username: ${{ secrets.DOCKER_USERNAME }}          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Compilación y push de la imagen        uses: docker/build-push-action@v5        with:          context: .          push: true          tags: |            ${{ secrets.DOCKER_USERNAME }}/myapp:latest            ${{ secrets.DOCKER_USERNAME }}/myapp:${{ github.sha }}

No ol