Eine Pipeline ist im DevOps-Sinne eine automatisierte, mehrstufige Werkzeugkette, die Code-Änderungen vom Commit bis in eine Zielumgebung transportiert und dabei Build-, Test-, Sicherheits- und Deployment-Schritte ausführt. Pipelines werden in der Regel als Code (YAML, Groovy, JSON) im Repository selbst gepflegt und reagieren auf Ereignisse wie Pushes, Pull Requests, Tags, Zeitpläne oder manuelle Trigger. Sie strukturieren ihre Arbeit in Stages, Jobs und Steps, die wiederum parallel oder sequentiell ablaufen können und über Artefakte sowie Variablen Daten austauschen.
Eingesetzt werden Pipelines in nahezu jedem modernen Softwareprojekt. Die zugrundeliegenden Plattformen reichen von GitHub Actions und GitLab CI/CD über Azure Pipelines, Jenkins, Bitbucket Pipelines, CircleCI bis hin zu spezialisierten Werkzeugen wie Tekton, Argo Workflows und Buildkite. Klassische Pipeline-Bausteine sind: Build, Unit-Tests, statische Analyse (Linter, SAST), Integrationstests, Container-Build mit Provenance, Vulnerability-Scan, Veröffentlichung in Artefakt-Repository, Deployment in Dev/Staging/Production sowie Smoke- und End-to-End-Tests in der Zielumgebung.
Manuelle Build-, Test- und Deployment-Schritte sind fehleranfällig, schwer dokumentierbar und stark personenabhängig. Eine Pipeline kodiert diese Schritte einmal, versioniert sie zusammen mit dem Code und macht sie für jeden Beteiligten transparent nachvollziehbar — inklusive Logs, Artefakten und Status-Historie. Damit sinkt die Schwelle zwischen Entwicklung und Betrieb, was die DevOps-Idee operationalisiert.
Historisch geht das Konzept der Build-Pipeline auf Werkzeuge wie make (1976) und ant (2000) zurück, die mehrstufige Build-Schritte deklarativ beschrieben. CruiseControl (2001) führte den Pipeline-Gedanken in das CI-Umfeld; Jez Humble und Dave Farley etablierten 2010 mit ihrem Buch "Continuous Delivery" den Begriff "Deployment Pipeline" als zentralen Architekturbegriff. Mit dem Aufstieg von Container-Builds und Kubernetes haben sich Cloud-Native-Pipeline-Werkzeuge wie Tekton (CNCF Incubating) und Argo Workflows (CNCF Graduated) etabliert, die Pipelines selbst als Custom Resources in Kubernetes ausführen.
"Pipeline as Code" war bis 2014 keineswegs Standard — viele Teams konfigurierten Pipelines in der Click-Oberfläche von Jenkins oder TFS, wodurch die Pipeline-Definition selbst nicht versioniert war. Die Einführung des Jenkinsfile (Pipeline Plugin, 2016) gilt als Wendepunkt: Sie machte sichtbar, dass auch CI/CD-Werkzeugketten am besten als Code verwaltet werden — eine Erkenntnis, die heute in fast allen modernen Pipeline-Plattformen Standard ist.