CI/CD für Java-Projekte: GitHub Actions

Einführung: Automatisierung der Java-Entwicklung mit GitHub Actions

Moderne Java-Entwicklung ist ohne Automatisierung undenkbar. Manuelle Builds, Tests und Deployments sind nicht nur Zeitverschwendung, sondern auch eine Quelle kritischer Fehler. CI/CD (Continuous Integration / Continuous Deployment) löst dieses Problem, indem es Routineaufgaben in automatische Prozesse verwandelt. Eines der beliebtesten Werkzeuge zur Implementierung von CI/CD ist GitHub Actions.

GitHub Actions ist direkt in GitHub integriert, was es zur idealen Wahl für Java-Projekte macht, die auf dieser Plattform gehostet werden. Es ermöglicht die Erstellung leistungsstarker Pipelines, die bei jedem Push, Pull Request oder nach einem Zeitplan ausgelöst werden. In diesem Artikel werden wir durchgehen, wie man einen vollständigen CI/CD-Zyklus für eine Java-Anwendung einrichtet: vom Build und Test bis zum Deployment. Sie erfahren, wie Sie effektive YAML-Konfigurationen schreiben, Abhängigkeits-Caching nutzen und beliebte Tools wie Maven und Gradle integrieren.

1. Grundlagen von GitHub Actions für Java: Workflow, Jobs und Steps

Bevor wir Code schreiben, ist es wichtig, die Architektur von GitHub Actions zu verstehen. Jede Pipeline wird in einer Datei .github/workflows/*.yml definiert. Die Hauptkomponenten sind:

• Workflow — das ist die Pipeline selbst. Sie enthält einen oder mehrere jobs.
• Jobs — logische Blöcke, die auf einem einzigen Runner (virtuellen Maschine) ausgeführt werden. Jobs können voneinander abhängen.
• Steps — spezifische Befehle innerhalb eines Jobs: Installation des JDK, Ausführen von Maven, Veröffentlichen von Artefakten.

Für Java-Projekte ist der wichtigste Schritt die Einrichtung des Java Development Kit (JDK). GitHub Actions bietet die vorgefertigte Aktion actions/setup-java, die alle gängigen JDK-Distributionen (Oracle, OpenJDK, Adoptium) unterstützt.

name: Java CI/CD Pipeline

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'      - name: Build with Maven        run: mvn clean install --file pom.xml

In diesem Beispiel haben wir einen grundlegenden Workflow erstellt, der bei einem Push oder Pull Request in den Branch main ausgelöst wird. Er verwendet Ubuntu, installiert JDK 17 (Distribution Temurin) und führt einen Maven-Build aus. Dies ist das absolute Minimum für Continuous Integration.

2. Build und Test: Maven, Gradle und Caching

Der Build ist das Herzstück von CI/CD. Es reicht jedoch nicht aus, einfach mvn install auszuführen. In großen Projekten kann das Herunterladen von Abhängigkeiten Minuten dauern. Um den Prozess zu beschleunigen, verwenden Sie Caching. GitHub Actions ermöglicht das Cachen des Verzeichnisses ~/.m2/repository (für Maven) oder ~/.gradle/caches (für Gradle).

Hier ist ein Beispiel mit Caching für Maven:

jobs:  build-and-test:    runs-on: ubuntu-latest    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 and run tests        run: mvn clean verify --file pom.xml

      - name: Upload test results        if: always()        uses: actions/upload-artifact@v4        with:          name: test-results          path: target/surefire-reports/

Beachten Sie das Flag if: always() im Schritt zum Hochladen der Testergebnisse. Es stellt sicher, dass das Artefakt