19 CI/CD-Einbindung (Jenkins, GitLab, GitHub Actions)

Continuous Integration (CI) und Continuous Delivery (CD) sind wesentliche Bestandteile moderner Softwareentwicklung. Sie gewährleisten, dass Code-Änderungen automatisiert gebaut, getestet und bereitgestellt werden. Maven fügt sich hier reibungslos als Build-Werkzeug ein. Im Folgenden zeigen wir, wie Maven in typische CI/CD-Pipelines eingebunden wird, exemplarisch anhand von Jenkins, GitLab und GitHub Actions.

19.1 1. Grundkonzept CI/CD mit Maven

1. Code Commit
   Entwickler pushen Quellcode-Änderungen in ein Versionsverwaltungssystem (z. B. Git).
2. Automatischer Build
   Der CI-Server erkennt neue Commits und startet einen Maven-Build (z. B. mvn clean install).
3. Automatische Tests
   Während des Builds werden Unit-Tests (mvn test) und ggf. Integrationstests (mvn verify) ausgeführt.
4. Bereitstellung (Deployment)
   Je nach Workflow werden fertige Artefakte (JAR, WAR) in ein Artefakt-Repository oder direkt in eine Zielumgebung (z. B. Staging-Server) deployt.
5. Feedback
   Entwickler erhalten sofort Rückmeldung (Erfolg/Misserfolg), was kurze Reaktionszeiten ermöglicht.

19.2 2. Jenkins Integration

19.2.1 2.1 Jenkins-Job erstellen

1. Neues Freestyle-Projekt (oder Pipeline) in Jenkins konfigurieren.
2. Quellcode-Management: Git-Repository angeben, Jenkins holt automatisch den Code.
3. Build: Unter „Build“ z. B. Invoke top-level Maven targets auswählen oder einen „Pipeline“-Build mit Jenkinsfile konfigurieren.

19.2.2 2.2 Beispiel: Jenkinsfile (Pipeline-Syntax)

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git url: 'https://git.example.com/myrepo.git', branch: 'main'
            }
        }
        stage('Build') {
            steps {
                sh 'mvn clean install'
            }
        }
        stage('Test') {
            steps {
                // Tests werden meist schon in 'clean install' enthalten sein
                // Optional: sh 'mvn test'
            }
        }
        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh 'mvn deploy'
            }
        }
    }
}

• Checkout: Holt Quellcode aus Git.
• Build: Führt mvn clean install aus.
• Test: Könnte separat ausgeführt werden, wenn man z. B. Unit-Tests vom Integrationstest trennt.
• Deploy: Nur auf dem main Branch wird in ein zentrales Repository deployt.

19.2.3 2.3 Best Practices für Jenkins und Maven

• Parallelisierung: Jenkins kann Multi-Module-Projekte parallel bauen, wenn Maven das unterstützt (-T Option).
• Umgang mit Credentials: Deployment-Zugangsdaten sicher im Jenkins Credential Store ablegen.
• Nachverfolgbarkeit: Build-Nr. und Git-Commit in POM (z. B. via Versions-Plugin) integrieren, um Releases rückverfolgbar zu machen.

19.3 3. GitLab CI

19.3.1 3.1 .gitlab-ci.yml Grundlagen

In GitLab werden CI/CD-Pipelines meist über eine .gitlab-ci.yml Datei im Projekt konfiguriert. Wenn GitLab neue Commits erkennt, startet es einen Build entsprechend der definierten Stages.

19.3.2 3.2 Beispiel .gitlab-ci.yml

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  image: maven:3.8.7-openjdk-17
  script:
    - mvn clean compile

test-job:
  stage: test
  image: maven:3.8.7-openjdk-17
  script:
    - mvn test

deploy-job:
  stage: deploy
  image: maven:3.8.7-openjdk-17
  only:
    - main
  script:
    - mvn deploy

• stages: Definiert die Reihenfolge (build → test → deploy).
• image: Container-Image mit vorinstalliertem Maven und Java.
• script: Die Maven-Kommandos, die in den jeweiligen Stages ausgeführt werden.

19.3.3 3.3 Umgebungskonfiguration und Secrets

• Variables: In GitLab können Variablen (z. B. MVN_SETTINGS_XML) gesetzt werden, um benutzerdefinierte settings.xml einzubinden.
• Secrets: Zugangsdaten für Repositories sollten als geschützte Variablen hinterlegt werden.

19.3.4 3.4 Best Practices

• Cache: GitLab bietet Caching-Mechanismen (z. B. für das .m2 Repository), um Builds zu beschleunigen.
• Branch-Regeln: Deployments nur von bestimmten Branches (z. B. main, release) zulassen.
• SonarQube & Co: Integrieren von Code-Qualitätsanalysen in eigenen Stages (z. B. quality).

19.4 4. GitHub Actions

19.4.1 4.1 Workflow-Konzept

GitHub Actions speichert CI/CD-Konfigurationen in .github/workflows/<filename>.yml. Jeder Push, Pull Request oder Tag-Event kann eine definierte Pipeline auslösen.

19.4.2 4.2 Beispiel: Maven-Workflow

name: Java Maven Build

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

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: 17

      - name: Build with Maven
        run: mvn clean install

      - name: Deploy (only on main branch)
        if: github.ref == 'refs/heads/main'
        run: mvn deploy

• on: Gibt an, bei welchen Events (z. B. Push, Pull Request) der Workflow gestartet wird.
• steps: Jede Stufe wird nacheinander ausgeführt.
• if: Bedingte Ausführung (z. B. Deploy nur auf main).

19.4.3 4.3 Erweiterungen

• Caching:

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

  Beschleunigt den Build, da Dependencies nicht jedes Mal neu heruntergeladen werden.

• Integration mit GitHub Packages: Direktes Deploy in GitHub Packages.

• Secrets / Encrypted Variables: In den Repository Settings hinterlegen (z. B. DEPLOY_USERNAME, DEPLOY_PASSWORD).

19.4.4 4.4 Best Practices

• Matrix Builds: Mit GitHub Actions lassen sich verschiedene Java-Versionen testen (z. B. 8, 11, 17).
• Automatische Releases: Tag-Events triggern, um das Maven Release Plugin aufzurufen.

19.5 5. Gemeinsame Best Practices

1. Trennung von Build und Deploy:
   • Build und Test sollten in jeder Pipeline durchlaufen.
   • Deployment nur ausführen, wenn bestimmte Bedingungen erfüllt sind (z. B. Pull-Request akzeptiert, Branch = main).
2. Sensible Daten schützen
   • Credentials, Repository-Keys, Passwörter niemals im Klartext in der YAML/Pipeline.
   • CI-Systeme (Jenkins, GitLab, GitHub) bieten eigene Mechanismen zum Umgang mit Secrets.
3. Consistency Check
   • Prüfen, ob die lokale Maven-Konfiguration (Profil, Java-Version) mit der Pipeline übereinstimmt.
4. Parallelisierung
   • Große Multi-Module-Projekte können beschleunigt werden, indem Teilmodule parallel gebaut werden (mvn -T 1C).
5. Snapshots vs. Releases
   • Klare Trennung in CI/CD, wann SNAPSHOT-Versionen getestet werden und wann ein Release ansteht (z. B. via Maven Release Plugin).

19.6 6. Fazit

Ob Jenkins, GitLab oder GitHub Actions – Maven lässt sich in jeder CI/CD-Umgebung effizient integrieren. Entscheidend ist eine klare Struktur der Pipeline:

• Checkout des Codes
• Build und Test (z. B. mvn clean install)
• (Optionale) Code-Analyse und Qualitätschecks
• Deploy ins Remote-Repository (sofern gewünscht)

Durch die konsequente Anwendung von CI/CD wird jeder Code-Änderungsprozess transparenter und fehlerärmer. Maven’s Fähigkeit, Builds reproduzierbar und standardisiert abzuwickeln, macht es zu einem essenziellen Werkzeug in jeder automatisierten Pipeline.