CI/CD im Jahr 2026: Wann Jenkins, GitHub Actions, GitLab CI, Argo CD und Tekton sinnvoll sind
Wenn es um CI/CD geht, landen Jenkins, GitHub Actions, GitLab CI, Argo CD und Tekton oft in derselben Vergleichstabelle. Für eine erste Orientierung ist das praktisch, aber 2026 kann so eine Tabelle leicht in die Irre führen. Manche Werkzeuge lösen Builds und Tests nah am Repository. Andere steuern Deployments nach Kubernetes. Wieder andere sind Bausteine für eine interne Delivery-Plattform.
Deshalb ist die Frage „Was sollen wir wählen?“ meist zu breit gestellt. Zuerst geht es nicht um die Marke, sondern um das Betriebsmodell: Brauchen Sie CI direkt beim Git-Anbieter, GitOps CD für einen Cluster, eine Kubernetes-native Pipeline Engine oder ein System, das mehr als zehn Jahre Enterprise-Automatisierung überlebt hat und weiterhin in vielen Unternehmen läuft? Erst danach ergibt die Produktauswahl Sinn.
Stirbt Jenkins?
Wenn man Jenkins als bestehendes Enterprise-System betrachtet, lautet die Antwort: nein, es stirbt nicht. Die offizielle Jenkins-Dokumentation dreht sich weiterhin um Controller, Agents, Labels und verteilte Job-Ausführung. Dieses Modell funktioniert immer noch dort, wo es geschlossene Netzwerke, Hardware-Labore, Code Signing, ungewöhnliche Toolchains und jahrelang gewachsene Pipelines gibt. (Jenkins)
Als neue Wahl im Jahr 2026 wirkt Jenkins aber fast immer schwächer als CI-Plattformen, die bereits in den Entwicklungsprozess eingebettet sind. Nicht weil Jenkins „keine Builds mehr ausführen kann“, sondern weil mit einem Jenkinsfile auch ein separates Produkt kommt, das aktualisiert, gesichert, geschützt, von unnötigen Plugins befreit und stabil betrieben werden muss. Wo GitHub Actions und GitLab CI schon Teil des täglichen Entwicklungsprozesses sind, fühlt sich Jenkins für ein neues Team oft weniger wie ein Beschleuniger und eher wie eine zusätzliche Betriebsschicht an.
Ein gutes Zeichen dieser Entwicklung ist Jenkins X. Im März 2026 schrieb das Projekt direkt, dass der Name Jenkins zu einer Marketinglast geworden sei: Er zog Menschen an, die klassisches Jenkins erwarteten, und schreckte Menschen ab, die nach einer Alternative suchten. Das Projekt wurde in JayeX umbenannt, und die verbleibenden Jenkins-Integrationen wurden als deprecated markiert. Das ist nicht mehr „die Zukunft von Jenkins“, sondern ein eigener Entwicklungszweig. (JayeX)
Meine Kurzfassung: Jenkins ist als installierte Basis nicht tot, aber als Standardwahl für neue Projekte ist es tot. Teams wählen Jenkins nicht, weil es 2026 die beste Option ist, sondern weil die Migrationskosten manchmal höher sind als der Schmerz des Verbleibs.
GitHub Actions
GitHub Actions passt am besten zu Teams, deren Code, Pull Requests, Code Reviews und Release-Prozess bereits in GitHub stattfinden. Die Stärke von Actions liegt nicht in YAML an sich, sondern in der Nähe zum Repository: Workflows liegen neben dem Code, Statusmeldungen landen direkt im PR, Secrets und Environments sind Teil der Plattform, und das Ökosystem fertiger Actions deckt die meisten Standardaufgaben ab.
2026 investiert GitHub weiter in dieses Modell. Das Unternehmen schreibt, dass alle Jobs auf eine neue Architektur umgestellt wurden, die auf zig Millionen Jobs pro Tag ausgelegt ist. Gleichzeitig wurden die Preise für GitHub-hosted runners zum 1. Januar 2026 gesenkt. Für Standard-hosted runners sieht die Preisstruktur so aus: Linux 1-core kostet $0.002/min, Linux 2-core $0.006/min, Windows 2-core $0.010/min und macOS $0.062/min. Für öffentliche Repositories bleiben Standard-hosted runners kostenlos, während private Repositories je nach Plan ein inkludiertes Minutenkontingent erhalten. (GitHub, GitHub, GitHub)
Die aussagekräftigste Geschichte des Jahres 2026 betrifft aber nicht hosted runners, sondern self-hosted runners. GitHub kündigte zunächst eine separate $0.002/min cloud platform charge für self-hosted runners an und verschob dieses Modell dann nach negativer Rückmeldung der Nutzer. Das Signal ist wichtig: Self-hosted runners im GitHub-Ökosystem sollte man nicht mehr als „für immer kostenlose Möglichkeit, Actions auf eigener Hardware auszuführen“ betrachten. Die Plattform bewegt sich klar dahin, nicht nur Compute, sondern auch die Control Plane darum herum zu monetarisieren. (GitHub)
GitHub Actions ist der beste Standard, wenn Ihr Team bereits in GitHub arbeitet und keine separate Platform-Engineering-Funktion aufbaut. Die Schwäche ist ebenso klar: Mit der Bequemlichkeit akzeptieren Sie einen starken Lock-in an GitHub als Zentrum des Engineering-Prozesses.
GitLab CI
GitLab CI ist selten die trendigste CI-Lösung, aber sehr oft das vollständigste Produkt. Wenn GitHub Actions durch seine Nähe zum Pull-Request-Workflow stark ist, dann ist GitLab CI stark, weil es innerhalb einer breiteren SDLC-Plattform lebt: Source Code, Merge Requests, Registry, Security Scans, Environments, Runners und Governance liegen in einer gemeinsamen Schicht.
Besonders transparent ist bei GitLab die Ökonomie der hosted usage. Auf GitLab.com wird Compute-Nutzung nach der Formel job duration / 60 * cost factor berechnet; der cost factor hängt vom Runner-Typ und der Maschinengröße ab. Für Linux x86-64 small beträgt der Faktor 1, größere Maschinen erhöhen ihn, und macOS- sowie GPU-Runner haben deutlich höhere Multiplikatoren. Der Free Tier auf GitLab.com enthält 400 compute minutes pro Monat, weitere 1000 Minuten kosten $10. Eigene Runners kann man separat betreiben, und ihre Nutzung verbraucht nicht das Kontingent der shared runners. (GitLab, GitLab, GitLab)
Der praktische Schluss ist einfach. Wenn ein Team bereits in GitLab arbeitet, ergibt ein Wechsel nur wegen eines „modischeren CI“ meist keinen Sinn. GitLab CI ist besonders stark dort, wo ein einheitliches Governance-Modell, Group Runners und ein vorhersehbarer administrativer Rahmen wichtig sind. Wenn ein Unternehmen GitLab aber nicht als zentrale Entwicklungsplattform nutzt, ist es nicht immer rational, den ganzen Stack nur wegen CI/CD einzuführen.
Argo CD
Argo CD gehört in eine andere Schicht als GitHub Actions und GitLab CI. Offiziell ist es ein declarative GitOps continuous delivery tool for Kubernetes. Argo CD beantwortet also nicht die Frage „Wo führen wir Tests und Builds aus?“, sondern „Wie konvergiert der Cluster zu dem Zustand, der in Git beschrieben ist?“ (Argo CD)
Das sieht man auch in der Dokumentation zu automation from CI pipelines. Der empfohlene Ablauf lautet: CI baut und veröffentlicht ein Container-Image, aktualisiert anschließend Manifeste in Git, und danach synchronisiert Argo CD den Cluster mit dem gewünschten Zustand. Wenn automated sync für die Anwendung aktiviert ist, wird ein separater imperativer Deploy-Schritt in CI sogar überflüssig. (Argo CD)
Argo CD ersetzt CI also nicht, sondern steht daneben. Es gibt Teams einen auditierbaren GitOps-Prozess, besseren Umgang mit mehreren Clustern, Trennung zwischen Application-Repository und Config-Repository sowie vorhersehbarere Rollbacks über die Git-Historie. Wenn Sie aber einen einzelnen Service per docker compose auf einen VPS deployen, ist Argo CD keine Modernisierung, sondern zusätzliche Komplexität.
Tekton
Tekton ist wieder eine andere Systemklasse. Die offizielle Dokumentation beschreibt es als cloud-native solution for building CI/CD pipelines, die als Kubernetes-Erweiterung installiert wird und Custom Resources als grundlegende Pipeline-Bausteine verwendet. Tekton ist also nicht einfach „noch ein CI“, sondern eine Kubernetes-native Schicht, auf der man eine eigene Delivery-Plattform bauen kann. (Tekton)
Deshalb passt Tekton besonders gut zu Platform Engineering. In seiner Terminologie gibt es Tasks, Pipelines, Triggers, Chains, Kataloge wiederverwendbarer Komponenten und einen starken Fokus auf Supply-Chain-Sicherheit. Im März 2026 wurde Tekton ein CNCF Incubating Project, was es als reifen cloud-native Baustein und nicht als Nischenexperiment positioniert. (Tekton, CNCF)
All das hat aber seinen Preis. Tekton funktioniert gut, wenn Kubernetes bereits Ihre interne Plattform ist und ein Team bereitsteht, nicht nur Anwendungen, sondern auch die Delivery-Schicht selbst zu betreiben. Für ein kleines Produktteam ist Tekton meistens keine „Freiheit“, sondern der zu frühe Bau eines internen PaaS.
Self-hosted runners
Self-hosted runners sind 2026 nicht deshalb sinnvoll, weil sie „per Definition billiger“ sind. Sie sind sinnvoll, wenn es klare Anforderungen gibt: Builds brauchen Zugriff auf ein privates Netzwerk, interne Artefakte, ungewöhnliche Toolchains, GPU, Arm, HSM/Code Signing, große Caches oder strengere Kontrolle über Daten und Latenz.
Self-hosted runners werden aber fast immer unterschätzt. Sobald Sie managed execution verlassen, entsteht eine Mini-Plattform: Autoscaling, Queues, Image-Updates, OS-Patches, Secrets, Isolation zwischen Jobs, Observability, Fehleranalyse und Capacity Planning. GitHub schreibt in seiner Kommunikation für 2026 ausdrücklich, dass es in ARC, Scale Set Client, Observability und weitere Enterprise-Funktionen rund um self-hosted Erfahrungen investiert. Das ist eine gute Erinnerung daran, dass eine Runner-Flotte ein echtes Produkt ist und kein kostenloses Anhängsel von CI. (GitHub)
Die Regel ist einfach: Self-hosted runners wählt man wegen Sicherheits-, Netzwerk- oder Performance-Anforderungen. Man sollte sie nicht nur deshalb wählen, weil das Team „eigene Hardware“ romantisiert oder ein paar Tausend hosted minutes sparen will, ohne die Betriebskosten zu berechnen.
Welches CI/CD sollte man 2026 wählen?
Für die meisten Teams wird die Entscheidung einfacher, wenn zuerst das Betriebsmodell und erst danach das Werkzeug festgelegt wird.
| Szenario | Wahl | Warum |
|---|---|---|
| Kleines Team, Code und Review vollständig in GitHub | GitHub Actions | Der kürzeste Weg vom Commit zur Production ohne separate Plattform |
| Team arbeitet bereits in GitLab und will einen einheitlichen SDLC-Stack | GitLab CI | Source, CI, Registry, Governance und Runners in einem Produkt |
| Kubernetes-Plattform mit GitOps-Prozess | GitHub Actions oder GitLab CI + Argo CD | CI baut Artefakte, Argo CD übernimmt declarative delivery |
| Internes Plattformteam baut eine eigene Delivery-Schicht auf Kubernetes | Tekton | Liefert Primitive und wiederverwendbare Bausteine, nicht nur eine fertige Pipeline-UI |
| Große Legacy-Organisation mit Hunderten Jobs und Spezialintegrationen | Jenkins | Der Migrationsschmerz kann höher sein als der Nutzen eines Umzugs |
Wenn Sie eine kurze Empfehlung ohne viele Einschränkungen brauchen: 2026 ist Jenkins nicht die Standardwahl für ein neues Team. Meist ist es entweder GitHub Actions oder GitLab CI. Argo CD kommt dazu, wenn Kubernetes bereits vorhanden ist und GitOps CD gebraucht wird. Tekton kommt dazu, wenn Sie eine interne Plattform bauen. Jenkins bleibt dort, wo die Geschichte des Unternehmens bereits tief in sein Modell eingebaut ist.
Kurzes Fazit
CI/CD im Jahr 2026 ist kein Markt mehr, in dem ein Werkzeug „alles machen“ muss. In der Praxis wählen Teams zwischen verschiedenen Schichten des Delivery-Stacks: CI nah an Git, GitOps-Deployment für Kubernetes und Plattformprimitive für ein internes Engineering-System.
Die Frage „Jenkins oder Argo CD?“ bedeutet daher meist, dass ein Team CI und CD noch nicht sauber in Schichten getrennt hat. Jenkins, GitHub Actions und GitLab CI führen Automatisierung aus. Argo CD steht daneben als Kubernetes CD. Tekton erscheint häufiger in der Architektur einer internen Plattform als in einem fünfköpfigen Produktteam.
Hart formuliert: Jenkins als Standardwahl ist tot. Jenkins als riesige installierte Basis wird noch lange leben. GitHub Actions passt natürlich zu GitHub-zentrierten Teams, GitLab CI ist stark als einheitliche Plattform, Argo CD ist zur Standardantwort für GitOps-Deployments nach Kubernetes geworden, und Tekton ist für Teams, die ihre eigene Delivery Engine bauen wollen, statt nur eine Pipeline auszuführen.
Der teuerste Fehler ist nicht, „die falsche Marke“ zu wählen, sondern ein Werkzeug aus der falschen Klasse. Wenn ein Team normales CI nah am Repository braucht, braucht es kein Tekton. Wenn ein Team GitOps CD für einen Cluster braucht, braucht es nicht Jenkins statt Argo CD. Und wenn ein Team einen schnellen, funktionierenden Delivery-Prozess braucht, braucht es selten einen eigenen Zoo, den es länger warten wird als sein eigentliches Produkt.