CI/CD für Java-Projekte: GitHub Actions von A bis Z

Einleitung: Warum CI/CD der Standard moderner Java-Entwicklung ist

In der Welt der Java-Entwicklung sind Geschwindigkeit und Qualität der Codeauslieferung entscheidend. Jeden Tag nehmen Teams hunderte von Änderungen vor, und ohne Automatisierung wird der Integrationsprozess zum Chaos. CI/CD (Continuous Integration / Continuous Deployment) löst dieses Problem: Der Code wird automatisch gebaut, getestet und auf Servern bereitgestellt.

Das Tool GitHub Actions ist eine integrierte CI/CD-Lösung direkt im Repository. Es ermöglicht die Erstellung von Pipelines (Workflows) in YAML, die auf Push, Pull Request oder andere Ereignisse reagieren. In diesem Artikel gehen wir den gesamten Zyklus der CI/CD-Einrichtung für ein Java-Projekt durch: vom grundlegenden Build bis zum Deployment in die Cloud.

Sie erfahren, wie Sie die Entwicklung beschleunigen, Fehler vermeiden und Routineaufgaben automatisieren können. Los geht's!

1. Grundlagen von GitHub Actions: Struktur eines Workflows

Was ist GitHub Actions?

GitHub Actions ist eine Plattform zur Automatisierung von Arbeitsabläufen. Ein Workflow ist eine Reihe von Schritten, die bei einem Ereignis ausgeführt werden (z. B. Push in den main-Branch). Jeder Workflow besteht aus:

\n
• Event — Auslöser (push, pull_request, schedule).
\n
• Jobs — Aufgaben, die auf virtuellen Maschinen (Runner) ausgeführt werden.
\n
• Steps — konkrete Aktionen (Skript ausführen, Abhängigkeiten installieren).
\n

Für ein Java-Projekt umfasst ein typischer Workflow: Code auschecken, JDK installieren, Maven/Gradle-Build ausführen, Tests starten und Artefakte veröffentlichen.

Erstellen des ersten Workflows für Java

Erstellen Sie im Stammverzeichnis des Repositorys den Ordner .github/workflows/ und die Datei ci.yml. Hier ist ein minimales Beispiel für ein Maven-Projekt:

name: Java CI with Maven\n\non:\n  push:\n    branches: [ main ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n\n    steps:\n    - uses: actions/checkout@v4\n    - name: Set up JDK 17\n      uses: actions/setup-java@v4\n      with:\n        java-version: '17'\n        distribution: 'temurin'\n    - name: Build with Maven\n      run: mvn clean compile\n    - name: Run tests\n      run: mvn test

Dieser Workflow wird bei Push oder Pull Request in main ausgelöst. Er prüft, ob der Code kompiliert und die Tests bestanden werden. Wenn ein Test fehlschlägt, wird der Workflow mit einem Fehler beendet und Sie erhalten eine Benachrichtigung.

2. Erweiterte Konfiguration: Caching, Matrizen und Artefakte

Caching von Abhängigkeiten

Maven und Gradle laden jedes Mal Abhängigkeiten neu herunter – das ist langsam. GitHub Actions unterstützt Caching. Fügen Sie einen Schritt mit actions/cache hinzu:

- name: Cache Maven packages\n  uses: actions/cache@v4\n  with:\n    path: ~/.m2/repository\n    key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}\n    restore-keys: |\n      ${{ runner.os }}-maven-

Der Cache-Schlüssel basiert auf dem Hash der pom.xml. Wenn sich die Datei nicht geändert hat, werden die Abhängigkeiten aus dem Cache wiederhergestellt, wodurch sich die Build-Zeit um das 2- bis 3-fache verkürzt.

Matrix-Builds

Java-Projekte werden oft mit mehreren JDK-Versionen und Betriebssystemen getestet. Verwenden Sie die matrix-Strategie:

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

GitHub erstellt 3 parallele Jobs – für Java 11, 17 und 21. Dies gewährleistet die Kompatibilität des Codes mit verschiedenen JDK-Versionen.

Artefakte speichern

Nach dem Build kann die JAR-Datei als Artefakt gespeichert werden, um sie manuell herunterzuladen oder im nächsten Job zu verwenden:

- name: Upload JAR artifact\n  uses: actions/upload-artifact@v4\n  with