CI/CD-Pipeline aufbauen — Leitfaden für den Mittelstand 2026

Eine moderne CI/CD-Pipeline ist 2026 nicht mehr nur ein Werkzeug der Entwicklungs-Abteilung, sondern ein zentraler Sicherheits- und Compliance-Pfeiler. Sie ist die Strecke, auf der jede Code-Änderung von der Entwickler-Maschine bis in die Produktion läuft — und damit auch die Strecke, auf der Lieferketten-Angriffe, kompromittierte Abhängigkeiten und Insider-Risiken am wirksamsten abgefangen werden. Für mittelständische Unternehmen ist das aus drei Gründen unmittelbar relevant: erstens fordert NIS2 dokumentierte und nachvollziehbare Software-Lieferketten, zweitens verlangen immer mehr Industrie- und Behörden-Kunden SLSA-konforme Build-Nachweise, drittens entscheidet die Pipeline über die Geschwindigkeit, mit der Sicherheits-Patches in den Markt kommen. Dieser Artikel zeigt, was eine zeitgemäße Pipeline leisten muss, welche Tools im Markt relevant sind, wie die Stages sauber aufgebaut werden, welche Sicherheits-Bausteine Pflicht sind und mit welchem Aufwand Sie realistisch rechnen. Für die Einordnung in die Gesamtstrategie siehe unseren Cloud-&-DevOps-Guide für den Mittelstand.

Was eine moderne Pipeline 2026 leisten muss — und warum Haftung und Kosten dranhängen

Wer hier Lücken hat, riskiert Haftung der Leitungsebene, Audit-Befunde und sechs- bis siebenstellige Kosten durch verzögerte Sicherheits-Patches oder Lieferketten-Vorfälle. Die Anforderungen an CI/CD haben sich in den letzten drei Jahren spürbar verschoben. War 2022 noch die Kernfrage „läuft der Build automatisch und kommt das Artefakt auf den Server“, geht es 2026 um vier zusätzliche Dimensionen: Sicherheit der Lieferkette, Nachvollziehbarkeit jedes Artefakts, Geschwindigkeit über große Repositories und Audit-Tauglichkeit der gesamten Strecke. Eine Pipeline, die diese vier Dimensionen nicht abdeckt, wird heute weder vom Sicherheits-Audit noch vom Lieferanten-Audit großer Kunden akzeptiert.

Konkret gehört in eine moderne Pipeline 2026 mindestens Folgendes: ein automatisierter Pfad vom Commit bis zum Rollout, signierte Build-Artefakte mit Provenance, abgestufte Sicherheits-Scans, Secrets-Management ohne Klartext, ein Rollback-Verfahren unter fünf Minuten und ein Audit-Log über zwölf Monate. Hinzu kommen weiche Anforderungen: Lead-Times unter zehn Minuten für Standard-Workflows, sonst weichen Entwickler:innen auf manuelle Releases aus und entwerten die Pipeline.

Ebenso wichtig ist die organisatorische Einbettung. Reife Organisationen dokumentieren ihre Pipeline-Architektur in einem Intranet-Runbook und definieren klare Verantwortlichkeiten für Pipeline-Änderungen.

Tools im Vergleich

Der Markt für CI/CD-Werkzeuge ist heute übersichtlicher als noch vor fünf Jahren — die Konsolidierung hat einige Anbieter ausgesondert und einen klaren Kern aus sechs Plattformen übrig gelassen. Die folgende Übersicht ordnet die wichtigsten Optionen für mittelständische Unternehmen ein, mit Fokus auf typische Stärken und Einsatz-Szenarien.

Tool	Stärken	Typisches Einsatz-Szenario
GitHub Actions	Tiefe Integration in GitHub, große Action-Marketplace, gehostete und self-hosted Runner, schneller Einstieg	Standardwahl für GitHub-basierte Teams im Mittelstand, gut für Open-Source und SaaS-Produkte
GitLab CI	Vollständig integrierte DevSecOps-Plattform, EU-Hosting, Self-Managed-Variante, starke Security-Features im Premium-Tier	Standardwahl für GitLab-Kunden, besonders bei Compliance-Anforderungen mit EU-Datenhaltung
Jenkins	Maximale Flexibilität, riesiges Plugin-Ökosystem, vollständig On-Premise betreibbar, etablierte Skripting-Sprache	Bestehende Jenkins-Landschaften mit Custom-Plugins, regulierte Umgebungen mit Air-Gapped-Netzen
CircleCI	Sehr schnelle Build-Performance, intelligentes Caching, gute Parallelisierung, ausgereifte Orb-Bibliothek	Build-intensive Anwendungen, große Test-Suites, Teams mit Fokus auf Lead-Time-Optimierung
Buildkite	Hybrid-Modell mit SaaS-Control-Plane und self-hosted Build-Agents, sehr gut skalierbar	Größere Engineering-Organisationen mit hohem Build-Volumen und Sicherheits-Anforderungen an die Build-Hosts
ArgoCD / Flux	GitOps-native Continuous Deployment für Kubernetes, deklarativ, drift-detection, Multi-Cluster	CD-Schicht oberhalb der gewählten CI-Plattform, Standardwahl bei Kubernetes-zentrierten Stacks

Ein wichtiger Hinweis: ArgoCD und Flux sind keine vollständigen CI/CD-Plattformen, sondern reine CD-Werkzeuge — sie ergänzen GitHub Actions, GitLab CI oder Jenkins um eine GitOps-basierte Deployment-Schicht. Für Kubernetes-zentrierte Stacks ist diese Trennung 2026 der De-facto-Standard, weil sie Build-Logik und Deployment-Logik sauber trennt und ein deklaratives Cluster-State-Management ermöglicht. Mehr dazu in unserem Cluster zu GitOps mit ArgoCD und Flux.

Aus unserer Beratungs-Praxis: für mittelständische Unternehmen unter 200 Entwickler:innen sind GitHub Actions oder GitLab CI fast immer die richtige Wahl. Jenkins lohnt sich nur noch dann, wenn bereits eine etablierte Jenkins-Landschaft existiert oder spezielle Custom-Workflows Pflicht sind. CircleCI und Buildkite sind starke Spezial-Lösungen, spielen im DACH-Markt aber eine Nebenrolle.

Pipeline-Stages: Lint, Test, Build, Scan, Deploy, Smoke

Eine wartbare Pipeline besteht aus klar abgegrenzten Stages, die in einer festgelegten Reihenfolge laufen und bei Fehlern sauber abbrechen. Die folgenden sechs Stages sind der Branchen-Standard und decken den Lebenszyklus jeder Code-Änderung ab:

• Lint-StageStatische Code-Analyse, Formatierungs-Checks, Sprach-spezifische Linter (ESLint, ruff, golangci-lint), Commit-Message-Validation. Diese Stage läuft in unter einer Minute und fängt 30 bis 40 Prozent aller trivialen Probleme ab, bevor teurere Stages starten.
• Test-StageUnit-Tests und Integrationstests, parallelisiert nach Test-Suite, mit Coverage-Report und einem definierten Schwellenwert. Tests laufen idealerweise gegen ephemerale Container-Datenbanken, nicht gegen geteilte Staging-Datenbanken — Letzteres erzeugt instabile Builds.
• Build-StageErzeugung der Build-Artefakte: Binaries, Container-Images, Frontend-Bundles. Reproduzierbare Builds mit fixierten Abhängigkeits-Versionen sind Pflicht, weil sie die Voraussetzung für SLSA-Provenance und für rückverfolgbare Releases sind.
• Scan-StageDependency-Scan (SCA), Container-Image-Scan, Secret-Scan, statische Anwendungs-Sicherheits-Tests (SAST), Lizenz-Compliance-Prüfung. Diese Stage darf den Build bei kritischen Findings hart blockieren — dokumentiert und mit nachvollziehbarem Ausnahme-Verfahren.
• Deploy-StageRollout in die Ziel-Umgebung. Strikte Trennung zwischen Staging und Produktion mit eigenen Approval-Gates, separaten Secrets und unterschiedlichen Deployment-Strategien (Staging: Rolling, Produktion: Canary oder Blue/Green).
• Smoke-StageAutomatisierte Verifikation nach dem Deployment: Health-Checks, kritische End-to-End-Pfade, synthetische Transaktionen. Bei Fehlschlag automatisches Rollback. Diese Stage ist der wichtigste Schutz gegen kaputte Deployments und wird in vielen Pipelines sträflich vernachlässigt.

Wichtig ist die Reihenfolge: schnelle und billige Stages zuerst, langsame und teure Stages später. Ein Build, der in der Lint-Stage in 30 Sekunden scheitert, kostet viel weniger als einer, der erst nach dem 12-Minuten-Build im Container-Scan auffällt. Diese Optimierung wird oft unterschätzt, summiert sich aber über tausende Builds pro Monat zu spürbaren Kosten- und Wartezeiten-Reduktionen.

Sicherheit in der Pipeline: Secrets, Supply-Chain, Sigstore, SLSA

Der wichtigste Wandel in der CI/CD-Welt seit 2023 betrifft die Lieferketten-Sicherheit. Angriffe wie die kompromittierten npm-Pakete, die SolarWinds-Hintertür und die Vorfälle mit GitHub-Actions-Workflows haben die Branche dazu gebracht, vier Bausteine in jeder ernsthaften Pipeline zu verankern: ein modernes Secrets-Management, signierte Build-Artefakte, eine nachvollziehbare Build-Provenance und eine dokumentierte SLSA-Reife.

Beim Secrets-Management gilt: keine Klartext-Variablen in YAML-Dateien, keine geteilten Passwörter zwischen Pipelines, keine Langzeit-Tokens ohne Ablaufdatum. Stattdessen kommen OIDC-basierte Workload-Identities zum Einsatz — GitHub Actions, GitLab CI und Buildkite unterstützen heute alle den Tokenwechsel via OIDC gegen Cloud-Provider wie AWS, GCP, Azure und Vault. Damit entfallen statische Cloud-Credentials in der Pipeline vollständig, und die Audit-Spur ist deutlich sauberer.

Bei der Supply-Chain-Sicherheit sind Sigstore und SLSA die Referenz. Sigstore liefert mit cosign ein etabliertes Werkzeug, mit dem Container-Images und beliebige Artefakte ohne Schlüssel-Verwaltungs-Aufwand signiert und mit Transparency-Log-Einträgen versehen werden. SLSA (Supply-chain Levels for Software Artifacts) definiert vier Reife-Stufen: Level 1 verlangt eine dokumentierte, automatisierte Pipeline. Level 2 fügt signierte Provenance-Daten hinzu. Level 3 verlangt isolierte, manipulationssichere Build-Hosts. Level 4 ist heute fast ausschließlich für regulierte Plattform-Betreiber relevant.

Für mittelständische Unternehmen ist Level 2 das realistische Mindestziel und Level 3 das anzustrebende Reife-Niveau. GitHub bietet mit dem SLSA-Generator-Workflow eine fertige Integration für Level 3, GitLab unterstützt es nativ ab der Premium-Edition. Die Investition ist überschaubar: ein bis zwei Engineer-Wochen für die initiale Einrichtung, danach läuft die Provenance-Erzeugung mit. Detaillierter zur Supply-Chain siehe unseren Cluster zu Terraform-IaC-Best-Practices, in dem auch die Infrastructure-Provenance behandelt wird.

Test-Strategien: Unit, Integration, E2E, Smoke, Canary

Die Test-Pyramide hat sich in der Cloud-Native-Welt leicht verschoben — sie ist heute eher eine Test-Trapez-Form mit weniger End-to-End-Tests und mehr Integrationstests gegen Container-Stacks. Die folgenden fünf Test-Arten gehören in jede mittelständische Pipeline, jeweils mit eigener Stage und eigener Lauf-Frequenz:

• Unit-Tests: isolierte Tests einzelner Funktionen und Klassen, schnell, hoher Coverage-Anspruch, laufen bei jedem Commit. Zielwert: 70 bis 85 Prozent Code-Coverage in Kern-Modulen.
• Integrationstests: Tests gegen echte Abhängigkeiten — Datenbank, Cache, Message-Broker — in ephemeralen Containern via Testcontainers oder docker-compose. Diese Schicht ist heute oft wichtiger als reine Unit-Tests, weil sie reale Bug-Klassen früh fängt.
• End-to-End-Tests: komplette Nutzerszenarien über die UI oder API, mit Playwright, Cypress oder ähnlichen Werkzeugen. Bewusst sparsam einsetzen, weil teuer und flaky-anfällig. Fokus auf kritische Pfade wie Login, Checkout, Datenexport.
• Smoke-Tests: minimaler Funktions-Set nach jedem Deployment, läuft in unter 60 Sekunden, blockiert die Pipeline bei Fehlschlag. Entscheidet über automatisches Rollback.
• Canary-Validation: automatisierte Beobachtung der Canary-Instanz — Fehlerraten, Latenz, Custom-Metriken — über fünf bis fünfzehn Minuten, mit automatischem Promote oder Rollback je nach Schwellenwert.

Eine häufige Praxis-Falle: Teams investieren übermäßig in End-to-End-Tests und vernachlässigen Integrationstests. Das ergibt langsame, instabile Pipelines mit hoher Wartungs-Last. Die wirtschaftlichste Test-Investition liegt fast immer in der Integrations-Schicht, weil sie das beste Verhältnis aus Bug-Fang-Quote und Lauf-Stabilität bietet.

Deployment-Strategien: Rolling, Blue/Green, Canary, Feature-Flags

Die Wahl der Deployment-Strategie entscheidet darüber, wie groß das Risiko jedes einzelnen Releases ist und wie schnell ein fehlerhafter Release zurückgerollt werden kann. Vier Modelle sind etabliert:

Strategie	Risiko	Aufwand	Wann sinnvoll
Rolling Update	Mittel	Niedrig	Standard für interne Anwendungen und niedrig-frequente Services
Blue/Green	Niedrig	Mittel	Klassische Web-Anwendungen mit klaren Versions-Schnitten, einfaches Rollback
Canary	Sehr niedrig	Hoch	Umsatzkritische externe Services, Checkout-Flows, B2B-APIs mit harten SLAs
Feature-Flags	Sehr niedrig	Mittel	Granulare Steuerung einzelner Features, A/B-Tests, schrittweise Rollouts an Nutzer-Segmente

Feature-Flags sind in den letzten Jahren von einer Spezial-Technik zu einem Standard-Werkzeug geworden. Sie entkoppeln das Deployment von der Aktivierung — neuer Code geht in Produktion, bleibt aber hinter einem Flag deaktiviert und wird kontrolliert für Nutzer-Segmente freigeschaltet. Werkzeuge wie LaunchDarkly, Unleash oder Flipt machen die Einführung überschaubar. Der Aufwand lohnt sich besonders bei produktnahen Teams, die kontinuierlich Funktionen ausrollen, ohne Releases zu blocken. Detaillierter zu Deployment-Strategien siehe unseren Cluster zu Zero-Downtime-Deployment.

Self-hosted Runner vs SaaS

Die Entscheidung zwischen gehosteten und selbst betriebenen Build-Runnern ist nicht primär eine Kostenfrage, sondern eine Frage von Sicherheits-Anforderungen, Hardware-Bedarf und Build-Volumen. SaaS-Runner — GitHub-hosted, GitLab.com-hosted, CircleCI-Cloud — sind der pragmatischste Standard für die meisten mittelständischen Unternehmen: keine Patch-Verantwortung, automatische Skalierung, kein Pflege-Aufwand. Sie kosten überschaubar bis etwa zwei- bis dreitausend Build-Minuten pro Monat.

Self-hosted Runner lohnen sich in drei klar definierten Szenarien: erstens bei hohem Build-Volumen ab etwa zehntausend Minuten pro Monat, ab dem die SaaS-Kosten den Eigenbetrieb übersteigen. Zweitens bei speziellen Hardware-Anforderungen — GPU-Builds für ML-Workloads, ARM64-Native-Builds, Builds mit großen Caches im RAM. Drittens bei Compliance-Anforderungen, die die Verarbeitung von Source-Code in einer kontrollierten Umgebung erzwingen — typischerweise bei sensiblen Branchen oder bei klassifizierten Daten.

Wer self-hosted geht, übernimmt zusätzliche Verantwortung: Runner müssen gehärtet, ephemeral und isoliert sein. Ein nicht-ephemeraler Runner mit persistenten Volumes ist ein Lieferketten-Risiko erster Ordnung, weil ein erfolgreicher Angriff auf einen Build-Job potenziell alle nachfolgenden Builds betreffen kann. Der Industrie-Standard sind heute ephemerale Runner als Kubernetes-Pods oder als kurzlebige VMs mit Auto-Scaling.

Multi-Repo + Monorepo: Nx, Turborepo, Bazel

Die Wahl zwischen Multi-Repo- und Monorepo-Setup hat erhebliche Auswirkungen auf die Pipeline-Architektur. Multi-Repo ist der historische Standard mit klaren Service-Grenzen, eigenen Pipelines pro Repository und einfacher Versionierung. Monorepo bündelt mehrere Services in einem Repository, ermöglicht atomare Cross-Service-Änderungen und vereinfacht Refactorings — bringt aber Anforderungen an die Pipeline mit, die nicht trivial sind.

Der zentrale Punkt im Monorepo-Setup ist das selektive Build- und Test-Verhalten: nur die Services, die von einer Änderung tatsächlich betroffen sind, sollen gebaut und getestet werden. Werkzeuge wie Nx, Turborepo und Bazel lösen dieses Problem unterschiedlich. Nx ist die Standardwahl im JavaScript- und TypeScript-Umfeld mit ausgezeichneter IDE-Integration und Cache-Funktionen. Turborepo ist der schlankere Konkurrent von Vercel, mit Fokus auf Geschwindigkeit und Remote-Caching. Bazel ist die anspruchsvollste, aber auch leistungsfähigste Variante — sprachunabhängig, sehr schnell, mit hohem Lern-Aufwand und steiler Einstiegs-Kurve. Bazel lohnt sich ab größeren Engineering-Organisationen mit echtem Polyglot-Setup, ist für die meisten Mittelständler aber überdimensioniert.

Pragmatische Empfehlung: für JS/TS-Stacks Turborepo oder Nx, für moderate Polyglot-Stacks einfache Pfad-Filter, für sehr große Polyglot-Stacks Bazel — letzteres nur mit dediziertem DevOps-Investment.

Geschwindigkeit und Caching: Layer-Cache, Action-Cache, Remote-Build-Cache

Eine Pipeline, die zwanzig Minuten für jeden Commit braucht, wird umgangen — Entwickler:innen pushen seltener, batchen Änderungen und entwerten die Investition in Continuous Integration. Die wichtigste Stellschraube für Pipeline-Geschwindigkeit ist Caching, auf drei Ebenen: Docker-Layer-Cache, CI-Action-Cache und Remote-Build-Cache.

Docker-Layer-Caching ist die einfachste Optimierung mit der größten Wirkung. Saubere Dockerfile-Ordnung — selten ändernde Layer (Base-Image, System-Pakete) zuerst, häufig ändernde Layer (Application-Code) zuletzt — reduziert Build-Zeiten oft um 60 bis 80 Prozent. BuildKit mit dem cache-from- und cache-to-Mechanismus macht Layer-Caching auch über Runner-Grenzen hinweg möglich, was insbesondere bei ephemeralen Runnern entscheidend ist.

Auf Pipeline-Ebene bietet jedes große CI-Werkzeug einen Action- oder Job-Cache: GitHub Actions mit dem cache-Action, GitLab CI mit dem cache-Schlüssel im Job, Buildkite mit Build-Artifacts. Sinnvoll gecacht werden Abhängigkeits-Verzeichnisse (node_modules, pip-cache, .gradle, .m2), Build-Output-Verzeichnisse und Test-Caches.

Die fortgeschrittenste Schicht ist Remote-Build-Caching mit Werkzeugen wie Nx Cloud, Turborepo Remote Cache oder Bazel Remote Cache. Hier teilt ein ganzes Team einen gemeinsamen Build-Cache: was ein:e Kolleg:in einmal gebaut hat, muss nicht erneut gebaut werden. Diese Schicht hat das größte Potenzial in Monorepo-Setups und kann Pipeline-Zeiten um den Faktor fünf bis zehn reduzieren.

Reepa-Pipeline-Standards

Aus den oben beschriebenen Bausteinen leiten wir bei Reepa einen Standard ab, den wir bei jedem mittelständischen DevOps-Mandat einsetzen — er ist pragmatisch, sicherheits-orientiert und konsequent dokumentiert:

• Tool-StackGitHub Actions oder GitLab CI als CI-Schicht, ArgoCD als CD-Schicht für Kubernetes-Workloads, Sigstore/cosign für Artefakt-Signaturen, OIDC für alle Cloud-Credentials.
• StagesSechs-Stage-Layout (Lint → Test → Build → Scan → Deploy → Smoke) mit harten Gates zwischen Scan und Deploy sowie zwischen Deploy-Staging und Deploy-Produktion.
• SicherheitSLSA-Level-3 als Mindestziel, automatische SBOM-Erzeugung mit syft, Container-Scans mit trivy, Secret-Scans mit gitleaks, SAST mit der jeweils sprachspezifischen Branchen-Lösung.
• PerformanceLead-Time-Ziel unter zehn Minuten für Standard-Workflows, Caching auf drei Ebenen (Docker-Layer, Action-Cache, Remote-Cache bei Monorepos), ephemerale Runner für sicherheitskritische Builds.
• Audit-TauglichkeitVollständiges Build- und Deployment-Log mit zwölf Monaten Aufbewahrung, signierte Provenance-Daten für jedes Produktions-Artefakt, dokumentiertes Rollback-Verfahren mit Test-Lauf alle 90 Tage.

Dieser Standard ist bewusst pragmatisch: er erfüllt SLSA-Level-3, NIS2-Anforderungen an die Lieferkette und typische Lieferanten-Audit-Fragen großer Industrie-Kunden — ohne in eine Plattform-Komplexität abzukippen, die für mittelständische Engineering-Teams nicht wartbar ist.

Häufige Fragen