Kostenlose DevOps-Analyse
00
CI/CD28. Februar 202615 min Lesezeit

CI/CD für SPS-Entwicklung.
TIA-Portal mit Jenkins.
Automatisiert.

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
01
// 01Kurz erklärt
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 die
SPS-Entwicklung.

In der klassischen Software-Entwicklung ist Continuous Integration und Continuous Delivery seit Jahren Standard. Jede Code-Änderung wird automatisch gebaut, getestet und deployt — weniger Fehler, schnellere Releases.

In der SPS-Entwicklung sieht die Realitaet anders aus. TIA-Portal-Projekte werden manuell kompiliert, per USB-Stick 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.

Laut dem State of DevOps Report erzielen Unternehmen mit ausgereiften CI/CD-Pipelines 2.000-fach häufigere Deployments. Auch in der SPS-Entwicklung sind die Ergebnisse messbar: typischerweise 40-60 % kuerzere Inbetriebnahmezeiten und die Eliminierung manueller Übertragungsfehler. Die offizielle Siemens-Dokumentation beschreibt den Rahmen — hier zeigen wir die praxiserprobte Umsetzung.

-75 %
Manuelle Deployment-Schritte
-60 %
Fehleridentifikation
100 %
Nachvollziehbarkeit
3x
Release-Häufigkeit

Quelle: Projekterfahrungen Comquent (2006-2026)

02
// 02Architektur-Vergleich

Klassische Software
vs. SPS / TIA Portal.

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

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)
03
// 03Pipeline-Stages

Sechs Stages.
Vom Commit zur Anlage.

Vom Git-Commit bis zum kontrollierten Deployment — jede Stage mit ihrer Aufgabe und ihrer Toolchain.

  • /01

    Checkout

    Git · TIA Openness API

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

    Build

    TIA Portal V18+ · TIA Openness · Jenkins Agent

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

    Simulate

    PLCSim Advanced V5+ · SIMIT · Virtual Commissioning

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

    Test

    TIA Test Suite · Custom Scripts · JUnit Reporter

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

    Quality Gate

    Custom Analyzers · IEC 62443 Checks · SonarQube

    Code-Analyse, Namenskonventionen, Sicherheitsregeln und Compliance-Checks prüfen. Bei Verstoss wird die Pipeline gestoppt.
  • /06

    Deploy

    Artifactory/Nexus · TIA Openness · Deployment Scripts

    Artefakte in ein Release-Repository ueberführen. Deployment auf die Ziel-SPS erfolgt kontrolliert im geplanten Wartungsfenster.
// 04Jenkinsfile-Beispiel

Das komplette
Jenkinsfile.

Eine vollständige Pipeline für ein TIA-Portal-Projekt. 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 '''
                    $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"
                    }
                '''
            }
        }

        stage('Simulate & Test') {
            steps {
                powershell '''
                    Start-PLCSimInstance -Name "TestPLC"
                    Download-ToPlcSim -Project ${env:PROJECT_PATH}
                    Invoke-PlcTests -TestSuite "tests/" -OutputFormat "junit" -OutputPath "test-results/"
                    Stop-PLCSimInstance -Name "TestPLC"
                '''
            }
            post {
                always { junit 'test-results/*.xml' }
            }
        }

        stage('Quality Gate') {
            steps {
                powershell '''
                    Test-NamingConventions -Path ${env:PROJECT_PATH}
                    Test-SecurityCompliance -Standard "IEC62443"
                    Test-UnusedVariables -Path ${env:PROJECT_PATH}
                '''
            }
        }

        stage('Package') {
            steps {
                powershell '''
                    $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 '''
                    Deploy-ToStagingPlc -Package "release/MyPlcProject-*.zip" -Target "192.168.1.100"
                '''
            }
        }
    }

    post {
        success { echo "Pipeline erfolgreich abgeschlossen" }
        failure { echo "Pipeline fehlgeschlagen" }
    }
}
Hinweis

Die PowerShell-Cmdlets 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 Verfuegung.

// 05Voraussetzungen

Was Sie
brauchen.

  • /01

    TIA Portal V18 oder hoeher

    Ohne V18 kein stabiler Headless-Build.

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

    Jenkins-Server mit Windows-Agent

    TIA Portal läuft nur unter Windows.

    Der Jenkins-Agent benötigt eine lizenzierte TIA-Portal-Installation. Floating Licenses empfohlen.
  • /03

    PLCSim Advanced V5+

    Für automatisierte Simulation und Tests.

    Die Advanced-Variante unterstützt API-Zugriff und mehrere Instanzen parallel.
  • /04

    Git-Repository

    Projekte als Verzeichnisstruktur speichern.

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

    Netzwerkzugang

    Zugriff auf Repository und SPS.

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

Projektstruktur
und Branching.

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

my-plc-project/
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 ausschliessen
└── .gitattributes          # LFS für große Dateien

Branching-
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
07
// 07Fallstricke

Fuenf Stolperstellen.
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.

  • /01

    Binaere 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.

  • /02

    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.

  • /03

    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.

  • /04

    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. 60-70 % der kritischen Pfade reichen für den Anfang.

  • /05

    Team-Akzeptanz

    Problem

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

    Lösung

    Frueh einbinden, Vorteile demonstrieren ("nie wieder verlorene Änderungen"), Schulungen anbieten und mit einem Pilot-Projekt starten.

// 08Andere Hersteller

Über Siemens hinaus.
CODESYS, Beckhoff, Rockwell.

Die beschriebenen Prinzipien sind herstelleruebergreifend anwendbar. Die Implementierung unterscheidet sich je nach Toolchain, aber Grundkonzept — Versionierung, Build, Simulation, Quality Gates — bleibt identisch.

  • /01

    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.
  • /02

    Beckhoff TwinCAT

    TwinCAT-Projekte basieren auf Visual Studio und lassen sich über MSBuild automatisiert kompilieren. Die Integration in Jenkins oder Azure DevOps ist geradlinig. Tests über TwinCAT-Simulation oder TcUnit.
  • /03

    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.

Unabhaengig 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 kuenftig ohnehin Pflicht.

// 09Häufige Fragen

Was Kunden
wirklich fragen.

Q.01
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.
Q.02
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.
Q.03
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 temporaere und generierte Dateien ausgeschlossen, sodass nur der relevante Steuerungscode versioniert wird.
Q.04
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.
Q.05
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.
Q.06
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 lueckenlose Nachverfolgbarkeit aller Änderungen am Steuerungscode. Zusaetzlich ermöglicht die Automatisierung paralleles Arbeiten mehrerer Entwickler am selben Projekt.
Q.07
Funktioniert CI/CD auch mit anderen SPS-Herstellern als Siemens?
Ja, das Grundprinzip ist herstelleruebergreifend anwendbar — die konkrete Implementierung unterscheidet sich jedoch je nach Toolchain. Für CODESYS, Beckhoff TwinCAT und Rockwell Studio 5000 existieren ebenfalls Ansaetze zur Kommandozeilensteuerung und Pipeline-Integration.
Q.08
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.
// 11 — Einstiegsangebot

2 Wochen.
4.900 EUR.
SPS-Pipeline.

Proof of Concept zum Festpreis: Wir setzen in 2 Wochen eine funktionierende CI/CD-Pipeline für Ihr TIA-Portal-Projekt auf. Build, Test und Quality Gates inklusive.

PoC anfragen
Festpreis · 2 Wochen
Inkl. Dokumentation
// Nächster Schritt

Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.

Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.

Erstgespräch buchen
Seit 2006 · 47+ Projekte
Industrie · Automotive · Finance