Kostenlose DevOps-Analyse
Zurück zum Blog
CI/CD 15 min Lesezeit 28. Februar 2026

CI/CD für SPS-Entwicklung: TIA-Portal mit Jenkins automatisieren

Schritt-für-Schritt-Anleitung: So automatisieren Sie Build, Test und Deployment von TIA-Portal-Projekten mit Jenkins. Inklusive Jenkinsfile-Beispiel und PLCSim-Integration.

CI/CD Pipeline für SPS-Entwicklung mit TIA Portal und Jenkins
AS

Andreas Schönfeld

Geschäftsführer & DevOps-Berater, Comquent GmbH

18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation

Veröffentlicht: 28. Februar 2026Zuletzt aktualisiert: 1. April 2026

Warum CI/CD für SPS-Entwicklung?

In der klassischen Software-Entwicklung ist Continuous Integration und Continuous Delivery (CI/CD) seit Jahren Standard. Jede Code-Änderung wird automatisch gebaut, getestet und — bei Erfolg — deployt. Das Ergebnis: weniger Fehler, schnellere Releases, zufriedenere Teams.

In der SPS-Entwicklung sieht die Realität anders aus. TIA-Portal-Projekte werden manuell kompiliert, per USB-Stick oder Netzlaufwerk verteilt und ohne systematische Tests auf die Anlage übertragen. Versionierung? Oft eine Kopie des Projektordners mit Datum im Namen.

Das muss nicht so bleiben. Mit der TIA Openness API, PLCSim Advanced und Jenkins lässt sich eine vollwertige CI/CD-Pipeline für SPS-Projekte aufbauen — von der Versionskontrolle bis zum automatisierten Deployment.

Laut dem State of DevOps Report (Google DORA) erzielen Unternehmen mit ausgereiften CI/CD-Pipelines 2.000-fach häufigere Deployments und 200-fach kürzere Lead Times. Auch in der SPS-Entwicklung sind die Ergebnisse messbar: typischerweise 40-60 % kürzere Inbetriebnahmezeiten und die Eliminierung manueller Übertragungsfehler. Die offizielle Siemens-Dokumentation zur Continuous Integration mit TIA Portal beschreibt den technischen Rahmen — in diesem Artikel zeigen wir die praxiserprobte Umsetzung.

Was Sie nach diesem Artikel können

  • TIA-Portal-Projekte in Git versionieren (diff-fähig)
  • Eine Jenkins-Pipeline für automatisierten Build konfigurieren
  • PLCSim Advanced für automatisierte Tests einbinden
  • Quality Gates mit Code-Analyse und Compliance-Checks definieren
  • Ein kontrolliertes Deployment-Konzept für SPS-Code entwickeln

Architektur-Überblick

Die CI/CD-Pipeline für SPS-Entwicklung unterscheidet sich in einigen Punkten grundlegend von klassischen Software-Pipelines. Die wichtigsten Unterschiede:

AspektKlassische SoftwareSPS / TIA Portal
Build-SystemMaven, Gradle, npmTIA Openness API (Headless)
BetriebssystemLinux / Windows / macOSWindows (zwingend)
Test-UmgebungDocker-Container, VMsPLCSim Advanced, SIMIT
DeploymentJederzeit, automatischGeplantes Wartungsfenster
RollbackSekunden (Container)Minuten (SPS-Download)

Diese Unterschiede machen deutlich: Man kann nicht einfach eine IT-Pipeline 1:1 auf die OT-Welt übertragen. Es braucht einen angepassten Ansatz, der die Besonderheiten von SPS-Entwicklung respektiert.

Die 6 Stages der SPS-CI/CD-Pipeline

Vom Git-Commit bis zum kontrollierten Deployment — jede Stage im Detail.

01

Checkout

SPS-Quellcode aus Git-Repository auschecken. TIA-Portal-Projekte werden als Verzeichnisstruktur oder als exportierte XML-Dateien versioniert.

GitTIA Openness API
02

Build

TIA-Portal-Projekt im Headless-Modus kompilieren. Die TIA Openness API ermöglicht automatisierte Builds ohne GUI-Interaktion.

TIA Portal V18+TIA OpennessJenkins Agent
03

Simulate

Kompilierten Code auf PLCSim Advanced laden und gegen virtuelle Anlagenmodelle testen. Hardware-in-the-Loop ohne physische Hardware.

PLCSim Advanced V5+SIMITVirtual Commissioning
04

Test

Automatisierte Funktionstests, Regressionstests und Grenzwerttests ausführen. Testergebnisse werden als JUnit-XML exportiert.

TIA Test SuiteCustom ScriptsJUnit Reporter
05

Quality Gate

Code-Analyse, Namenskonventionen, Sicherheitsregeln und Compliance-Checks prüfen. Bei Verstoß wird die Pipeline gestoppt.

Custom AnalyzersIEC 62443 ChecksSonarQube (optional)
06

Deploy

Artefakte in ein Release-Repository überführen. Deployment auf die Ziel-SPS erfolgt kontrolliert im geplanten Wartungsfenster.

Artifactory/NexusTIA OpennessDeployment Scripts

Jenkinsfile: Das komplette Beispiel

Das folgende Jenkinsfile zeigt eine vollständige Pipeline für ein TIA-Portal-Projekt. Es dient als Startpunkt — passen Sie Pfade, Projektnamen und Qualitätskriterien an Ihre Umgebung an.

Jenkinsfile
pipeline {
    agent { label 'windows-tia' }

    environment {
        TIA_VERSION    = 'V18'
        PROJECT_PATH   = 'src/MyPlcProject'
        PLCSIM_TIMEOUT = '300'
    }

    options {
        timeout(time: 60, unit: 'MINUTES')
        timestamps()
        disableConcurrentBuilds()
    }

    stages {
        stage('Checkout') {
            steps {
                checkout scm
                echo "Projekt ausgecheckt: ${env.GIT_COMMIT}"
            }
        }

        stage('Build') {
            steps {
                powershell '''
                    # TIA Openness Headless Build
                    $tiaPath = "C:\Program Files\Siemens\
                      Automation\Portal ${env:TIA_VERSION}"
                    Import-Module "${tiaPath}\
                      PublicAPI\Siemens.Engineering.dll"

                    $project = [Siemens.Engineering.TiaPortal]::
                      Open(${env:PROJECT_PATH})
                    $project.CompileAll()

                    if ($project.CompileResult.HasErrors) {
                        throw "Build fehlgeschlagen"
                    }

                    echo "Build erfolgreich -
                      keine Kompilierfehler"
                '''
            }
        }

        stage('Simulate & Test') {
            steps {
                powershell '''
                    # PLCSim Advanced starten
                    Start-PLCSimInstance -Name "TestPLC"

                    # Programm auf Simulations-SPS laden
                    Download-ToPlcSim -Project ${env:PROJECT_PATH}

                    # Automatisierte Tests ausführen
                    Invoke-PlcTests -TestSuite "tests/"
                      -OutputFormat "junit"
                      -OutputPath "test-results/"

                    # Simulation beenden
                    Stop-PLCSimInstance -Name "TestPLC"
                '''
            }
            post {
                always {
                    junit 'test-results/*.xml'
                }
            }
        }

        stage('Quality Gate') {
            steps {
                powershell '''
                    # Namenskonventionen prüfen
                    Test-NamingConventions -Path ${env:PROJECT_PATH}

                    # Sicherheitsregeln nach IEC 62443
                    Test-SecurityCompliance -Standard "IEC62443"

                    # Ungenutzte Variablen finden
                    Test-UnusedVariables -Path ${env:PROJECT_PATH}
                '''
            }
        }

        stage('Package') {
            steps {
                powershell '''
                    # Release-Artefakt erstellen
                    $version = "${env:BUILD_NUMBER}"
                    Compress-Archive
                      -Path ${env:PROJECT_PATH}
                      -DestinationPath
                        "release/MyPlcProject-v${version}.zip"
                '''
                archiveArtifacts artifacts: 'release/*.zip'
            }
        }

        stage('Deploy (Staging)') {
            when {
                branch 'release/*'
            }
            steps {
                input message: 'Deployment auf Staging-SPS?',
                      ok: 'Deployen'
                powershell '''
                    # Kontrolliertes Deployment
                    Deploy-ToStagingPlc
                      -Package "release/MyPlcProject-*.zip"
                      -Target "192.168.1.100"
                '''
            }
        }
    }

    post {
        success {
            echo "Pipeline erfolgreich abgeschlossen"
        }
        failure {
            echo "Pipeline fehlgeschlagen"
            // E-Mail-Benachrichtigung an Team
        }
    }
}

Wichtiger Hinweis

Die PowerShell-Cmdlets in diesem Beispiel sind vereinfacht dargestellt. In der Praxis benötigen Sie Wrapper-Scripts, die die TIA Openness API korrekt ansprechen und Fehlerbehandlung implementieren. Wir stellen unseren Kunden erprobte Script-Bibliotheken zur Verfügung.

Voraussetzungen: Was Sie brauchen

1

TIA Portal V18 oder höher

Ältere Versionen unterstützen TIA Openness nur eingeschränkt. Ab V18 ist Headless-Build zuverlässig möglich.

2

Jenkins-Server mit Windows-Agent

TIA Portal läuft nur unter Windows. Der Jenkins-Agent benötigt eine lizenzierte TIA-Portal-Installation.

3

PLCSim Advanced V5+

Für automatisierte Simulation und Tests. Die Advanced-Variante unterstützt API-Zugriff und mehrere Instanzen.

4

Git-Repository

TIA-Portal-Projekte müssen als Verzeichnisstruktur (nicht als einzelne .zap-Datei) gespeichert werden, um diff-fähig zu sein.

5

Netzwerkzugang

Der Jenkins-Agent muss Zugriff auf das Git-Repository und optional auf die Ziel-SPS oder ein Staging-System haben.

Git-Strategie für TIA-Portal-Projekte

Die Versionierung von SPS-Projekten in Git ist der erste und wichtigste Schritt. Ohne saubere Versionskontrolle ist CI/CD nicht möglich. Hier die empfohlene Strategie:

Projektstruktur im Repository

my-plc-project/
├── src/
├── PLC_1/ # SPS-Programm
├── HMI_1/ # HMI-Projekt
└── Safety/ # Safety-Programm
├── tests/
├── unit/ # FB-Unit-Tests
└── integration/ # PLCSim-Tests
├── scripts/
├── build.ps1 # Build-Script
├── test.ps1 # Test-Script
└── deploy.ps1 # Deploy-Script
├── Jenkinsfile # Pipeline-Definition
├── .gitignore # Binaries ausschließen
└── .gitattributes # LFS für große Dateien

Branching-Modell

Für SPS-Projekte empfehlen wir ein vereinfachtes Git-Flow-Modell:

mainProduktionsreifer Code — nur über Merge-Requests
developIntegrations-Branch für laufende Entwicklung
feature/*Feature-Branches für neue Funktionsbausteine
release/*Release-Kandidaten für geplante Wartungsfenster
hotfix/*Dringende Korrekturen für Produktionsanlagen

5 typische Fallstricke — und wie Sie sie vermeiden

Aus über 100 Projekten kennen wir die häufigsten Stolperstellen bei der CI/CD-Einführung für SPS-Entwicklung.

1

Binäre Projektdateien

Problem

TIA-Portal speichert standardmäßig binäre .zap-Dateien, die nicht diff-fähig sind.

Lösung

Projekte als Verzeichnisstruktur speichern und die TIA Openness API für XML-Export nutzen. So werden Änderungen in Git nachvollziehbar.

2

Lizenzverwaltung

Problem

Jeder Jenkins-Agent benötigt eine eigene TIA-Portal-Lizenz. Bei mehreren parallelen Builds steigen die Kosten.

Lösung

Floating Licenses nutzen und die Anzahl paralleler Builds begrenzen. Alternativ: einen dedizierten Build-Agent mit Exklusiv-Lizenz einsetzen.

3

Lange Build-Zeiten

Problem

TIA-Portal-Kompilierung kann bei großen Projekten 10–30 Minuten dauern.

Lösung

Inkrementelle Builds nutzen, nur geänderte Bausteine kompilieren und Build-Caching implementieren. Nightly Full-Builds für Sicherheit.

4

Testabdeckung

Problem

Automatisierte Tests für SPS-Code sind deutlich schwieriger als für klassische Software.

Lösung

Mit Unit-Tests für Funktionsbausteine (FBs) starten, dann schrittweise Integrationstests mit PLCSim Advanced aufbauen. 100 % Abdeckung ist nicht das Ziel — 60–70 % der kritischen Pfade reichen für den Anfang.

5

Team-Akzeptanz

Problem

SPS-Programmierer sind oft nicht mit Git und CI/CD vertraut. Widerstand gegen neue Workflows.

Lösung

Früh einbinden, Vorteile demonstrieren (z.B. "nie wieder verlorene Änderungen"), Schulungen anbieten und mit einem Pilot-Projekt starten.

Typische Ergebnisse nach der Einführung

Was unsere Kunden nach der Einführung von CI/CD für SPS-Entwicklung berichten:

75 %

weniger manuelle Deployment-Schritte

60 %

schnellere Fehleridentifikation

100 %

Nachvollziehbarkeit aller Änderungen

3x

häufigere Releases bei weniger Fehlern

Über Siemens hinaus: CI/CD für CODESYS, Beckhoff und Rockwell

Die in diesem Artikel beschriebenen Prinzipien sind herstellerübergreifend anwendbar. Die konkrete Implementierung unterscheidet sich je nach Toolchain, aber das Grundkonzept — Versionierung, automatisierter Build, Simulation, Quality Gates — bleibt identisch.

CODESYS

CODESYS bietet mit dem CODESYS Automation Server eine eigene CI/CD-Lösung. Alternativ lässt sich die CODESYS-Kommandozeile in Jenkins-Pipelines integrieren. Die Projekte sind textbasiert und dadurch nativ git-freundlich.

Beckhoff TwinCAT

TwinCAT-Projekte basieren auf Visual Studio und lassen sich über MSBuild automatisiert kompilieren. Die Integration in Jenkins oder Azure DevOps ist dadurch relativ geradlinig. Tests können über die TwinCAT-Simulation oder TcUnit ausgeführt werden.

Rockwell Studio 5000

Rockwell bietet mit FactoryTalk Logix Echo eine Emulations-Umgebung ähnlich PLCSim Advanced. Die Kommandozeilensteuerung ist eingeschränkter als bei Siemens, aber über die Logix Designer SDK lassen sich Builds und Deployments automatisieren.

Unabhängig vom Hersteller gilt: Der Industrial-DevOps-Ansatz ist die strategische Klammer. Die Wahl des SPS-Herstellers bestimmt die Werkzeuge, nicht das Prinzip. Für die Compliance-Anforderungen des Cyber Resilience Act ist eine nachvollziehbare, automatisierte Build-Pipeline künftig ohnehin Pflicht.

Fazit: Starten Sie mit einem Pilot-Projekt

CI/CD für SPS-Entwicklung ist kein Alles-oder-Nichts-Projekt. Unsere Erfahrung aus über 47 Projekten im DACH-Raum zeigt: Beginnen Sie mit einem überschaubaren Pilot — ein einzelnes TIA-Portal-Projekt, ein Jenkins-Agent, eine einfache Pipeline mit Build und Basis-Tests. Die Ergebnisse sprechen für sich: 40-60 % kürzere Inbetriebnahmezeiten, null manuelle Übertragungsfehler und lückenlose Nachverfolgbarkeit aller Änderungen.

Die Technologie ist reif, die Tools sind verfügbar und die Vorteile sind messbar. Was es braucht, ist der Mut zum ersten Schritt — und idealerweise einen erfahrenen Partner, der die Fallstricke kennt.

Proof of Concept in 2 Wochen

Wir setzen in 2 Wochen eine funktionierende CI/CD-Pipeline für Ihr TIA-Portal-Projekt auf — zum Festpreis. Build, Test und Quality Gates inklusive. Kein Risiko, sofort nutzbar.

Häufig gestellte Fragen zu CI/CD für SPS

Kann man SPS-Programmierung mit CI/CD automatisieren?

Ja, SPS-Projekte wie Siemens TIA-Portal lassen sich vollständig in CI/CD-Pipelines integrieren — inklusive automatisiertem Build, Simulation mit PLCSim und Quality Gates. Die Automatisierung reduziert manuelle Fehler und beschleunigt den Release-Zyklus erheblich.

Welche CI/CD-Tools eignen sich für TIA-Portal-Projekte?

Jenkins ist der am häufigsten eingesetzte CI/CD-Server für SPS-Automatisierung, da er über Plugins und Kommandozeilenaufrufe flexibel an TIA-Portal angebunden werden kann. Auch GitLab CI und Azure DevOps sind grundsätzlich geeignet, erfordern aber Custom-Skripte für die Siemens-Toolchain.

Wie versioniert man Steuerungscode mit Git?

TIA-Portal-Projekte werden als exportierte Dateien in ein Git-Repository eingecheckt, wobei die Projektstruktur in sinnvolle Verzeichnisse aufgeteilt wird. Durch .gitignore-Regeln werden temporäre und generierte Dateien ausgeschlossen, sodass nur der relevante Steuerungscode versioniert wird.

Was ist PLCSim Advanced und wie wird es in CI/CD genutzt?

PLCSim Advanced ist eine Software-Simulation von Siemens, die eine virtuelle SPS bereitstellt und sich per API steuern lässt. In der CI/CD-Pipeline wird PLCSim Advanced gestartet, das kompilierte Programm geladen und automatisierte Tests gegen die Simulation ausgeführt.

Wie lange dauert die Einführung von CI/CD für SPS-Entwicklung?

Ein Proof of Concept mit einer funktionsfähigen Pipeline für ein Pilotprojekt lässt sich in zwei Wochen aufsetzen. Die Skalierung auf weitere Projekte und Teams dauert typischerweise drei bis sechs Monate.

Welche Vorteile bringt CI/CD in der SPS-Entwicklung?

Typische Ergebnisse sind eine Reduzierung der Inbetriebnahmezeit um 40–60 %, die Eliminierung manueller Übertragungsfehler und eine lückenlose Nachverfolgbarkeit aller Änderungen am Steuerungscode. Zusätzlich ermöglicht die Automatisierung paralleles Arbeiten mehrerer Entwickler am selben Projekt.

Funktioniert CI/CD auch mit anderen SPS-Herstellern als Siemens?

Ja, das Grundprinzip ist herstellerübergreifend anwendbar — die konkrete Implementierung unterscheidet sich jedoch je nach Toolchain. Für CODESYS, Beckhoff TwinCAT und Rockwell Studio 5000 existieren ebenfalls Ansätze zur Kommandozeilensteuerung und Pipeline-Integration.

Was sind Quality Gates in einer SPS-CI/CD-Pipeline?

Quality Gates sind automatisierte Prüfpunkte, die bestimmte Qualitätskriterien erzwingen, bevor der Code die nächste Pipeline-Stage erreicht. Typische Gates für SPS-Code umfassen Kompilierungserfolg, Simulationstests, Code-Analyse und Dokumentationsvollständigkeit.

Bereit für den nächsten Schritt?

Vereinbaren Sie ein kostenloses Erstgespräch — wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen

Von Comquent-Experten beraten — seit 2006 | 47+ erfolgreiche Projekte | Industrie, Automotive, Finance