Integration von Jenkins mit gängigen Tools: Ein praktischer Überblick

Jenkins wird nützlich, wenn es mit den Tools kommunizieren kann, die Ihr Team bereits verwendet: Git für Code, Docker für Images, Test-Frameworks für Feedback und Artefakt-Repositories für Releases. Das Ziel ist nicht, jedes verfügbare Plugin zu installieren. Das Ziel ist, eine klare Pipeline aufzubauen, die Code auscheckt, baut, testet und das Ergebnis veröffentlicht.

Dieser praktische Überblick zeigt, wie Jenkins-Integrationen normalerweise zusammenpassen und wo Teams oft Fehler machen.

Beginnen Sie mit der Versionskontrolle

Die meisten Jenkins-Pipelines beginnen mit einem Git-Checkout. In einem Pipeline-Job kann Jenkins entweder das im Job konfigurierte Repository verwenden und checkout scm ausführen, oder Sie können das Repository in der Jenkinsfile definieren.

Für eine Multibranch-Pipeline reicht dies normalerweise aus:

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
    }
}

Multibranch-Jobs entdecken Branches und Pull-Requests von GitHub, GitLab, Bitbucket oder einem anderen Git-Server, abhängig von den installierten und konfigurierten Plugins.

Für einen einfachen Pipeline-Job sehen Sie möglicherweise einen expliziten Checkout:

git url: 'https://github.com/example/app.git', branch: 'main'

Verwenden Sie Jenkins-Anmeldeinformationen für private Repositories. Setzen Sie keine Tokens in die Repository-URL.

Bevorzugen Sie Webhooks gegenüber Polling

Jenkins kann Git auf Änderungen überwachen, aber Webhooks sind sauberer. Ihr Git-Anbieter sendet Jenkins eine Anfrage, wenn jemand Code pusht oder einen Pull-Request öffnet, und Jenkins startet den passenden Job.

Ein typisches Setup sieht so aus:

Installieren Sie das Jenkins-Plugin für Ihren Git-Anbieter, z. B. GitHub Branch Source oder GitLab Branch Source.
Erstellen Sie einen Multibranch-Pipeline-Job.
Fügen Sie die Repository- oder Organisationsquelle hinzu.
Speichern Sie Anmeldeinformationen in Jenkins Credentials.
Fügen Sie die Webhook-URL in den Einstellungen Ihres Git-Anbieters hinzu.

Polling funktioniert immer noch für eingeschränkte Netzwerke, fügt aber Verzögerung und unnötige Last hinzu.

Docker-Images bauen und pushen

Jenkins kann Docker-Images bauen, solange der Agent, der den Build ausführt, Docker-Zugriff hat. Das kann eine VM mit installiertem Docker sein, ein Kubernetes-Agent mit einem Build-Tool wie Kaniko oder BuildKit oder ein kontrolliertes Docker-Socket-Setup.

Hier ist ein einfacher Docker-Build- und Push-Ablauf:

pipeline {
    agent any

    environment {
        IMAGE = 'registry.example.com/team/app'
    }

    stages {
        stage('Build Image') {
            steps {
                sh 'docker build -t $IMAGE:$BUILD_NUMBER .'
            }
        }

        stage('Push Image') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'registry-login',
                    usernameVariable: 'REGISTRY_USER',
                    passwordVariable: 'REGISTRY_PASSWORD'
                )]) {
                    sh '''
                        echo "$REGISTRY_PASSWORD" | docker login registry.example.com \
                          --username "$REGISTRY_USER" --password-stdin
                        docker push "$IMAGE:$BUILD_NUMBER"
                    '''
                }
            }
        }
    }
}

Das wichtige Detail ist --password-stdin. Es vermeidet die Offenlegung des Registry-Passworts in der Befehlszeile und ist sicherer als docker login -p.

Tests ausführen und Ergebnisse veröffentlichen

Jenkins muss Ihr Test-Framework nicht verstehen, um es auszuführen. Es benötigt Ihren Build-Befehl, um ein Berichtsformat zu erzeugen, das Jenkins lesen kann.

Für ein Maven-Projekt mit JUnit-kompatiblen XML-Berichten:

pipeline {
    agent any

    stages {
        stage('Test') {
            steps {
                sh 'mvn test'
            }
            post {
                always {
                    junit 'target/surefire-reports/*.xml'
                }
            }
        }
    }
}

Der post { always { ... } }-Block ist wichtig. Er veröffentlicht Testergebnisse auch dann, wenn Tests fehlschlagen, sodass Sie die Fehler in der Jenkins-Benutzeroberfläche sehen können.

Python-, JavaScript- und Go-Projekte können dasselbe Muster verwenden, wenn sie kompatible Berichte ausgeben. Zum Beispiel führen viele Python-Teams pytest --junitxml=reports/junit.xml aus und veröffentlichen dann reports/junit.xml.

Build-Ausgaben in einem Artefakt-Repository speichern

Behandeln Sie einen Jenkins-Arbeitsbereich nicht als Langzeitspeicher. Arbeitsbereiche sind temporär und können verschwinden, wenn Agenten bereinigt werden.

Verwenden Sie ein Artefakt-Repository wie Nexus, Artifactory, eine Container-Registry oder Cloud-Objektspeicher für Release-Ausgaben. Jenkins kann kleine Diagnosedateien mit archiveArtifacts archivieren, aber Produktionspakete sollten in ein System gehen, das für Aufbewahrung und Zugriffskontrolle ausgelegt ist.

Beispiel für das Aufbewahren von Build-Logs oder Berichten mit dem Lauf:

post {
    always {
        archiveArtifacts artifacts: 'reports/**', allowEmptyArchive: true
    }
}

Verwenden Sie dies für Build-Nachweise, nicht als Ihr einziges Release-Repository.

Anmeldeinformationen in Jenkins behalten, nicht in Pipelines

Jenkins Credentials können Benutzernamen, Passwörter, SSH-Schlüssel, Tokens und geheime Dateien speichern. Ihre Pipeline sollte auf eine credentialsId verweisen, nicht auf den geheimen Wert.

Für Shell-Befehle binden Sie Anmeldeinformationen nur um den Schritt, der sie benötigt:

withCredentials([string(credentialsId: 'slack-webhook', variable: 'SLACK_WEBHOOK')]) {
    sh 'curl -X POST -H "Content-type: application/json" --data "{\"text\":\"Build complete\"}" "$SLACK_WEBHOOK"'
}

Halten Sie den Umfang klein. Das verringert die Wahrscheinlichkeit, dass Geheimnisse durch Logs oder spätere Befehle preisgegeben werden.

Nützliche Integrationen, die später hinzugefügt werden können

Sobald die Kern-Pipeline stabil ist, fügen Sie Integrationen basierend auf tatsächlichen Workflow-Anforderungen hinzu:

Tool-Typ	Häufige Verwendung
Git-Anbieter	Branch-Erkennung, Pull-Request-Builds, Commit-Status-Updates
Docker oder Image-Builder	Container-Images bauen und veröffentlichen
Testberichterstattung	Fehler, Trends und flaky Tests anzeigen
Artefakt-Repository	Build-Ausgaben und Release-Pakete speichern
Chat- oder Incident-Tools	Bei fehlgeschlagenen oder veröffentlichten Builds den richtigen Kanal benachrichtigen
Sicherheitsscanner	Abhängigkeiten, Images oder Quellcode vor dem Release prüfen

Fügen Sie jeweils eine Integration hinzu und stellen Sie sicher, dass die Pipeline immer noch klar fehlschlägt. Ein nützliches Jenkins-Setup ist im besten Sinne langweilig: Ein Entwickler pusht Code, Jenkins baut ihn, testet ihn, veröffentlicht das Artefakt und zeigt genau, wo ein Fehler aufgetreten ist.