Jenkins vs GitLab vs GitHub Actions. CI/CD-Tools im Vergleich.
Welches der drei Tools passt, entscheidet der Betrieb, nicht der Funktionsumfang. Jenkins, wenn der Build im eigenen Netz bleiben muss und an Sonderschnittstellen hängt. GitLab CI, wenn Code, Pipeline und Security-Scans aus einer Hand kommen sollen. GitHub Actions, wenn der Code ohnehin auf GitHub liegt. Azure DevOps ordnen wir gesondert ein, weil Microsoft neue Funktionen inzwischen zuerst in GitHub entwickelt. Grundlage sind über 47 CI/CD-Projekte.
AIWelche CI/CD-Tools gibt es und welches passt zu uns?
Für einen Neustart kommen 2026 drei CI/CD-Tools in Frage: Jenkins, GitLab CI und GitHub Actions. Welches davon passt, entscheiden zwei Fragen, nicht die Feature-Liste. Wo liegt Ihr Quellcode? Und wo darf die Pipeline laufen?
Liegt der Code auf GitHub und darf gebaut werden, wo Rechenzeit günstig ist, ist GitHub Actions die kürzeste Strecke. Muss der Build im eigenen Netz bleiben, weil Lizenzserver, Steuerungscode oder ein Air-Gap-Netz daran hängen, bleibt Jenkins die Referenz, mit GitLab self-managed als All-in-One-Alternative.
Die dritte Achse wird am häufigsten unterschätzt: die Total Cost of Ownership. Über die Laufzeit entscheidet nicht der Lizenzpreis, sondern wer die Runner pflegt, wer Plugins aktualisiert und wer nachts drangeht, wenn der Build-Server steht. Die Rechnung steht in Abschnitt 07.
- /01
Jenkins
Der flexibelste CI/CD-Server, läuft komplett im eigenen Netz und auch ohne Internet. Sie zahlen dafür mit Wartung, und zwar jeden Monat.
- /02
GitLab CI
Repository, Pipelines, Registry und Security-Scans in einer Plattform, als SaaS oder self-managed. Der schnellste Weg, wenn ohnehin konsolidiert wird.
- /03
GitHub Actions
Die kürzeste Strecke, wenn der Code auf GitHub liegt. Microsoft entwickelt neue DevOps-Funktionen inzwischen zuerst hier.
Azure DevOps fehlt hier mit Absicht. Es wird weiter gepflegt, neue Funktionen entwickelt Microsoft aber zuerst in GitHub. Wer heute damit arbeitet, findet die Einordnung in Abschnitt 06.
Wo liegt Ihr Code, und wo darf die Pipeline laufen?
Die Matrix ersetzt keine Bewertung, sie kürzt die Kandidatenliste. Wer danach bei zwei Systemen landet, entscheidet über die Pipeline-Syntax, mit der das Team täglich arbeitet (Abschnitt 05), und über die Kosten (Abschnitt 07).
| Ihr Quellcode liegt auf | Pipeline darf in die Cloud | Pipeline bleibt im eigenen Netz |
|---|---|---|
| GitHub oder GitHub Enterprise Cloud | GitHub Actions. Fertige Actions für fast jeden Schritt, kein zweites System, das jemand betreiben muss. | GitHub Enterprise Server mit self-hosted Runnern. Ohne Enterprise-Lizenz bleibt Jenkins daneben die günstigere Antwort. |
| GitLab, als SaaS oder self-managed | GitLab CI. Repository, Registry, Security-Scans und Pipelines in einer Oberfläche. | GitLab self-managed mit eigenen Runnern. Der übliche Weg, wenn Quellcode und Artefakte das Haus nicht verlassen dürfen. |
| Bitbucket, Subversion oder ein gewachsener Mischbestand | GitLab CI, wenn Sie ohnehin konsolidieren wollen. Sonst zahlen Sie die Migration vor dem ersten grünen Build. | Jenkins. Er ist das einzige der drei Systeme, das alle diese Quellen anspricht, ohne dass vorher etwas umgezogen wird. |
| Steuerungscode aus TIA Portal, CODESYS oder einer Embedded-Toolchain | Kommt praktisch nicht vor. Lizenzserver, Dongles und Prüfstände wandern nicht in die Cloud. | Jenkins mit Windows-Agents am Lizenzserver. Die Anwendungsfälle dazu stehen in Abschnitt 09. |
Ist die Toolwahl zwischen Jenkins, GitLab und GitHub bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Warum gibt es kein bestes CI/CD-Tool?
Weil die Toolwahl an Ihrer Umgebung hängt und nicht am Funktionsumfang. Teamgröße, vorhandene Infrastruktur, Branche, Compliance und das, was Ihr Team wirklich beherrscht, entscheiden. Alle drei Plattformen bauen, testen und deployen zuverlässig.
„Welches CI/CD-Tool sollen wir einsetzen?“ Die Frage kommt oft mit einem leisen Unterton von Sorge, sich für Jahre festzulegen. Zu Recht: Entschieden wird sie in einer Stunde am Whiteboard, gelebt wird sie fünf bis zehn Jahre, von einem Team, dessen Alltag in keiner Feature-Matrix auftaucht.
AIGeschrieben von Andreas Schönfeld, Geschäftsführer der Comquent GmbH. Er arbeitet seit 2006 mit Jenkins und CI/CD und hat Teams in beide Richtungen migrieren sehen, von Jenkins zu GitLab und anderthalb Jahre später wieder zurück.
Comquent vergleicht die Plattformen im Betrieb, nicht am Reißbrett. In über 47 CI/CD-Projekten haben wir Jenkins-Instanzen saniert, GitLab-Migrationen begleitet und in Microsoft-Umgebungen den Wechsel zu GitHub Actions vorbereitet, vom Maschinenbauer mit TIA-Portal-Pipelines bis zum Startup, das am Freitag deployt und am Wochenende schläft. Im Kontext Industrial DevOps kommt hinzu, was in den üblichen Vergleichen fehlt: Windows-Build-Agents, Air-Gap-Netze und Toolchains, die es nur als Kommandozeile gibt.
AIQuellen:plugins.jenkins.io GitHub Octoverse 2025 GitHub Actions Pricing 2026 DORA Report 2024
Was können Jenkins, GitLab CI und GitHub Actions im Betrieb?
Alle drei bauen, testen und deployen zuverlässig, sie unterscheiden sich im Betriebsmodell. Jenkins ist ein Server, den Sie selbst betreiben. GitLab CI ist Teil einer Plattform. GitHub Actions ist ein Dienst im Repository.
Was sich 2026 tatsächlich verschiebt, ist nicht die Rangfolge, sondern die Ebene. KI wandert von der IDE in die Pipeline, auf allen drei Plattformen. Das entscheidet selten die erste Toolwahl, aber es entscheidet, wie viel Handarbeit Ihr Team in zwei Jahren noch leistet.
- /01
Jenkins
Der Open-Source-Veteran.
Jenkins kann fast alles. Über 2.300 Plugins und die Controller-Agent-Architektur machen ihn zum flexibelsten CI/CD-Server am Markt, und nach mehr als 15 Jahren ist er der am längsten erprobte. Die Freiheit bezahlen Sie mit Wartung. Wer einmal einen halben Tag mit Plugin-Konflikten verloren hat, weiß, wovon wir reden. Totgesagt wird Jenkins regelmäßig, geliefert wird trotzdem. Die aktuelle LTS 2.580.1 vom 30. September 2026 setzt Java 21 oder 25 voraus, Java 17 läuft seit 2.555.1 nicht mehr. Das Plugin „AI Agent“ aus dem offiziellen Plugin-Verzeichnis führt Coding-Agents wie Claude Code, Codex oder die Gemini CLI als Pipeline-Step aus, mit einer Freigabe vor jedem Werkzeugaufruf und den Token-Kosten je Build. In Umgebungen mit Sonderschnittstellen (SPS, TIA Portal, Embedded) bleibt er meist die erste Wahl.
Stärken- Fast alles konfigurierbar
- Über 2.300 Plugins
- Open Source, keine Bindung an einen Hersteller
- Läuft komplett im eigenen Netz, auch ohne Internet
- Groovy-Pipelines mit Schleifen, Funktionen und Shared Libraries
- Windows-Agents mit Lizenzbindung seit jeher Alltag
Schwächen- Steile Lernkurve, hoher Wartungsaufwand
- Plugin-Kompatibilität kann Probleme bereiten
- Klassische Oberfläche wirkt veraltet
- Skalierung erfordert eigene Infrastruktur
- Kein integriertes Source-Code-Management
- Security-Patches selbst einspielen
Am besten geeignet fürUnternehmen mit heterogenen Umgebungen, On-Premise-Anforderungen und erfahrenen DevOps-Teams. Besonders stark in der industriellen Automatisierung.
- /02
GitLab CI
Die All-in-One-Plattform.
GitLab CI nimmt Ihnen die Frage ab, welche Werkzeuge Sie zusammenstecken müssen. Versionskontrolle, Pipelines, Container-Registry und Security-Scans kommen aus einer Hand, als SaaS oder self-managed im eigenen Rechenzentrum. Genau das schätzen Teams, die produktiv sein wollen, statt Infrastruktur zu pflegen. Seit GitLab 18.8 (Januar 2026) ist die Duo Agent Platform allgemein verfügbar. Der „Fix CI/CD Pipeline Flow“ analysiert fehlgeschlagene Pipelines und schlägt die Korrektur vor, seit 18.10 auch im Free-Tier auf GitLab.com. Ein Security-Analyst-Agent sortiert Befunde vor, bevor sie Ihr Team erreichen. Mit GitLab 19.5 vom 15. Oktober 2026 sind außerdem der MCP-Server und der Secrets Manager allgemein verfügbar. SAST und Dependency Scanning brauchen kein Zusatz-Plugin, die volle Security-Auswertung steckt allerdings in der Ultimate-Stufe.
Stärken- SCM, CI/CD, Registry und Security in einer Plattform
- Einfache YAML-Konfiguration in .gitlab-ci.yml
- Container- und Package-Registry eingebaut
- Security-Scans ohne Zusatzmodule
- Self-managed oder SaaS, freie Wahl
- KI-Agenten für Pipeline-Fehler seit 18.8 allgemein verfügbar
Schwächen- Ressourcenhungrig bei Self-Hosted-Installation
- Weniger Integrationen als Jenkins
- Volle Security-Funktionen nur in Ultimate
- Komplexe Konfiguration bei Multi-Projekt-Pipelines
- Runner-Management bei großen Teams aufwendig
- Starke Bindung, wenn viele Plattform-Funktionen genutzt werden
Am besten geeignet fürTeams, die eine einheitliche Plattform für den gesamten Software-Lebenszyklus wollen, vom Startup bis zum Mittelstand. Self-managed auch dort, wo der Code das Haus nicht verlassen darf.
- /03
GitHub Actions
Der Cloud-native Herausforderer.
GitHub Actions sitzt dort, wo der Code ohnehin liegt, und daraus kommt fast sein ganzer Vorteil. Ein Workflow ist in Minuten geschrieben, der Marketplace hat für nahezu jeden Schritt eine fertige Action, und Microsoft entwickelt neue DevOps-Funktionen inzwischen zuerst hier. Wie stark die Plattform genutzt wird, zeigt der Octoverse-Bericht von GitHub: 11,5 Milliarden Actions-Minuten allein in öffentlichen Projekten im Jahr 2025, 35 % mehr als im Jahr davor. Zum 1. Januar 2026 hat GitHub die Preise der gehosteten Runner um bis zu 39 % gesenkt. Die angekündigte Gebühr für self-hosted Runner wurde verschoben, eingeführt ist sie bis heute nicht. Seit Juni 2026 laufen die Agentic Workflows in der Public Preview, in denen Agenten wie Copilot oder Claude Code in einer Sandbox mit Leserechten arbeiten. Der Haken bleibt: ohne GitHub kein GitHub Actions. On-Premise gibt es nur mit GitHub Enterprise Server, und komplexe Pipeline-Logik stößt an die Grenzen von YAML.
Stärken- Schnellster Einstieg, Workflow direkt im Repository
- Großer Marketplace mit fertigen Actions
- Für öffentliche Repositories kostenlos
- Gehostete Runner seit Januar 2026 bis zu 39 % günstiger
- Hier entwickelt Microsoft neue DevOps-Funktionen zuerst
- Tiefe Integration in Pull Requests, Issues und Copilot
Schwächen- On-Premise nur mit GitHub Enterprise Server
- Workflows nicht auf andere Plattformen portierbar
- Reines YAML, keine echten Schleifen oder Funktionen
- Keine native OT-Anbindung (TIA Portal, PLCSim)
- Build-Minuten bei großen Matrizen schwer planbar
- Sonderhardware nur über self-hosted Runner
Am besten geeignet fürTeams, deren Code auf GitHub liegt und die schnell produktiv sein wollen: Cloud-Startups, Open-Source-Projekte und Microsoft-Umgebungen, die neu starten. Für On-Premise-, Air-Gap- und OT-Szenarien die falsche Adresse.
Belege (Stand Oktober 2026):Jenkins LTS-Changelog Jenkins-Plugin AI Agent GitLab 18.8 (Duo Agent Platform) GitLab 19.5 GitHub Agentic Workflows
Ist Jenkins 2026 noch aktuell?
Ja. Jenkins wird aktiv weiterentwickelt, die letzte LTS 2.580.1 erschien am 30. September 2026, und das Plugin-Verzeichnis zählt über 2.300 Plugins. Geändert hat sich die Rolle. Neue Projekte ohne Sonderanforderungen starten heute meist auf GitHub Actions oder GitLab CI, weil dort niemand einen Server pflegen muss.
Jenkins bleibt dort, wo Builds im eigenen Netz laufen müssen, wo Windows-Agents an einer Lizenz hängen oder wo über Jahre gewachsene Pipelines verlässlich laufen. Veraltet ist in solchen Umgebungen selten das Tool. Veraltet ist meist die Instanz: drei Jahre ohne Update, vierzig Plugins in unbekannten Versionen, die Konfiguration nur in der Oberfläche.
Wie schneiden die Tools in neun Kriterien ab?
Neun Kriterien, nach denen wir in Projekten tatsächlich entscheiden. Die Einträge stammen aus dem Betrieb und aus den Hersteller-Dokumentationen, nicht aus Marketing-Material.
| Kriterium | Jenkins | GitLab CI | GitHub Actions |
|---|---|---|---|
| Installation & Setup | Manuell, per Docker oder Paketmanager | Docker/Helm oder SaaS, schnell produktiv | Kein Setup, Workflow-YAML direkt im Repository |
| Pipeline-Konfiguration | Jenkinsfile (Groovy), mächtig, aber komplex | .gitlab-ci.yml, gut dokumentiert | .github/workflows/*.yml, einfach, aber nur YAML |
| Erweiterbarkeit | Über 2.300 Plugins (Community-gepflegt) | Native Integrationen, CI/CD-Components, eigene Runner | Marketplace mit Community- und Verified-Actions |
| Security (DevSecOps) | Über Plugins (OWASP, SonarQube, Trivy) | SAST, DAST, Container- und Dependency-Scanning eingebaut | CodeQL, Dependabot, Secret Scanning (Advanced Security) |
| Skalierung | Agent-basiert, selbst verwaltet | Autoscaling-Runner, Kubernetes-Integration | Gehostete Runner, self-hosted für Sonderfälle |
| Kosten | Open Source (0 EUR), Infrastruktur ab ca. 50–200 EUR/Monat | Free (400 Compute-Minuten), Premium $29/User/Monat | Free mit 2.000 Minuten/Monat, Team $4/User/Monat |
| On-Premise / Air-Gap | Nativ On-Premise, auch ohne Internet | Self-managed, offline installierbar | Nur über GitHub Enterprise Server |
| Industrial DevOps | TIA Openness, PLCSim, Embedded, breit erprobt | Über self-managed Windows-Runner, mehr Eigenbau | Nur über self-hosted Windows-Runner |
| KI in der Pipeline (2026) | Plugin „AI Agent“: Claude Code, Codex, Gemini CLI als Step | Duo Agent Platform, Fix CI/CD Pipeline Flow, MCP-Server | Agentic Workflows (Public Preview), Copilot Coding Agent |
Jenkins vs GitLab CI: Wann lohnt sich welches Tool?
GitLab CI lohnt sich, wenn Sie Repository, Pipelines und Security-Scans auf einer Plattform zusammenführen wollen. Jenkins lohnt sich, wenn die Builds an Sonderschnittstellen, Windows-Agents mit Lizenzbindung oder viele unterschiedliche Quellsysteme gebunden sind.
Der Unterschied im Alltag liegt im Betrieb. Bei GitLab pflegen Sie Runner, bei Jenkins zusätzlich den Controller und seine Plugins. Dafür schreibt Jenkins seine Pipelines in Groovy, mit Schleifen, Funktionen und Shared Libraries, während GitLab bei YAML und CI/CD-Components bleibt. Läuft Jenkins stabil und ist als Code konfiguriert, ist ein Wechsel selten die beste Investition. Wie er abläuft, wenn er sich lohnt, steht in Abschnitt 10.
Jenkins vs GitHub Actions: Wann welcher Build-Server?
GitHub Actions, wenn der gesamte Code auf GitHub liegt und keine On-Premise-Pflicht besteht. Jenkins, wenn On-Premise-Builds, Industrie-Toolchains wie das TIA Portal oder komplexe Pipeline-Logik gefragt sind.
Bei den Kosten kippt das Bild mit der Last. GitHub Actions rechnet nach Minuten ab, Jenkins nach Server und Admin-Zeit; bei zehn Entwicklern mit fünf Builds am Tag wird ein selbst gehosteter Jenkins nach etwa einem halben Jahr günstiger, sofern ohnehin jemand ihn betreibt. Proprietäre OT-Toolchains laufen auf Windows-Agents mit lokalen Lizenzen, die GitHub Actions nur über self-hosted Runner erreicht, und dann ist der Cloud-Vorteil weg.
In gemischten Setups sehen wir oft beides: GitHub Actions baut die Anwendung, Jenkins steuert die Freigabe in die Anlage.
GitLab vs GitHub: Was unterscheidet die Plattformen?
GitLab ist eine DevOps-Plattform mit eingebauten Security-Scans, Registry und Planung, die Sie auch komplett self-managed betreiben können. GitHub ist das größere Ökosystem mit dem größeren Marketplace, und dort entwickelt Microsoft neue Funktionen zuerst.
Für die Pipeline heißt das: GitLab CI bringt mehr Funktionen ohne Zusatzlizenz mit, GitHub Actions mehr fertige Bausteine aus der Community. Wer On-Premise braucht, bekommt bei GitLab dieselbe Software wie in der Cloud. Bei GitHub ist es der Enterprise Server, und der kostet entsprechend.
Kann man Jenkins und GitLab CI gleichzeitig nutzen?
Ja, und in der Industrie ist das häufig die vernünftigste Lösung. GitLab CI übernimmt die Standard-Pipelines für Web und Cloud, Jenkins die Spezialfälle mit Sonderschnittstellen. Über die GitLab-Jenkins-Integration lassen sich Jenkins-Jobs direkt aus GitLab heraus starten, und die Ergebnisse erscheinen am Merge Request.
Damit das nicht in zwei Welten zerfällt, liegen die Artefakte zentral in Nexus oder Artifactory, und beide Systeme sind als Code konfiguriert.
Wie sieht dieselbe Pipeline in drei Tools aus?
Build, Test und Deploy, wobei das Deployment nur vom Branch main läuft. GitLab CI und GitHub Actions beschreiben das in YAML, Jenkins in einer Groovy-Syntax. Bei so einer Pipeline sind die Unterschiede klein. Groß werden sie, sobald Logik dazukommt.
pipeline {
agent any
stages {
stage('Build') {
steps { sh 'make build' }
}
stage('Test') {
steps { sh 'make test' }
}
stage('Deploy') {
when { branch 'main' }
steps { sh 'make deploy' }
}
}
}stages: [build, test, deploy]
build:
stage: build
script: make build
test:
stage: test
script: make test
deploy:
stage: deploy
script: make deploy
rules:
- if: $CI_COMMIT_BRANCH == "main"on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- run: make build
test:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- run: make test
deploy:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- run: make deployZwei Unterschiede sieht man schon hier. GitHub Actions startet jeden Job auf einer frischen Maschine und muss den Code deshalb dreimal auschecken, die anderen teilen sich den Arbeitsbereich innerhalb einer Stufe oder reichen ihn als Artefakt weiter. Und die Bedingung für das Deployment steht jedes Mal an einer anderen Stelle: als when in Jenkins, als rules in GitLab (das ältere only gilt dort als veraltet) und als if in GitHub.
Wer migriert, überträgt genau solche Stellen von Hand. Bei zwanzig Pipelines mit Schleifen, Shared Libraries und Sonderfällen ist das der Großteil der Arbeit, nicht das Umschreiben der Stufen.
Sollten Sie 2026 noch mit Azure DevOps starten?
Für einen Neustart im Microsoft-Umfeld eher nicht, für bestehende Projekte gibt es keinen Grund zur Eile. Microsoft verlagert seine DevOps-Entwicklung sichtbar zu GitHub. Im Mai 2025 schrieb Microsofts Produktverantwortlicher Aaron Hallberg, jetzt sei der Zeitpunkt, Azure-DevOps-Repositories zu GitHub zu migrieren und dabei Azure Boards und Pipelines weiter zu nutzen. GitHub-Enterprise-Lizenzen enthalten seitdem Nutzungsrechte für Azure DevOps Basic.
Das ist keine Abkündigung. Azure DevOps bekommt Sicherheits- und Funktionsupdates, der Copilot Coding Agent startet seit Dezember 2025 direkt aus Azure Boards, und der Azure DevOps Server ist seit Dezember 2025 als versionsloses Produkt mit fortlaufenden Updates verfügbar. Wer 2026 auf der grünen Wiese startet, sollte diese Richtung trotzdem kennen, bevor er sich für Jahre bindet.
| Kategorie | Azure DevOps (Oktober 2026) |
|---|---|
| Modell | Gewachsene Microsoft-Suite: Pipelines, Repos, Boards, Artifacts, Test Plans |
| Kosten | Die ersten 5 Nutzer frei, danach $6 je Nutzer und Monat. Ein Microsoft-hosted Parallel-Job mit 1.800 Minuten frei, jeder weitere $40/Monat; self-hosted je weiterer Job $15/Monat |
| On-Premise | Azure DevOps Server, seit 09.12.2025 versionslos mit fortlaufenden Updates. Version 2022 im Mainstream-Support bis 11.01.2028 |
| Stärke | Nachverfolgbarkeit vom Work Item bis zum Release, Test Plans, Audit-Trails |
| Richtung 2026 | Wird gepflegt, neue Funktionen entstehen zuerst in GitHub. Copilot Coding Agent aus Azure Boards seit 12/2025 |
| Am besten für | Bestandskunden und regulierte On-Premise-Umgebungen im Microsoft-Stack |
Belege:Microsoft DevOps Blog, 27.05.2025 Copilot für Azure Boards Azure DevOps Preise
Azure DevOps oder GitHub Actions: Was 2026 wählen?
Für neue Projekte im Microsoft-Umfeld GitHub Actions, für laufende Azure-DevOps-Projekte Azure DevOps. Ein Wechsel um des Wechsels willen lohnt sich nicht, ein bewusster Neustart auf GitHub schon.
Beide gehören zu Microsoft, sie sind aber nicht dasselbe Produkt. Azure DevOps ist eine Suite mit Boards, Repos, Pipelines und Test Plans, GitHub eine Plattform um das Repository. Die Kombination ist erlaubt und verbreitet: Code und Pipelines auf GitHub, Planung in Azure Boards.
Azure DevOps vs GitLab: Was ist der Unterschied?
Beide sind komplette Plattformen mit Repository, Pipelines, Planung und Artefakten. GitLab bündelt die Security-Scans und läuft self-managed auf jedem Linux-Server oder in Kubernetes, Azure DevOps ist eng an Microsoft-Konten und Azure gebunden und hat mit Test Plans das stärkere Testmanagement.
Wer konsolidieren und dabei auch ohne Microsoft-Stack On-Premise bleiben will, landet meist bei GitLab. Wer im Microsoft-Stack bleibt, bei Azure DevOps oder GitHub.
Azure DevOps vs Jenkins: Was ist der Unterschied?
Jenkins ist ein reiner CI/CD-Server ohne Repository, Boards oder Testmanagement. Azure DevOps ist eine Suite, in der die Pipelines nur ein Teil sind.
Jenkins gewinnt bei Sonderschnittstellen, Air-Gap-Netzen und Windows-Agents mit Lizenzbindung. Azure DevOps gewinnt bei der Nachverfolgbarkeit vom Work Item bis zum Release. In der Industrie laufen beide oft nebeneinander: Azure Boards hält die Anforderungen, Jenkins baut die Steuerungssoftware und meldet das Ergebnis zurück.
Welche Alternativen gibt es zu Azure DevOps?
Die naheliegendste Alternative ist GitHub mit GitHub Actions, weil Microsoft neue Funktionen dort zuerst entwickelt. Als Plattform ohne Microsoft-Bindung kommt GitLab in Frage, für reine CI/CD-Aufgaben im eigenen Netz Jenkins.
Wer nur die Azure-Cloud verlassen will, muss die Suite gar nicht wechseln: Der Azure DevOps Server läuft im eigenen Rechenzentrum, mit denselben Pipelines und Boards.
Was kosten die Tools wirklich?
Für ein Team mit 20 Personen liegen die Gesamtkosten bei Jenkins bei etwa 13.000 bis 27.000 Euro im Jahr, bei GitLab CI Premium bei 10.500 bis 20.000 und bei GitHub Actions im Team-Plan bei 3.500 bis 7.000. Die Lizenz ist dabei der kleinste Posten. Den Unterschied machen Infrastruktur, Wartung und Schulung.
Der teuerste Posten steht in keiner Tabelle: der Nachmittag, an dem nach einem Plugin-Update die Hälfte der Builds rot ist und niemand mehr weiß, welche der vierzig Plugin-Versionen zuletzt zusammen funktioniert haben.
| Kosten pro Jahr | Jenkins | GitLab CI Premium | GitHub Actions Team |
|---|---|---|---|
| Lizenz | 0 EUR (Open Source) | ca. 7.000 ($29 × 20 × 12) | ca. 960 ($4 × 20 × 12) |
| Infrastruktur | 2.400–6.000 EUR | 0 EUR (SaaS) oder 2.400–4.800 EUR | 0 EUR (SaaS) + Build-Minuten nach Verbrauch |
| Wartung/Admin | 8.000–15.000 EUR (0,5–1 FTE) | 2.000–5.000 EUR (0,1–0,3 FTE) | 1.500–3.500 EUR (0,1–0,2 FTE) |
| Schulung | 3.000–6.000 EUR | 1.500–3.000 EUR | 1.000–2.500 EUR |
| Gesamt (ca.) | 13.400–27.000 EUR | 10.500–19.800 EUR | 3.500–7.000 EUR |
Erfahrungswerte aus Kundenprojekten, je nach Komplexität abweichend. Lizenzpreise laut Herstellerseiten im Oktober 2026 in US-Dollar, in der Summe vereinfacht 1:1 in Euro gerechnet.
Jenkins
Plugin-Updates und Kompatibilitätsprobleme kosten Tage an DevOps-Zeit. Security-Patching liegt komplett bei Ihnen.
GitLab CI
Die volle Security-Auswertung gibt es erst in Ultimate. Self-managed Instanzen brauchen leistungsfähige Server.
GitHub Actions
Build-Minuten summieren sich bei großen Test-Matrizen schnell. Self-hosted Runner für Sonderhardware holen den Betrieb zurück in Ihre Infrastruktur, samt Wartung.
AIWas kosten GitLab und Azure DevOps?
GitLab Premium kostet $29 je Nutzer und Monat bei jährlicher Abrechnung, Azure DevOps ist für die ersten fünf Nutzer frei und kostet danach $6 je Nutzer und Monat.
GitLab Free enthält 400 Compute-Minuten im Monat, Premium 10.000, Ultimate gibt es auf Anfrage. Bei Azure DevOps kommen die Pipelines dazu: ein Microsoft-hosted Job ist frei, jeder weitere parallele Job kostet $40 im Monat, ein weiterer self-hosted Job $15.
Welches CI/CD-Tool ist für kleine Teams bezahlbar?
Für Teams bis fünf Personen ohne Sonderschnittstellen ist eine SaaS-Plattform fast immer am günstigsten. GitHub Free bringt 2.000 Minuten im Monat für private Repositories, GitLab Free 400, und Azure DevOps kostet bis fünf Nutzer keine Lizenz.
Teuer wird es über den Betrieb, nicht über die Lizenz. Ein selbst gehosteter Jenkins für fünf Leute kostet mehr Arbeitszeit als jede dieser Lizenzen.
Sie wollen den Wartungsaufwand ganz abgeben? Wir betreiben Jenkins, GitLab CI, Azure DevOps und ArgoCD für Sie als Managed DevOps & CI/CD Service (DevOps Outsourcing), mit monatlichem Festpreis statt unkalkulierbarer FTE-Kosten.
Welches Tool passt zu welchem Szenario?
Sechs Ausgangslagen, die uns in Projekten am häufigsten begegnen, und was wir dort jeweils empfehlen. Passt keine davon, hilft der Tool-Finder am Ende des Abschnitts mit zwei Fragen.
- /01
Maschinenbau mit TIA Portal
→ JenkinsErprobte Anbindung an TIA Openness und PLCSim über Windows-Agents. Läuft komplett im eigenen Netz, auch in Air-Gap-Umgebungen.
- /02
Startup oder Scale-up mit Cloud-Fokus
→ GitLab CI oder GitHub ActionsSchneller Einstieg ohne eigene Server. Liegt der Code schon auf GitHub, ist Actions die kürzere Strecke; soll alles aus einer Hand kommen, GitLab.
- /03
Enterprise mit Microsoft-Stack
→ GitHub Actions + Azure BoardsMicrosoft entwickelt neue Funktionen vorrangig für GitHub, der Copilot Coding Agent startet seit Dezember 2025 direkt aus Azure Boards. GitHub-Enterprise-Lizenzen enthalten zudem Nutzungsrechte für Azure DevOps Basic. Bestehende Azure-DevOps-Projekte laufen voll unterstützt weiter.
- /04
Regulierte Branche (Pharma, Automotive)
→ GitLab oder Azure DevOps ServerAudit-Trails, Freigabe-Workflows und Nachverfolgbarkeit sind eingebaut. GitLab bei mehreren Clouds oder gemischter Infrastruktur, der Azure DevOps Server in reinen Microsoft-Umgebungen mit strengen Auflagen zur Datenhaltung.
- /05
Heterogene IT- und OT-Umgebung
→ Jenkins + GitLab (Hybrid)Jenkins für OT-Pipelines (SPS, Embedded), GitLab für IT-Pipelines (Web, Cloud). Die Artefakte liegen zentral in Nexus oder Artifactory.
- /06
Quellcode und Artefakte müssen in Deutschland bleiben
→ GitLab self-managed oder JenkinsBeide laufen im eigenen Rechenzentrum oder bei einem deutschen Hoster und halten Code, Artefakte und Build-Protokolle vollständig unter eigener Kontrolle. Bei GitHub Actions und Azure DevOps als SaaS liegen zumindest Metadaten und Protokolle bei Microsoft, das verlangt eine Bewertung nach Art. 28 DSGVO.
AIWelches CI/CD-Tool passt zu Ihrem Team?
Jenkins, GitLab oder Azure DevOps — die beste Wahl hängt weniger am Feature-Vergleich als an Ihrer Infrastruktur. Zwei Klicks zeigen Ihnen das Tool, das zu Ihrer Umgebung passt.
Wo läuft Ihre Infrastruktur überwiegend?
Warum setzt die Industrie so oft auf Jenkins?
Weil Steuerungs- und Embedded-Toolchains unter Windows laufen, an lokalen Lizenzen hängen und oft in Netzen ohne Internetzugang stehen. Jenkins kommt mit allen drei Bedingungen ohne Umweg zurecht.
Industrielle Umgebungen in Maschinenbau, Automotive und Energie bringen dazu Air-Gap-Netze und Compliance nach IEC 62443 mit. Die anderen Plattformen können das auch, über self-hosted Windows-Runner und mehr Eigenbau.
- /01
TIA Portal Openness API
Automatisierte Kompilierung und Export von SPS-Projekten über die Programmierschnittstelle. - /02
PLCSim Advanced
Tests gegen eine simulierte Steuerung in der Pipeline, ohne echte Hardware. - /03
Windows-native Agents
Viele OT-Werkzeuge laufen ausschließlich unter Windows, ihre Lizenz oft auf genau einem Rechner. - /04
Air-Gap-fähig
Jenkins läuft komplett On-Premise ohne Internetzugang, Plugins lassen sich offline einspielen. - /05
IEC 62443 Compliance
Volle Kontrolle über Datenflüsse und Zugriffsrechte, nachweisbar aus der Konfiguration.
In der Praxis empfehlen wir häufig einen Hybrid-Ansatz. Jenkins übernimmt die OT-Pipelines (SPS-Kompilierung, Embedded-Tests), GitLab CI die IT-Pipelines für Web-Anwendungen und Cloud-Deployments. Das ist gelebte IT/OT-Konvergenz, mit zentraler Artefakt-Verwaltung über Nexus oder JFrog Artifactory.
AIIn den drei folgenden Fällen fiel die Tool-Entscheidung nicht am Funktionsumfang, sondern an einer physischen Randbedingung: einer Lizenz, einem Prüfstand, einem Netzsegment. Solche Randbedingungen tauchen in keinem Tool-Vergleich auf, entscheiden aber am Ende.
- /01
Sondermaschinenbau, 40 Anlagentypen
Jenkins, Windows-AgentDer Build braucht das TIA Portal, eine gültige Lizenz und die Openness-API. Beides liegt auf genau einem Windows-Rechner im Haus. Daraus wurde ein fester Build-Agent mit einem Label auf der Lizenz, damit kein zweiter Job den Platz belegt, während der erste kompiliert. GitLab CI hätte dieselbe Aufgabe mit einem self-managed Windows-Runner gelöst. Ausgeschlossen war allein die Cloud, weil die Lizenz nicht mitwandert.
- /02
Steuergeräte-Software im Automotive
Zweistufig, Runner am PrüfstandDer HiL-Prüfstand ist Hardware, und Hardware gibt es einmal. Ein Testlauf dauert Stunden und belegt den Prüfstand exklusiv, also läuft er nachts statt bei jedem Commit. Die Pipeline zerfällt entsprechend: Kompilieren und statische Analyse bei jedem Push, der Prüfstandslauf einmal pro Nacht. Die schwierigere Frage war nicht das Tool, sondern wie ein Testergebnis später dem Requirement zugeordnet wird, das es abdeckt. Danach fragt das ASPICE-Assessment, und zwar für jedes einzelne.
AIDer Prüfstandslauf dauert Stunden. Er läuft nachts, nicht bei jedem Commit. - /03
Serienfertigung unter IEC 62443
Alles im eigenen NetzIm Audit lautet die Frage nicht, welches CI/CD-Tool im Einsatz ist. Sie lautet, welche Verbindungen dieses System in die Produktionszelle öffnet und wer sie freigegeben hat. Wer das aus der Konfiguration heraus beantwortet, ist in einer Stunde durch. Wer erst rekonstruieren muss, wie ein Cloud-Runner an das Zellennetz kam, sitzt zwei Tage daran und hat am Ende trotzdem nur eine Erzählung, keinen Nachweis.
Lohnt sich der Wechsel weg von Jenkins?
Nur, wenn Jenkins ein konkretes Problem verursacht, das sich im bestehenden System nicht lösen lässt. Tool-Migrationen sind teuer, binden ein Team über Monate und lösen kein Betriebsproblem.
Meist geht es um einen Jenkins, den ein früheres Team aufgesetzt hat und den das heutige pflegt, ohne jede Entscheidung darin zu kennen. Oft ist es wirtschaftlicher, ihn als Code neu aufzusetzen, als ihn abzulösen.
Was ist die beste Jenkins-Alternative 2026?
Das hängt vom Einsatzzweck ab. GitLab CI ist die stärkste All-in-One-Alternative, GitHub Actions die Wahl für Teams auf GitHub und für neue Microsoft-Projekte, und Azure DevOps bleibt für Bestands- und On-Premise-Kunden voll unterstützt. Für On-Premise-, Air-Gap- und Industrie-Umgebungen (SPS, TIA Portal, Embedded) ersetzt keine davon Jenkins vollständig.
In Vergleichslisten tauchen zwei weitere Namen auf. Tekton ist ein Kubernetes-natives Framework, aus dem Plattform-Teams eigene CI/CD-Systeme bauen; für eine Werkstatt mit Windows-Agents ist es das falsche Werkzeug. TeamCity von JetBrains ist ein kommerzieller CI-Server, als Cloud-Dienst oder im eigenen Netz, und eine echte Option für Teams, die Jenkins ablösen, aber On-Premise bleiben wollen.
- /01Aufwand: Mittel
Jenkins
→ GitLab CI- 01Jenkinsfile in .gitlab-ci.yml übertragen (kein 1:1-Mapping)
- 02Plugin-Abhängigkeiten identifizieren und Ersatz finden
- 03Shared Libraries in GitLab CI/CD Components überführen
- 04Git-Repositories können übernommen werden
- /02Aufwand: Mittel
Jenkins
→ GitHub Actions- 01Jenkinsfile in .github/workflows/*.yml übertragen (YAML statt Groovy)
- 02Shared Libraries in Reusable Workflows und Composite Actions überführen
- 03Plugins durch Marketplace-Actions ersetzen (nicht immer 1:1)
- 04Für Sonderhardware und OT self-hosted Runner einplanen
- /03Aufwand: Hoch
GitLab CI
→ Jenkins- 01.gitlab-ci.yml in ein Jenkinsfile übertragen (Groovy lernen)
- 02Integrierte Funktionen (Registry, Security) durch Plugins ersetzen
- 03Eigene Infrastruktur für den Jenkins-Server aufbauen
- 04In der Praxis selten, meist wird von Jenkins weg migriert
Migrieren Sie nicht, weil ein Tool moderner klingt. Bei 10 bis 20 Pipelines rechnen Sie mit vier bis acht Wochen für den Umzug, dazu Schulung und angepasste Abläufe. Diese Zeit fehlt an anderer Stelle. Prüfen Sie deshalb zuerst, ob sich das Problem im bestehenden Tool lösen lässt. Sprechen Sie mit uns über Ihre Migration.
AIWelche Best Practices gelten unabhängig vom Tool?
Sechs Praktiken tragen alle vier Plattformen, und sie entscheiden über den Nutzen einer Pipeline stärker als die Toolwahl. Pipeline as Code, der CI-Server als Code, ein Artefakt durch alle Stufen, reproduzierbare Build-Agents, Feedback unter zehn Minuten und Secrets außerhalb der Pipeline-Definition.
Wer die sechs Punkte hat, kann das Tool wechseln, ohne die Arbeit von drei Jahren wegzuwerfen. Wer sie nicht hat, nimmt sein Problem in die neue Plattform mit und wundert sich dort nach zwei Jahren erneut.
- /01
Pipeline as Code, im selben Repository
Die Pipeline-Definition liegt neben dem Code, den sie baut, und wird mit ihm versioniert. Ein Branch bringt seine eigene Pipeline mit, ein Rollback nimmt sie mit zurück. Alle vier Plattformen können das. Nur klickt es in der Praxis trotzdem jemand in der Oberfläche zusammen, weil es beim ersten Mal schneller geht. Pipeline as Code im Glossar. - /02
Der CI-Server selbst als Code
Jenkins Configuration as Code, gitlab.rb oder Helm-Werte bei GitLab, YAML-Templates in Azure Pipelines. Ohne diesen Schritt ist der Wiederaufbau nach einem Ausfall Handarbeit, und niemand kann sagen, wer wann welche Einstellung geändert hat. Das ist der Punkt, an dem gewachsene Jenkins-Instanzen kippen, nicht die Plugin-Zahl. - /03
Einmal bauen, mehrfach ausliefern
Dasselbe Artefakt wandert durch Test, Abnahme und Produktion, statt in jeder Stufe neu gebaut zu werden. In der Industrie ist das der Unterschied zwischen der Aussage, auf Anlage 17 laufe Version 3.2.1, und der Aussage, dort laufe irgendein Stand von damals. - /04
Build-Agents reproduzierbar halten
Container-Image oder Konfigurationsrolle statt handgepflegter Maschine. Eine Ausnahme gibt es, und sie ist typisch für OT: Agents mit Lizenzbindung, etwa für das TIA Portal, lassen sich nicht beliebig neu erzeugen. Dann gilt das Minimum, nämlich Installation und Lizenzstand dokumentiert und der Agent nicht der einzige seiner Art. - /05
Zehn Minuten bis zum ersten Feedback
Der Commit-Build kompiliert, prüft statisch und lässt die schnellen Tests laufen. Alles, was länger dauert, also Integrationstests, Prüfstandsläufe, vollständige Regression, gehört in eine nachgelagerte Stufe. Dauert das erste Feedback eine Stunde, schaut niemand mehr hin, und die Pipeline wird zur Formalie. - /06
Secrets außerhalb der Pipeline-Definition
Credentials-Store, maskierte Variablen, Vault oder Key Vault. Ein Passwort im Jenkinsfile ist ein Passwort im Git-Verlauf, und der Verlauf vergisst es nicht, auch wenn der nächste Commit es entfernt.
In industriellen Projekten kommt eine siebte Praxis dazu, die in keiner Standardliste steht: Der Softwarestand muss von der Seriennummer der Anlage aus rückwärts auffindbar sein. Das ist keine Pipeline-Frage, sondern eine Frage der Versionierung und der Artefakt-Verwaltung. Wer sie offen lässt, hat eine schnelle Pipeline und trotzdem keine Antwort, wenn im Feld etwas ausfällt.
AIWie geht es nach der Toolwahl weiter?
Mit Pipeline-Design, Testautomatisierung und einem Team, das die Plattform betreibt. Das Tool macht nach unserer Erfahrung höchstens ein Fünftel des Erfolgs aus. Ein schlecht konfiguriertes GitLab CI ist nicht besser als ein gut gepflegter Jenkins.
Der erste Merge Request, der ohne einen Handgriff bis auf die Testumgebung durchläuft, sieht in allen vier Tools gleich aus. Auf dem Testsystem läuft dann der Stand, den der Entwickler kurz vorher gepusht hat, und niemand hat ihn dorthin kopiert. An diesem Punkt setzt unser DevOps-Coaching an.
Wer bei Jenkins bleibt, sollte 2026 die Wartung mit KI angehen. Plugin-Konflikte, das Rückübersetzen einer gewachsenen Instanz in Jenkins Configuration as Code (JCasC) und die Analyse von Build-Logs üben wir in der Jenkins-Schulung für Administratoren mit Claude Code, CPS-Fehler, Shared-Library-Refactoring und Tests mit JenkinsPipelineUnit im Jenkins Pipeline Workshop mit Claude Code. Wer Continuous Delivery auf Kubernetes braucht, ergänzt CI durch GitOps im ArgoCD- und GitOps-Workshop. Dauer, Preis und Termine aller Jenkins-Schulungen und -Seminare stehen in der Workshop-Übersicht. Für eine Jenkins-Plattform, die auf die Fertigung zugeschnitten ist, mit Air-Gap-fähiger KI-Assistenz und NIS2- und CRA-Berichten, gibt es IndustrialFlow.
Häufige Fragen zu Jenkins, GitLab und Azure DevOps
- Jenkins vs GitLab CI vs Azure DevOps vs GitHub Actions: Welches Tool 2026?
- Jenkins für maximale Flexibilität und Builds im eigenen Netz, GitLab CI für eine integrierte DevOps-Plattform mit Security-Scans, GitHub Actions für Teams auf GitHub und für neue Microsoft-Projekte, denn dorthin verlagert Microsoft die Weiterentwicklung. Azure DevOps bleibt für Bestands- und On-Premise-Kunden voll unterstützt. In der Industrie laufen oft zwei Tools nebeneinander, etwa Jenkins für die Steuerungssoftware und GitLab CI für die IT.
- Ist Jenkins noch aktuell?
- Ja. Jenkins wird aktiv weiterentwickelt, die letzte LTS 2.580.1 erschien am 30. September 2026, und das offizielle Plugin-Verzeichnis zählt über 2.300 Plugins. Neue Projekte ohne Sonderanforderungen starten heute zwar meist auf GitHub Actions oder GitLab CI, in Umgebungen mit Windows-Agents, Lizenzbindung oder Air-Gap-Netzen bleibt Jenkins aber oft die erste Wahl.
- Was ersetzt Jenkins?
- In den meisten Fällen GitLab CI oder GitHub Actions, je nachdem, wo der Quellcode liegt. Wer On-Premise bleiben will, nimmt GitLab self-managed oder TeamCity. Ganz ersetzt wird Jenkins in der Industrie selten: Pipelines mit TIA Portal, PLCSim oder Prüfständen bleiben häufig auf Jenkins, während die übrige Software umzieht.
- Was ist die beste Jenkins-Alternative 2026?
- Das hängt vom Einsatzzweck ab. GitLab CI ist die stärkste All-in-One-Alternative mit Repository, CI/CD, Registry und Security in einer Plattform. GitHub Actions ist die Wahl für Teams auf GitHub und für neue Microsoft-Projekte. Azure DevOps bleibt für Bestands- und On-Premise-Kunden voll unterstützt. Für On-Premise-, Air-Gap- und Industrie-Umgebungen (SPS, TIA Portal) ersetzt keine davon Jenkins vollständig.
- Welche Alternativen gibt es zu Azure DevOps?
- Die naheliegendste Alternative ist GitHub mit GitHub Actions, weil Microsoft neue Funktionen wie den Copilot Coding Agent dort zuerst entwickelt, während Azure DevOps für Bestandskunden voll unterstützt bleibt. Als Plattform ohne Microsoft-Bindung kommt GitLab in Frage, für reine CI/CD-Aufgaben im eigenen Netz Jenkins. Wer nur die Azure-Cloud verlassen will, kann mit dem Azure DevOps Server im eigenen Rechenzentrum bleiben.
- Was kostet Azure DevOps?
- Die ersten fünf Nutzer sind frei, danach kostet Azure DevOps Basic 6 US-Dollar je Nutzer und Monat (Stand Oktober 2026). Für Pipelines ist ein Microsoft-hosted Parallel-Job mit 1.800 Minuten im Monat frei, jeder weitere kostet 40 Dollar im Monat, ein weiterer self-hosted Job 15 Dollar. GitHub-Enterprise-Lizenzen enthalten Nutzungsrechte für Azure DevOps Basic.
- Gibt es eine kostenlose Jenkins-Alternative?
- Ja. GitLab bietet einen Free-Tarif mit 400 Compute-Minuten im Monat und eine kostenlose self-managed Edition, GitHub Actions ist für öffentliche Repositories frei und bringt im Free-Plan 2.000 Minuten im Monat für private Repositories mit, und Azure DevOps ist bis fünf Nutzer kostenlos. Wie bei Jenkins entstehen die eigentlichen Kosten durch Infrastruktur, Wartung und Schulung.
- Was kostet die Migration von Jenkins zu GitLab CI?
- Bei 10 bis 20 Pipelines rechnen Sie mit vier bis acht Wochen Aufwand. Der Großteil steckt nicht im Umschreiben der Stufen, sondern in Shared Libraries, Plugin-Ersatz und Sonderfällen. Dazu kommen Schulungen und angepasste Arbeitsabläufe im Team.
- Kann man Jenkins und GitLab CI gleichzeitig nutzen?
- Ja, und in der Praxis ist das verbreitet. GitLab CI übernimmt die Standard-Pipelines, Jenkins die Spezialfälle mit Sonderschnittstellen. Über die GitLab-Jenkins-Integration lassen sich Jenkins-Jobs direkt aus GitLab starten, die Ergebnisse erscheinen am Merge Request.
- Welches CI/CD-Tool eignet sich für SPS-Entwicklung und Industrial DevOps?
- Meist Jenkins. Er bindet Siemens TIA Portal, PLCSim Advanced oder Beckhoff TwinCAT über Kommandozeilenaufrufe und Windows-Agents an, auch in Netzen ohne Internet. GitLab CI und GitHub Actions gehen ebenfalls, brauchen aber self-hosted Windows-Runner und mehr Eigenbau. In IT/OT-Mischumgebungen empfehlen wir oft Jenkins für die OT-Pipelines und GitLab CI für die IT.
- Was ist der Unterschied zwischen GitLab CI und GitHub Actions?
- GitLab CI ist Teil einer DevOps-Plattform mit Issue-Tracking, Registry und Security-Scans, die sich auch komplett self-managed betreiben lässt. GitHub Actions ist der CI/CD-Dienst im GitHub-Ökosystem. GitLab CI bringt mehr eingebaute Funktionen mit, GitHub Actions punktet mit dem größeren Marketplace an fertigen Actions.
- Ist GitHub Actions besser als Jenkins?
- Für Teams auf GitHub ohne Sonderanforderungen ja, weil es einfacher einzurichten ist und keinen eigenen Server braucht. In komplexen Szenarien ersetzt es Jenkins nicht: Jenkins bietet mehr Spielraum bei On-Premise-Umgebungen, industriellen Toolchains und Pipeline-Logik mit Schleifen und Shared Libraries.
- Lohnt sich Azure DevOps auch ohne Azure Cloud?
- Azure DevOps lässt sich auch On-Premise oder mit anderen Cloud-Anbietern nutzen, verliert dann aber seinen größten Vorteil, die direkte Anbindung an Azure-Dienste. Für reine On-Premise-Umgebungen ohne Microsoft-Stack sind Jenkins oder GitLab self-managed meist die bessere Wahl.
- Was kostet der Betrieb von Jenkins im Vergleich zu GitLab CI?
- Jenkins ist lizenzfrei, braucht aber eigene Server und einen Wartungsanteil von etwa einer halben bis einer ganzen Stelle. GitLab Premium kostet 29 US-Dollar je Nutzer und Monat, reduziert aber den Administrationsaufwand deutlich. Für ein Team mit 20 Personen liegen die Gesamtkosten nach unserer Erfahrung bei Jenkins bei etwa 13.000 bis 27.000 Euro im Jahr, bei GitLab CI bei etwa 10.500 bis 20.000 Euro.
- Welche Kriterien zählen bei der Auswahl eines CI/CD-Tools?
- Zuerst zwei Fragen: Wo liegt der Quellcode, und wo darf die Pipeline laufen? Danach entscheiden die Gesamtkosten über die Laufzeit, die Kompetenz im Team, Anforderungen an Compliance und Datenhaltung sowie Sonderschnittstellen wie Windows-Toolchains oder Prüfstände. Ein Proof of Concept mit dem Favoriten auf einem echten Projekt liefert die solideste Entscheidungsgrundlage.
- Welche CI/CD-Tools lassen sich vollständig on-premise betreiben?
- Alle vier, mit unterschiedlichem Aufwand. Jenkins ist von Haus aus On-Premise und läuft auch ohne Internetzugang. GitLab self-managed bringt Repository, Registry und Runner als geschlossenes Paket ins eigene Rechenzentrum. Der Azure DevOps Server ist seit Dezember 2025 ein versionsloses Produkt mit fortlaufenden Updates. GitHub Actions setzt On-Premise den GitHub Enterprise Server mit self-hosted Runnern voraus und ist damit die teuerste Variante.
- Wie baut man Windows-Software in einer CI/CD-Pipeline?
- Über einen Build-Agent, der selbst unter Windows läuft. Jenkins bindet Windows-Agents seit jeher ein, GitLab CI über einen self-managed Runner mit Shell- oder Docker-Executor unter Windows, Azure Pipelines über Microsoft-hosted Windows-Agents oder eigene Maschinen. In industriellen Projekten ist das der Regelfall: TIA Portal Openness, PLCSim Advanced und viele Embedded-Toolchains gibt es nur für Windows, und ihre Lizenz hängt oft an genau einem Rechner.
- Welches CI/CD-Tool passt, wenn Quellcode und Artefakte in Deutschland bleiben müssen?
- GitLab self-managed und Jenkins, beide im eigenen Rechenzentrum oder bei einem deutschen Hoster betrieben. Beide halten Quellcode, Build-Artefakte und Protokolle vollständig unter eigener Kontrolle, was die Auftragsverarbeitung erheblich vereinfacht. Bei GitHub Actions und Azure DevOps als SaaS liegen zumindest Metadaten und Build-Protokolle bei Microsoft, was in regulierten Umgebungen eine Bewertung nach Art. 28 DSGVO erfordert.
Wie geht es bei Ihnen mit der Toolwahl zwischen Jenkins, GitLab und GitHub weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Welches Tool passt zu Ihnen?
Wir beraten herstellerunabhängig und empfehlen das Tool, das zu Ihrer Situation passt, nicht das, an dem wir am meisten verdienen. Das fachliche Erstgespräch dauert 30 Minuten und endet mit einer Einschätzung, nicht mit einem Angebot.
Verwandte Artikel
Jenkins mit KI steuern: MCP, Vibe Coding & Log-Analyse
Jenkins per Model Context Protocol steuern, Pipelines vibecoden und Build-Logs KI-gestützt analysieren.
CI/CD für SPS: TIA-Portal mit Jenkins
SPS-Programmierung automatisieren mit Jenkins, Git-Versionierung und PLCSim-Tests.
DevOps-Reifegrad messen & benchmarken
DORA-Metriken, Maturity Assessment und Value-Stream-Mapping.
AIOps in der Industrie: Praxisbeispiele und Kennzahlen
Wie AIOps die Daten aus IT und Anlage gemeinsam auswertet, mit vier Praxisbeispielen und den Kennzahlen MTTD, MTTR und MTBF.
Erstgespräch.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance