CI/CD für Java: Erweiterte Konfigurationen von GitHub Actions

Einleitung: Von einfachen Pipelines zu industriellen Lösungen

Eine einfache CI/CD-Pipeline für ein Java-Projekt ist gut. Aber in der realen Entwicklung, wenn das Projekt auf Dutzende von Modulen anwächst und das Team aus mehreren Entwicklern besteht, erfüllt ein einfaches `mvn clean test` nicht mehr die Anforderungen. Es tauchen Fragen auf: Wie kann man den Build beschleunigen? Wie testet man mit verschiedenen JDK-Versionen? Wie organisiert man parallele Testläufe? Wie veröffentlicht man Artefakte automatisch in Docker Hub?

In diesem Artikel behandeln wir fortgeschrittene Techniken zur Konfiguration von GitHub Actions für Java-Projekte. Sie erfahren, wie Sie Ihre Pipeline von einer linearen Schrittfolge in ein leistungsstarkes, paralleles und optimiertes System für kontinuierliche Integration und Bereitstellung verwandeln.

1. Matrix-Builds: Testen mit mehreren JDKs und Betriebssystemen

Eine der Hauptaufgaben von CI ist es, sicherzustellen, dass Ihr Java-Code auf allen unterstützten Plattformen funktioniert. Manuelles Ausführen von Tests unter Windows, macOS und Linux mit verschiedenen JDK-Versionen (11, 17, 21) ist ein unerschwinglicher Luxus. GitHub Actions bietet eine elegante Lösung: Matrix-Builds.

Wie es funktioniert

Sie definieren eine Matrix von Parametern (JDK-Versionen, Betriebssysteme), und GitHub erstellt automatisch einen separaten Job für jede Kombination. Alle werden parallel ausgeführt.

Konfigurationsbeispiel

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  # JDK 21 unter Windows ausschließen, falls nicht unterstützt      fail-fast: false  # Andere Jobs nicht stoppen, wenn einer fehlschlägt

    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

Wichtige Punkte:

• strategy.matrix — definiert die Parameterkombinationen.
• exclude — ermöglicht den Ausschluss bekanntermaßen nicht funktionierender oder unnötiger Kombinationen.
• fail-fast: false — wenn ein Job fehlschlägt, arbeiten die anderen weiter. Dies ergibt ein vollständiges Bild der Kompatibilität.

2. Abhängigkeiten-Caching: Build um das 2- bis 3-fache beschleunigen

Jeder Pipeline-Lauf beginnt in einer sauberen Umgebung. Maven oder Gradle laden alle Abhängigkeiten erneut aus den Repositories herunter. Dies kann 3-5 Minuten dauern. Caching löst dieses Problem, indem es den Ordner ~/.m2/repository (für Maven) oder ~/.gradle/caches (für Gradle) zwischen den Läufen speichert.

GitHub Actions bietet die integrierte Aktion actions/cache. Der Cache-Schlüssel wird basierend auf der Datei mit den Abhängigkeiten (pom.xml) gebildet. Wenn sich die Datei nicht geändert hat, wird der Cache sofort wiederhergestellt.

Beispiel für 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

Wichtig: Das Caching sollte vor dem Build-Schritt erfolgen. Der Schlüssel hashFiles('**/pom.xml') stellt sicher, dass der Cache nur aktualisiert wird, wenn sich die Abhängigkeiten ändern.

3. Parallele Testausführung und Build-Artefakte

Wenn Ihr Projekt Hunderte oder Tausende von Tests enthält und