CI/CD für Go-Projekte: GitHub Actions Fortgeschrittenenstufe

Fortgeschrittenes CI/CD für Go-Projekte mit GitHub Actions

Die Automatisierung von Build, Test und Deployment ist die Grundlage moderner Go-Entwicklung. Basis-Pipelines sind gut für den Start, aber wenn das Projekt wächst, sind fortgeschrittene Techniken erforderlich: Caching von Abhängigkeiten, parallele Jobs, Matrix-Builds für verschiedene Betriebssysteme und Architekturen, Veröffentlichung von Artefakten in Docker Hub und intelligentes Deployment. In diesem Artikel werden wir behandeln, wie man GitHub Actions für ein Go-Projekt auf professionellem Niveau konfiguriert.

1. Caching von Go-Modulen und Binärdateien

Jeder Pipeline-Durchlauf kann Dutzende Megabyte an Abhängigkeiten herunterladen. Um den Prozess zu beschleunigen, verwenden wir das integrierte Caching von GitHub Actions für go mod und den Build-Cache.

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

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

      - name: Go installieren        uses: actions/setup-go@v5        with:          go-version: '1.22'

      - name: Go-Module cachen        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: Abhängigkeiten herunterladen        run: go mod download

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

      - name: Tests mit Coverage        run: go test -v -race -coverprofile=coverage.out ./...

      - name: Binary bauen        run: go build -o myapp ./cmd/app

Der Schlüssel hashFiles('**/go.sum') macht den Cache nur bei Änderungen der Abhängigkeiten ungültig. Der Build-Cache (~/.cache/go-build) speichert kompilierte Objekte und beschleunigt so Neubuilds.

2. Matrix-Builds: Testen mit verschiedenen Go-Versionen und Betriebssystemen

Go-Projekte müssen oft unter Linux, macOS und Windows laufen und mehrere Sprachversionen unterstützen. Die Matrix-Strategie ermöglicht das Ausführen paralleler Jobs für jede Kombination.

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: Go ${{ matrix.go-version }} installieren        uses: actions/setup-go@v5        with:          go-version: ${{ matrix.go-version }}      - name: Tests        run: go test ./...

Dieser Ansatz deckt Kompatibilitätsprobleme auf verschiedenen Plattformen auf. Für Windows kann eine zusätzliche Konfiguration von Pfaden und Zeilenumbrüchen erforderlich sein. Fügen Sie fail-fast: false hinzu, damit die anderen Jobs weiterlaufen, auch wenn einer fehlschlägt.

3. Veröffentlichung von Docker-Image und GitHub Release

Nach erfolgreichem Testen ist es sinnvoll, Artefakte zu veröffentlichen: ein Docker-Image in Docker Hub (oder GitHub Container Registry) und ein Binary in GitHub Release. Betrachten wir beide Szenarien.

Veröffentlichung des Docker-Images

Erstellen wir einen Job, der nur nach den Tests und nur bei einem Push in main oder bei der Erstellung eines Tags ausgeführt wird.

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: Bei Docker Hub anmelden        uses: docker/login-action@v3        with:          username: ${{ secrets.DOCKER_USERNAME }}          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Image bauen und pushen        uses: docker/build-push-action@v5        with:          context: .          push: true          tags: |            ${{ secrets.DOCKER_USERNAME }}/myapp:latest            ${{ secrets.DOCKER_USERNAME }}/myapp:${{ github.sha }}

Nicht ve