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

Einführung in CI/CD für Java-Projekte mit GitHub Actions

Moderne Softwareentwicklung ist ohne Automatisierung von Build-, Test- und Deployment-Prozessen nicht mehr möglich. CI/CD (Continuous Integration / Continuous Deployment) ist eine Sammlung von Praktiken, die es Teams ermöglicht, Änderungen schnell und sicher in die Produktion zu bringen. Für Java-Projekte ist eines der praktischsten Tools GitHub Actions – ein integriertes CI/CD-System, das keinen separaten Server erfordert.

In diesem Artikel schauen wir uns an, wie man eine Pipeline für eine Java-Anwendung einrichtet: von der Kompilierung und dem Ausführen von Tests bis zur Veröffentlichung von Artefakten. Sie erfahren, wie Sie Maven, JUnit und GitHub Actions nutzen, um einen zuverlässigen Bereitstellungsprozess zu erstellen.

1. Grundlagen von GitHub Actions: Struktur eines Workflows

GitHub Actions basiert auf Workflows – Konfigurationsdateien im YAML-Format, die im Ordner .github/workflows gespeichert werden. Jeder Workflow besteht aus einem oder mehreren Jobs, die auf virtuellen Maschinen (Runnern) ausgeführt werden.

Für ein Java-Projekt umfasst ein typischer Workflow die folgenden Schritte:

• Checkout – Klonen des Repositorys
• Setup JDK – Installation der benötigten Java-Version
• Cache – Zwischenspeichern von Maven/Gradle-Abhängigkeiten zur Beschleunigung des Builds
• Build & Test – Kompilierung und Ausführung der Tests
• Deploy – Veröffentlichung von Artefakten (optional)

Betrachten wir ein grundlegendes Konfigurationsbeispiel für Java 17 und Maven:

name: Java CI with Maven

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

    - name: Upload JAR artifact      uses: actions/upload-artifact@v4      with:        name: app-jar        path: target/*.jar

Dieser Workflow wird bei jedem Push oder Pull Request in den Branch main ausgelöst. Er baut das Projekt, führt die Tests aus und speichert die JAR-Datei als Artefakt.

2. Erweiterte Konfiguration: Testen und Codequalität

Ein einfacher Build ist nur der Anfang. In realen Projekten ist es wichtig, die Codequalität zu kontrollieren. Fügen wir dem Workflow Schritte für die statische Analyse und die Generierung von Berichten hinzu.

Zuerst binden wir JaCoCo ein, um die Testabdeckung zu messen. Fügen Sie das Plugin in die pom.xml ein:

<plugin>    <groupId>org.jacoco</groupId>    <artifactId>jacoco-maven-plugin</artifactId>    <version>0.8.11</version>    <executions>        <execution>            <goals><goal>prepare-agent</goal></goals>        </execution>        <execution>            <id>report</id>            <phase>test</phase>            <goals><goal>report</goal></goals>        </execution>    </executions></plugin>

Aktualisieren wir nun den Workflow, indem wir eine Überprüfung der Abdeckung und die Veröffentlichung des Berichts hinzufügen:

    - name: Run tests with coverage      run: mvn verify

    - name: Upload JaCoCo report      uses: actions/upload-artifact@v4      with:        name: coverage-report        path: target/site/jacoco/

Man kann auch einen Linter wie Checkstyle oder SpotBugs hinzufügen. Beispiel für Checkstyle:

    - name: Checkstyle      run: mvn checkstyle:check

Diese Schritte helfen dabei, Probleme automatisch zu erkennen,