Pipeline as Code

In der Praxis sieht das so aus: Im Wurzelverzeichnis des Repositorys liegt eine Textdatei, bei Jenkins das Jenkinsfile, bei GitLab die .gitlab-ci.yml, bei GitHub ein Workflow unter .github/workflows. Bei jedem Push liest der CI-Server diese Datei aus dem jeweiligen Branch und führt die darin beschriebenen Stages aus. Build- und Deployment-Logik werden also nicht mehr in einer Web-UI zusammengeklickt. Das Prinzip stammt von Infrastructure as Code und überträgt es auf die Pipeline selbst.

Jede Änderung an der Pipeline durchläuft damit dieselben Schritte wie Anwendungscode: Code-Review, Pull Request, Branch-Strategie und vollständige Historie. Wer den Build-Prozess ändert, hinterlässt eine Spur mit Namen, Datum und Begründung. Bei einer klickbaren Konfiguration fehlt diese Spur meist. Die Auditor-Frage „Wer hat diese Build-Einstellung wann geändert?" bleibt dort oft unbeantwortet, bei Pipeline as Code beantwortet sie ein git log.

Für regulierte Industrien entsteht dieser Nachweis nebenbei. Audits nach ASPICE oder IEC 62443 verlangen, dass Änderungen am Entwicklungs- und Auslieferungsprozess nachvollziehbar sind. Liegt die Pipeline als versionierter Code vor, ist diese Dokumentation Teil der täglichen Arbeit und keine Sonderaufgabe vor dem Audit.

Der typische Stolperstein ist Wildwuchs. Schreibt jedes Team seine Pipeline-Datei komplett selbst, existieren nach einem Jahr Dutzende leicht unterschiedlicher Varianten derselben Logik. Abhilfe schaffen wiederverwendbare Bausteine wie Jenkins Shared Libraries, GitLab-Includes oder Reusable Workflows bei GitHub. Sie halten die gemeinsame Logik an einer Stelle, und im Projekt bleibt nur, was wirklich projektspezifisch ist.