GitOps in der Industrie.
Von der SPS bis zur Anlagen-Flotte.
GitOps lässt sich in der Industrie auf zwei Ebenen anwenden. Auf SPS-/PLC-Ebene ist PLC-Code in Git heute vor allem ein versioniertes Artefakt-Repository mit Audit-Trail — echte Merges gelingen nur für textuelle Logik wie Structured Text. Für Container-Workloads am Industrie-Edge gilt GitOps im engeren Sinn: Tools wie Argo CD, Flux oder Rancher Fleet ziehen den in Git beschriebenen Soll-Zustand pull-basiert auf ganze Anlagen-Flotten. Der größte praktische Hebel — und die ehrlichste Grenze — liegt genau dazwischen.
GitOps vs. DevOps — und wo die Industrie steht
DevOps und GitOps sind keine Konkurrenten, sondern verschiedene Ebenen. DevOps ist die übergeordnete Kultur, GitOps ein konkretes Betriebsmodell für Deployments. In der Industrie kommt eine dritte Frage hinzu: Wie weit reicht dieses Modell überhaupt, wenn am Ende der Pipeline keine Cloud, sondern eine Steuerung in einer laufenden Anlage steht?
PLC mit Git versionieren: Was geht heute wirklich?
Der Knackpunkt ist die IEC 61131-3: Nur die textuelle Sprache Structured Text (ST) bzw. Siemens SCL ist zeilenweise diff- und mergebar. Die grafischen Sprachen LD, FBD und SFC werden zwar als XML serialisiert, lassen sich praktisch aber nicht zusammenführen. Wer GitOps-Vorteile in der Steuerung will, treibt Logik bewusst Richtung ST und nutzt für den Rest die Compare-Tools der Hersteller.
Wichtig für die Erwartungshaltung: Für die SPS-Logik selbst ist Git heute meist ein versioniertes Artefakt-Repository mit Audit-Trail — kein voller kollaborativer Merge-Workflow wie in der Web-Entwicklung. Echtes GitOps im engeren Sinn beginnt eine Ebene höher, bei den Container-Workloads. Wie man PLC-Code mit Git versioniert — über das Version Control Interface (VCI) oder den Openness-Export — zeigt unser Schritt-für-Schritt-Leitfaden für das TIA Portal.
Wie rollt man Software auf viele Anlagen aus?
Hier zeigt GitOps seine volle Stärke. Moderne Controller fahren zunehmend Linux und Container — PLCnext, Bosch ctrlX OS, Siemens Industrial Edge. Auf dieser Ebene beschreibt man den Soll-Zustand jeder Anlage deklarativ in Git, und ein Agent gleicht die Realität kontinuierlich ab. Entscheidend für OT: Diese Agents arbeiten pull-basiert und brauchen keine eingehende Verbindung — sie passen damit ins Zonenmodell der IEC 62443.
Wer setzt GitOps in der Industrie ein?
Die belastbaren öffentlichen Referenzen betreffen heute Edge- und Container-Workloads, nicht die IEC-61131-Zykluslogik selbst — eine saubere, ehrliche Unterscheidung. Eine öffentlich dokumentierte End-to-End-Case für GitOps der SPS-Logik in der Serienfertigung gibt es bislang nicht. Was es gibt, ist überzeugend genug:
Siemens Werk Amberg · Red Hat OpenShift
Umstieg von monolithischer IT auf eine Cloud-native Plattform. GitOps ermöglicht laut Siemens den Wechsel von zwei Upgrades pro Jahr auf tägliche Patches — ohne Produktionsunterbrechung. Anwendungen: Predictive Maintenance und KI-gestützte Röntgen-Analyse von Lötstellen.
Quelle: redhat.comBosch Rexroth ctrlX · Werk Blaichach
Der linux-basierte ctrlX-CORE-Controller läuft in Boschs eigener Fertigung sicherheitsrelevanter Produkte. ctrlX OS ist app- und update-fähig und bringt DevOps-Praktiken — versionierte Apps, deklarative Updates — auf die Steuerungsebene.
Quelle: bosch.comSiemens Industrial Edge
Docker-/Kubernetes-basierte Edge-Plattform mit zentralem Industrial Edge Management (IEM) zur deklarativen Verwaltung großer Geräteflotten über viele Werke. Referenz-Code öffentlich auf github.com/industrial-edge.
Quelle: siemens.comRed Hat „Industrial Edge" Validated Pattern
Offene Referenzarchitektur, die Hardware → OS → Kubernetes → Apps vollständig deklarativ aus Git beschreibt — inklusive Anomalieerkennung auf Sensor-Zeitreihen am Edge und zentralem Modell-Retraining.
Quelle: validatedpatterns.ioSechs Praktiken, die sich bewähren
Logik und Konfiguration trennen
Steuerungslogik (idealerweise als Structured Text) in eigene Repositories, Hardware-Konfiguration und Anlagenparameter deklarativ daneben. Bei TIA Portal erzwingt das VCI diese Trennung ohnehin — das Gesamtprojekt wird nicht synchronisiert.
Ein Objekt, eine Datei
POUs und Datentypen je Objekt in Einzeldateien halten (TwinCAT-Best-Practice). Das minimiert Merge-Konflikte, weil Änderungen nicht in einer Sammeldatei kollidieren. Generierte Artefakte konsequent per .gitignore ausschließen.
Sprache bewusst wählen
Wo Review und Versionierung zählen, Structured Text / SCL bevorzugen — nur diese sind echt diff- und mergebar. Grafische Sprachen nur dort, wo sie fachlich nötig sind, und über die Compare-Tools der Hersteller vergleichen.
CI gegen die Simulation
Pipeline kompiliert SPS-Code aus Git und testet gegen CODESYS-Simulation oder Siemens PLCSIM Advanced (realistisches Timing, skriptbar per API). Regressionstests laufen so ohne physische Hardware — Hardware-in-the-Loop nur für Timing- und Vendor-Spezifika.
Pull statt Push am Edge
In OT-Zonen sind eingehende Verbindungen meist verboten. Pull-basierte Modelle (Fleet, Flux, Argo CD) ziehen den Soll-Zustand aus Git und respektieren so die Conduits des IEC-62443-Zonenmodells.
Freigaben über Pull Requests
Jede Änderung läuft über Branch + Review + Merge. Der Pull Request wird zum dokumentierten Freigabeschritt, signierte Commits und Baseline-Tags liefern den Audit-Trail für Abnahme und Compliance.
Wo es in der Praxis hakt
Binärformate sind nicht mergebar
Das TIA-Gesamtprojekt (.apXX) ist binär, nicht text-diffbar und nicht abwärtskonvertierbar. Git verwaltet es nur als versioniertes Artefakt — kein kollaborativer Merge-Workflow.
Grafische Logik bleibt sperrig
LD/FBD/SFC werden zwar als XML serialisiert, sind aber praktisch nicht zeilenweise mergebar. LineID-Drift (TwinCAT) erzeugt Diffs schon bei reinen Kommentar-Änderungen.
Kein „einfacher Rollback" in der Produktion
Eine laufende Anlage lässt sich nicht wie ein Cloud-Service blue/green umschalten. Deployments brauchen Wartungsfenster; deterministisches Echtzeitverhalten und Anlagensicherheit setzen harte Grenzen.
Proprietäre Tools und Lizenzen
Native Git-Anbindung steckt in kostenpflichtigen Editionen (CODESYS Professional), TIA Openness ist lizenz- und versionsgebunden. Der Toolchain-Lock-in begrenzt den Workflow.
Kultur Automatisierer vs. Entwickler
Ladder-Denke und Vendor-IDE treffen auf Git, Branches und Code-Review. Dieser Kulturwandel ist der größte nicht-technische Hebel — und scheitert öfter als die Technik.
Abnahme bleibt Pflicht
Änderungen an abgenommenen, safety-relevanten Anlagen lösen Re-Validierung aus. GitOps liefert die Nachvollziehbarkeit, befreit aber nicht von der formalen Abnahme.
Erfüllt der Git-Verlauf die Nachweispflichten?
Die unveränderliche Git-History — signierte Commits, Baseline-Tags, dokumentierte Reviews per Pull Request — liefert genau die Nachvollziehbarkeit, die OT- und Safety-Normen verlangen. Sie liefert das Wie der Nachweisführung, befreit aber nicht von der formalen Abnahme.
OT-Security über Zonen & Conduits, Security Level SL1–SL4. Pull-basierte GitOps-Modelle ohne eingehende Verbindungen passen direkt ins Zonenmodell; signierte Commits und Images dienen als Integritätsnachweis.
Glossar: IEC 62443Funktionale Sicherheit fordert explizit Versions- und Change-Management. Die unveränderliche Git-History mit Baseline-Tags und PR-Reviews deckt genau diese Nachweispflicht ab — die Re-Validierung safety-relevanter Änderungen bleibt aber bestehen.
Analoge Anforderungen an Traceability und Konfigurationsmanagement. Die git-basierte Nachweisführung lässt sich sinngemäß übertragen.
Glossar: ISO 26262 (Automotive)Wie verwaltet man PLC-Code mit Git?
PLC-Code kommt in Git, indem man die Steuerungslogik aus der Vendor-IDE in Quelltext exportiert — bei CODESYS über den nativen Git-Client, bei Siemens TIA Portal über das Version Control Interface (VCI), bei Beckhoff TwinCAT 3 als XML je POU. Verlässlich diff- und mergebar ist dabei nur textuelle Logik (Structured Text / SCL); grafische Sprachen und das binäre Gesamtprojekt versioniert Git nur als Artefakt. In der Praxis ist Git für PLC-Code damit Audit-Trail und Single Source of Truth — mit signierten Commits, Baseline-Tags und Pull-Request-Reviews als Freigabe- und Compliance-Nachweis.
Lässt sich GitOps direkt auf eine SPS anwenden?
Nicht im engeren Sinn. GitOps als kontinuierliche Reconciliation aus Git gilt für Container-Workloads auf Edge-Geräten und Kubernetes — nicht für die zyklische Echtzeitlogik einer SPS. Für die SPS-Logik selbst nutzt man Git als versioniertes Artefakt-Repository und Audit-Trail. Die OT-Welt nähert sich GitOps darüber an, dass Controller zunehmend Linux und Container fahren (PLCnext, Bosch ctrlX, Siemens Industrial Edge).
Wie versioniert man SPS-Code aus TIA Portal in Git?
Über das Version Control Interface (VCI), das auch per Openness-API ansprechbar ist. Es exportiert einzelne Objekte — FBs, FCs, Datenbausteine, Tag-Tabellen — in ein Git-Workspace. Echt diff- und mergebar sind aber nur die Quelltext-Formate SCL und STL; LAD/FBD/GRAPH bleiben XML. Das Gesamtprojekt (.apXX) ist binär und wird nur als Artefakt versioniert.
Welche SPS-Plattformen unterstützen Git am besten?
CODESYS bringt einen nativen Git-Client mit, Beckhoff TwinCAT 3 erbt Git aus dem Visual-Studio-Framework und speichert POUs als XML je Einzeldatei, Phoenix Contact PLCnext ist linux-basiert und damit für Hochsprachen- und Container-Anteile voll git-fähig. TIA Portal geht nur den Umweg über den VCI-Objekt-Export. In allen Fällen gilt: Echte Merges sind nur für textuelle Logik (ST/SCL) realistisch.
Wie rollt man Software deklarativ auf viele Anlagen aus?
Über Edge-/Fleet-GitOps: Tools wie Rancher Fleet, Flux v2 (Azure Arc) oder OpenShift GitOps (Argo CD) ziehen den in Git beschriebenen Soll-Zustand pull-basiert auf Edge-Cluster in den Werken. Leichtgewichtige Distributionen wie K3s oder KubeEdge laufen auch bei WAN-Ausfall autonom weiter. Das Pull-Modell ist in OT-Netzen Pflicht, weil eingehende Verbindungen meist verboten sind.
Was ist der Unterschied zwischen GitOps und DevOps?
DevOps ist die übergeordnete Kultur und Arbeitsweise, die Entwicklung und Betrieb zusammenbringt. GitOps ist ein konkretes Betriebsmodell, das diese Prinzipien für Deployments umsetzt — mit Git als Single Source of Truth und automatischer Reconciliation durch Tools wie Argo CD oder Flux. GitOps ist eine Umsetzungsform innerhalb von DevOps, kein Ersatz.
Erfüllt der Git-Audit-Trail Compliance-Anforderungen?
Teilweise. Die unveränderliche Git-History mit signierten Commits, Baseline-Tags und Pull-Request-Reviews deckt zentrale Nachweispflichten von IEC 61508/61511 und IEC 62443 ab — sie dokumentiert wer, was und wann geändert hat. Sie ersetzt aber nicht die formale Re-Validierung und Abnahme safety-relevanter Änderungen.
Verwandte Artikel
TIA Portal mit Git versionieren: GitHub, GitLab & CI/CD
Openness-Export, mergefähige Quelltexte und eine CI/CD-Pipeline für SPS-Code.
CI/CD für SPS: TIA Portal mit Jenkins automatisieren
Build, Test und Deployment von SPS-Code in einer durchgängigen Pipeline.
ArgoCD vs. Flux: GitOps-Tools im Vergleich 2026
Architektur, UI, Multi-Cluster und Progressive Delivery im Vergleich.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance