Jenkins: der CI-Veteran mit 2000+ Plugins, hoher Lernkurve, geringer Modernität

Was ist Jenkins?

Jenkins ist der Veteran der Continuous-Integration-Welt. Das Projekt startete 2004 als Hudson bei Sun Microsystems, wurde 2011 nach dem Oracle-Kauf von Sun zu Jenkins umbenannt und ist seitdem ein eigenständiges Projekt unter der MIT-Lizenz. Mittlerweile (Mai 2026) in Version 2.450+ (LTS-Linie) – eine sehr lange Geschichte, eine sehr grosse Community, ein sehr breiter Plugin-Marketplace mit über 2000 Einträgen.

Lizenz: MIT – vollständig frei, vollständig self-host. CloudBees als Haupt-Sponsor bietet eine kommerzielle CloudBees CI an, aber das OSS-Jenkins ist nicht limitiert.

Architektur: Jenkins ist eine Java-Anwendung (läuft in einem Servlet-Container oder als standalone WAR). Master/Controller-Knoten orchestriert, Agents (Build-Slaves) führen Jobs aus. Konfiguration historisch über die UI (Job-Konfigurations-XMLs auf der Disk), modern über Jenkinsfile (Groovy-DSL) im Repo.

Plugin-System: das Kern-Argument für und gegen Jenkins. 2000+ Plugins decken praktisch jede denkbare Integration ab – Git, Slack, Jira, Docker, Kubernetes, AWS, Azure, GCP, Selenium, SonarQube, Nexus, Artifactory, und tausende mehr. Aber: Plugin-Qualität variiert stark, viele sind unmaintained, viele haben Security-Vulnerabilities. Plugin-Updates müssen sorgfältig getestet werden.

Jenkinsfile: seit ca. 2016 die moderne Konfigurations-Art. Eine Groovy-DSL-Datei im Repo definiert die Pipeline. Sehr flexibel (vollständige Groovy-Sprache verfügbar), aber auch komplexer Lernkurve als YAML-basierte Konkurrenten (GitLab CI, Gitea Actions, Woodpecker). Pipelines können scripted (imperativ) oder declarative (deklarativ) geschrieben werden – declarative ist Standard 2026.

Mai 2026 Verdict: Jenkins ist nicht tot, aber nicht modern. Wer ihn bereits betreibt mit hunderten Jenkinsfiles, sollte bleiben – Migration zu YAML-CI ist Aufwand ohne sofortigen Mehrwert. Wer 2026 neu beginnt, sollte zu Woodpecker, Gitea Actions, GitLab CI oder GitHub Actions greifen. Jenkins ist die "legacy by choice" – gerechtfertigt nur bei sehr spezifischen Plugin-Anforderungen, Compliance-Vorgaben, oder bestehendem Jenkins-Know-how im Team.

Warum es (noch) zählt

Jenkins ist nicht das Tool, das ein KMU 2026 neu einführt. Aber es ist das Tool, das viele KMU bereits haben – oft seit 8 oder 10 Jahren, mit hunderten Jenkinsfiles, mit Plugin-Konfigurationen, mit Build-Agent-Setups. Diese Realität zu ignorieren, wäre unfair.

Bestands-Realität: Wir sehen Jenkins regelmässig in Mandaten – ein Treuhand-Büro mit 5 internen Tools, alle über Jenkins gebaut seit 2018. Eine Anwaltskanzlei mit einer eigenen Mandanten-Plattform, deren Build-Pipeline seit 2020 in Jenkinsfile-Groovy steht. Ein Industrie-Mittelstand mit komplexen Cross-Platform-Builds (Linux + Windows + macOS-Agents), die in Jenkins zentral orchestriert werden. Migration zu YAML-CI wäre Wochen Arbeit, ohne dass der Endkunde einen Vorteil sieht.

CH-DSG-Fit: vollständig erfüllbar. Jenkins self-host auf Hetzner Falkenstein, alle Daten on-premise, MIT-Lizenz ohne US-Cloud-Bindung. Aus DSG-Sicht ist Jenkins unproblematisch.

Plugin-Macht als Argument: Wenn ein KMU-Bedarf sehr spezifisch ist (z.B. SonarQube-Integration plus Selenium-Grid plus Nexus-Artifact-Publishing plus Slack-Approval-Gate plus Jira-Integration), kann Jenkins das alles in einem Workflow abbilden. YAML-CI-Konkurrenten müssten das über externe Tools lösen. Für Mandate mit dieser Komplexität ist Jenkins die rationale Wahl.

Lernkurve als Realität: Groovy-DSL ist eine eigene Welt. Jenkinsfile-Pipelines zu schreiben braucht Wissen, das nicht überall verbreitet ist. Bei einem Personalwechsel ist der neue Mitarbeiter oft nicht produktiv ohne Einarbeitung. YAML-Pipelines (Woodpecker, GitLab CI) sind universeller verständlich.

Sicherheits-Realität: Jenkins-Master mit Plugin-Berechtigung auf System-Niveau ist ein attraktives Angriffsziel. CVE-Watch ist Pflicht – Jenkins veröffentlicht jede Woche Sicherheits-Advisories für Plugins. Wer Jenkins betreibt, muss ein Update-Verfahren etabliert haben.

Mai 2026 Realismus: Jenkins wird nicht "sterben". Aber die Investment-Energie geht in moderne Tools. Wer heute frei wählen kann: bei Woodpecker, GitLab CI, oder GitHub Actions bleiben. Wer Jenkins hat: bleiben, aktualisieren, langfristig auf YAML-CI migrieren wenn die Gelegenheit kommt.

Wie es funktioniert

Jenkins läuft als Java-Anwendung. Standard-Setup: ein Controller plus N Agents.

docker-compose.yml-Beispiel (vereinfacht):

```yaml services: jenkins: image: jenkins/jenkins:lts-jdk17 user: root ports: - "8080:8080" - "50000:50000" volumes: - jenkins-data:/var/jenkins_home - /var/run/docker.sock:/var/run/docker.sock environment: JAVA_OPTS: "-Djenkins.install.runSetupWizard=false" JENKINS_OPTS: "--prefix=/jenkins" restart: unless-stopped jenkins-agent: image: jenkins/inbound-agent:latest environment: JENKINS_URL: http://jenkins:8080/jenkins JENKINS_AGENT_NAME: docker-agent-01 JENKINS_SECRET: ${AGENT_SECRET} depends_on: [jenkins] restart: unless-stopped volumes: jenkins-data: ```

Nach dem ersten Start: Initial-Admin-Passwort aus jenkins-data/secrets/initialAdminPassword auslesen, Browser auf http://server:8080, Plugin-Auswahl durchklicken (Standard-Set ist empfohlen), Admin-User anlegen.

Pipeline-Beispiel (Jenkinsfile, declarative):

```groovy pipeline { agent { docker { image "node:20" } } stages { stage("Build") { steps { sh "npm ci" sh "npm run build" } } stage("Test") { steps { sh "npm test" } post { always { junit "test-results/*.xml" } } } stage("Deploy") { when { branch "main" } steps { withCredentials([sshUserPrivateKey(credentialsId: "deploy-key", keyFileVariable: "SSH_KEY")]) { sh "ssh -i $SSH_KEY deploy@server \"cd /app && git pull && pm2 restart all\"" } } } } post { failure { mail to: "[email protected]", subject: "Build failed: ${env.JOB_NAME}" } } } ```

Credentials-Management: in Jenkins über den Credentials-Store. Verschiedene Typen (Username/Password, SSH-Key, Secret-File, Cert). Per Job oder global. Plugin "Credentials Binding" exponiert sie als ENV-Variablen oder Files.

Plugin-Pflege: Update-Center in der UI. Empfehlung: Plugin-Updates monatlich prüfen, in einem Staging-Jenkins-Setup testen, dann in Produktion übernehmen. CVE-Mailingliste abonnieren (jenkinsci-advisories).

Backup: JENKINS_HOME-Verzeichnis (Standard /var/jenkins_home) komplett sichern. Enthält Job-Konfigurationen, Build-Historien, Plugins, Credentials (verschlüsselt mit Master-Key). Cron daily plus Off-Site-Kopie via rsync. Restore: Verzeichnis zurückkopieren, Jenkins-Image starten, fertig.

Setup in 5 Schritten (oder Migration weg)

1. 01Prüfen ob Neuanlage nötig – Mai 2026 ist Woodpecker, GitLab CI oder Gitea Actions die strategischere Wahl. Bestehendes Jenkins bleiben, neue Setups YAML-CI.
2. 02Falls Jenkins weiterhin: docker-compose mit jenkins/jenkins:lts-jdk17 starten, JENKINS_HOME-Volume persistieren, Initial-Admin-Passwort sichern.
3. 03Minimum-Plugin-Set installieren: Git, Pipeline, Credentials, Docker, Email-Extension, Mailer. Plugin-Inflation vermeiden – jede Plugin-Installation ist potenzielle CVE-Quelle.
4. 04Erste Pipeline als Jenkinsfile im Repo anlegen, Multibranch-Pipeline-Job in Jenkins konfigurieren, Webhook im Git-Hoster für Push-Trigger setzen.
5. 05CVE-Watching aktivieren: jenkinsci-advisories Mailingliste abonnieren, monatlich Plugin-Updates in Staging testen, Backup von JENKINS_HOME täglich.

Wann Jenkins (noch) einsetzen

Jenkins ist Mai 2026 die richtige Wahl in spezifischen Konstellationen: (a) bestehendes Jenkins-Setup mit hunderten Jenkinsfiles – Migration ist Aufwand ohne sofortigen Mehrwert, (b) sehr spezifische Plugin-Anforderungen, die in YAML-CI nicht abgebildet werden können (z.B. komplexe Cross-Platform-Build-Matrix mit Windows-Slaves), (c) Jenkins-Know-how im Team tief verankert – Lernkurve für YAML-CI würde Productivity-Verlust bedeuten, (d) Compliance-Vorgaben verlangen Jenkins explizit (selten, aber existent in einigen Banken-Audits).

Konkrete Fälle: Ein Industrie-Mittelständler mit 50 Build-Jobs, von denen 20 Windows-spezifisch sind und Selenium-Grid plus Nexus-Artifact-Publishing nutzen – Jenkins bleibt. Eine SaaS-Plattform mit komplexer Multi-Cloud-Deployment-Pipeline (AWS plus Azure plus GCP-Targets in einer Pipeline), die über Jenkins-Pipeline-Library zentralisiert ist – Migration zu YAML-CI wäre Wochen ohne Mehrwert.

Für KMU mit Standard-Web-Apps und einfachen Pipelines: nicht Jenkins. Stattdessen Gitea Actions, Woodpecker oder GitLab CI.

Bei Fairlane läuft Woodpecker, nicht Jenkins. Jenkins-Setup wäre für unsere KMU-typischen Pipelines (Build, Test, Container-Push, SSH-Deploy) Overkill und langsamer im Setup.

Wann NICHT

Jenkins ist die falsche Wahl, wenn (a) das Setup neu gebaut wird Mai 2026 – Woodpecker, GitLab CI oder GitHub Actions sind moderner, (b) das Team unter 5 Entwicklern ist – Lernkurve und Pflegeaufwand stehen in keinem Verhältnis, (c) Container-native Pipelines erwartet werden – Jenkins kann das, ist aber nicht so klar wie Drone-Nachfolger, (d) das Operations-Budget kein wochenliches Plugin-CVE-Watching erlaubt.

Fallen: Plugins ohne Vor-Test in Produktion aktualisieren – Plugin-Updates haben in der Vergangenheit Pipelines kaputt gemacht. Immer in Staging-Jenkins testen. Jenkins-Master direkt ins Internet exponieren – extrem hohes Angriffsziel. Hinter nginx mit IP-Whitelist oder VPN-Pflicht. Jenkinsfile-Pipelines ohne Versionskontrolle (per UI-Konfig) anlegen – Disaster-Recovery wird unmöglich. Immer Jenkinsfile im Repo.

Nicht-empfohlene Muster: Jenkins als zentrales CI für ein KMU-Treuhand-Setup, weil "die anderen es auch haben" – die anderen haben es aus historischen Gründen, nicht aus rationaler Wahl. Plugin-Inflation: jedes "nice-to-have"-Plugin installieren – jede zusätzliche Installation ist eine zusätzliche CVE-Quelle. Minimum-Plugin-Set anstreben. Build-Agent als Root laufen lassen – Privilegien-Eskalation bei Plugin-Compromise. User-Account mit Docker-Group-Mitgliedschaft.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Jenkins – Documentation · 2026-05
2. Jenkins – LTS release line · 2026-04
3. Jenkins – Security advisories · 2026-05
4. CloudBees – Commercial Jenkins distribution · 2026-03