CI/CD für Java: GitHub Actions von der Einrichtung bis zum Deployment

Einleitung: Warum CI/CD ein Must-have für Java-Entwickler ist

Moderne Java-Entwicklung ist ohne Automatisierung undenkbar. Manuelles Ausführen von Tests, Erstellen von .jar-Dateien und Deployment auf Server kosten Stunden und führen zu menschlichen Fehlern. CI/CD (Continuous Integration / Continuous Deployment) löst dieses Problem: Jeder Commit ins Repository wird automatisch geprüft, gebaut und bei Bedarf in die Produktion gesendet.

GitHub Actions ist ein integriertes GitHub-Tool, mit dem Sie Pipelines direkt im Repository erstellen können. Es ist für öffentliche Projekte kostenlos, lässt sich leicht in Maven/Gradle integrieren und unterstützt Java 8–21. In diesem Artikel behandeln wir den gesamten Zyklus: vom Trigger bei einem Push bis zur Veröffentlichung des Artefakts.

1. Grundlagen von GitHub Actions: Struktur eines Workflows

Ein Workflow ist eine YAML-Datei, die sich in .github/workflows/ befindet. Sie besteht aus:

• Triggern (push, pull_request, schedule);
• Jobs (Aufgaben), die auf virtuellen Maschinen (Runnern) ausgeführt werden;
• Steps (Schritten) innerhalb jedes Jobs.

Für ein Java-Projekt umfasst ein typischer Workflow das Einrichten des JDK, das Ausführen von Maven/Gradle-Tests und das Erstellen des Artefakts.

1.1. Erster Workflow: Testen eines Java-Projekts

Erstellen Sie die Datei .github/workflows/ci.yml mit folgendem Inhalt:

name: Java CI

on:  push:    branches: [ "main" ]  pull_request:    branches: [ "main" ]

jobs:  build:    runs-on: ubuntu-latest

    steps:    - uses: actions/checkout@v4    - name: Set up JDK 17      uses: actions/setup-java@v4      with:        java-version: '17'        distribution: 'temurin'        cache: maven    - name: Build with Maven      run: mvn -B package --file pom.xml    - name: Run tests      run: mvn test

Was hier passiert:

• actions/checkout — klont das Repository;
• setup-java — installiert JDK 17 (Temurin) und cached Maven-Abhängigkeiten;
• mvn package — baut das Projekt und führt Tests aus;
• mvn test — explizites Ausführen der Tests (kann mit package kombiniert werden).

Nach einem Push in main sehen Sie ein grünes Häkchen neben dem Commit – das bedeutet, dass die Pipeline erfolgreich durchgelaufen ist.

2. Erweiterte Konfiguration für Java: Versionsmatrix und Caching

Reale Projekte erfordern oft Tests mit mehreren Java-Versionen. GitHub Actions unterstützt Matrix-Strategien (matrix strategy).

2.1. JDK-Matrix

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

Dieser Ansatz stellt sicher, dass Ihr Code mit den LTS-Versionen von Java kompatibel ist. Die Jobs werden parallel ausgeführt, was Zeit spart.

2.2. Abhängigkeiten-Caching

Wir haben bereits cache: maven angegeben – dies cached automatisch ~/.m2/repository. Für Gradle verwenden Sie cache: gradle. Der Cache beschleunigt den Build um das 2- bis 3-fache.

3. Erstellen und Veröffentlichen von Artefakten (JAR/Docker)

Nach erfolgreichen Tests muss ein fertiges Artefakt erstellt werden. Betrachten wir zwei gängige Szenarien.

3.1. Hochladen einer JAR-Datei als GitHub-Artefakt

jobs:  build:    runs-on: ubuntu-latest    steps:    - uses: actions/checkout@v4    - name: Set up JDK 17      uses: actions/setup-java@v4      with:        java-version: '17'        distribution: 'temurin'    - run: mvn clean package    - name: Upload JAR      uses: actions/upload-artifact@v4      with:```