CI/CD für TwinCAT: Build-Tools-Landschaft 2026

Kurzfassung TwinCAT hat kein integriertes CI/CD. Die meisten Teams kommen mit lokalen IDE-Builds aus - bis etwas schiefläuft: Ein Entwickler verlässt das Unternehmen, ein Deployment geht um 2 Uhr nachts schief, oder ein Kunde fragt nach Rückverfolgbarkeit, die nicht vorhanden ist. Die realen Optionen sind: Pipeline selbst aufbauen mit Jenkins oder GitHub Actions (dauert Wochen, erfordert laufende Wartung, TwinCAT-Kenntnisse nicht inbegriffen), oder einen Cloud-Dienst nutzen, der TwinCAT bereits unterstützt (~180 €/Monat, dedizierter Build-Node, unbegrenzte Builds, Daten werden nach jedem Build gelöscht). Besser anfangen, bevor der Schmerz einsetzt.

Die Automatisierungsbranche ist in Sachen Tooling der übrigen Softwarewelt wahrscheinlich um ein Jahrzehnt hinterher. Wer in beiden Welten gearbeitet hat, weiß das bereits. TwinCAT ist eine der besseren SPS-Umgebungen, aber die Geschichte rund um Builds, Tests und Deployments endet im Grunde bei „IDE öffnen und Build klicken."

In den meisten Softwareteams sind automatisierte Builds, reproduzierbare Artefakte und Deployment-Audit-Trails Grundvoraussetzungen - keine optionale Aufgabe für ruhigere Zeiten. In der SPS-Entwicklung gelten sie nach wie vor als fortgeschrittene Praxis.

Der typische Workflow in den meisten Betrieben: Code lokal schreiben, lokal bauen, wenn es gut läuft auf Test-Hardware prüfen, deployen und hoffen. Das funktioniert gut, solange man alleine an einer überschaubaren Maschine arbeitet. Es fängt an auseinanderzufallen, sobald mehrere Entwickler an derselben Codebasis arbeiten, ein Kunde Dokumentation verlangt oder irgendwelche regulatorischen Anforderungen an Rückverfolgbarkeit bestehen.

Das eigentliche Problem: Beckhoff liefert eine ausgezeichnete IDE. Alles drumherum - Versionskontrollintegration, reproduzierbare Builds, Testautomatisierung, Artefaktverwaltung - ist das eigene Problem.

Die aktuelle Landschaft

1. Lokale TwinCAT-IDE-Builds (was die meisten machen)

Entwickeln, bauen, und irgendwo auf einem Netzlaufwerk liegt ein Ordner mit „v2_final_FINAL". Für kleine Projekte ist das in Ordnung. Jeder TwinCAT-Entwickler kann damit sofort arbeiten, und es gibt nichts einzurichten.

Die Risse zeigen sich, wenn jemand Neues ins Team kommt und den Build nicht reproduzieren kann, weil die IDE-Version leicht abweicht. Oder wenn der erfahrene Entwickler in Urlaub fährt und das gesamte Kontextwissen mitnimmt. Es gibt keine Testautomatisierung, keinen Audit-Trail, keine Aufzeichnung darüber, was sich zwischen Versionen geändert hat. Es funktioniert - bis es nicht mehr funktioniert.

2. Self-hosted Jenkins + eigenes Tooling

Jenkins aufsetzen, etwas Tooling rund um TwinCATs Automation Interface schreiben, mit Git verbinden - und schon hat man CI/CD. Technisch gesehen.

Das erfordert jemanden, der sowohl Jenkins als auch TwinCAT gut genug kennt, um die Pipeline aufzubauen und zu warten. Diese Kombination ist selten. Das Automation Interface ist außerdem - freundlich formuliert - nicht das angenehmste Ding, auf dem man Automatisierung aufbauen möchte. Es funktioniert, aber man stößt auf viele raue Kanten.

Das größere Problem ist die langfristige Verantwortung. Man hat es gebaut, also wartet man es. Sicherheitsupdates, Jenkins-Upgrades, Build-Skripte, eigene Logik - alles selbst. Es entwickelt sich schnell zum System, das jemand vor Jahren eingerichtet hat und das niemand sonst wirklich versteht.

3. GitHub Actions / GitLab CI

Wer bereits auf GitHub oder GitLab setzt, greift naheliegenderweise zu deren CI/CD. Aber TwinCAT bringt Reibung mit, die bei normaler Software nicht existiert.

TwinCAT benötigt Windows und Visual Studio zum Bauen. Die gemeinsame Infrastruktur von GitHub ist nicht nutzbar - man muss einen eigenen Windows-Build-Agent registrieren und warten. Es gibt auch keine fertige Action für „TwinCAT-Projekt bauen und Unit-Tests ausführen." Dieses Ökosystem existiert schlicht noch nicht, also baut man es selbst. Vom Prinzip her ein modernes Setup. In der Praxis verbringt man mehrere Wochen damit, aufzubauen, was man erwartet hatte, bereits fertig vorzufinden.

4. Zeugwerk CI/CD (Cloud)

Die Alternative ist ein Dienst, der das TwinCAT-Build-Problem bereits gelöst hat. Der Code verbleibt dort, wo er ist - GitHub, GitLab, Bitbucket - und der Cloud-Dienst übernimmt Kompilierung, Unit-Tests und Artefaktgenerierung auf Infrastruktur, die tatsächlich für TwinCAT konfiguriert ist.

So funktioniert es:

1. Code wird ins Git-Repository gepusht
2. Ein leichtgewichtiges Proxy-Skript erkennt den Push
3. Das Proxy sendet Repository-Metadaten und Authentifizierung an die Cloud-Plattform
4. Die Cloud-Plattform baut auf TwinCAT-fähiger Infrastruktur
5. Logs, Artefakte und Testberichte kommen ins eigene CI-System zurück

Wichtig: Der Build läuft auf einem Node, der exklusiv für das jeweilige Team reserviert ist. Kein fremder Code ist auf dieser Maschine, und alles wird unmittelbar nach Abschluss des Builds gelöscht - auch wenn er mittendrin abstürzt. Für Teams, die proprietäre Maschinensoftware ausliefern, ist das keine Kleinigkeit.

Die naheliegende Sorge ist die externe Abhängigkeit und der Repository-Zugriff. Ein NDA sollte selbstverständlich sein. Wer das aus Sicherheitsgründen grundsätzlich ausschließt, hat nachvollziehbare Gründe - aber für die meisten Teams ist es ein vernünftiger Kompromiss, um keine eigene Infrastruktur aufbauen und warten zu müssen.

Zeugwerk leistet einen wertvollen und einzigartigen Beitrag zur Modernisierung der SPS-Softwareentwicklung. Der Build-Service ist gut in GitHub integriert und zuverlässig, er funktioniert einfach. Das Team hat uns beim Onboarding gut unterstützt und ist auch danach schnell und hilfsbereit.

— Brianna Laugher · Principal Software Engineer · Celleo

Von Seiten Zeugwerk werden zudem Themen wie automatisierte Builds (CI/CD), Testing und Dokumentation als zusätzliche Services bereitgestellt und lassen sich sinnvoll in den Entwicklungsprozess integrieren. Mit diesem Set an ‚Werkzeugen’ ist es uns möglich, Entwicklungszeiten zu reduzieren, die Softwarequalität zu erhöhen und gleichzeitig eine langfristig wartbare und skalierbare Architektur sicherzustellen. Insgesamt haben wir durchweg sehr positive Erfahrungen gemacht und sehen im Zeugwerk Framework einen klaren Mehrwert für moderne, strukturierte Automatisierungsprojekte.

— Georg Tauber · Research & Development Electronics · Durst Group

Vergleich

Wohin die Entwicklung geht

Mehrere Faktoren treiben die Branche in Richtung professionelles Build-Tooling - ob Teams bereit sind oder nicht.

Regulatorische Anforderungen sind einer davon. Normen wie ISO 13849 und die Maschinenrichtlinie verlangen zunehmend Rückverfolgbarkeit - dokumentierte Testergebnisse, reproduzierbare Builds, Änderungshistorie. Das lässt sich schwer nachträglich produzieren. Remote-Arbeit ist ein weiterer Faktor. Die Annahme, dass alle Beteiligten um dieselbe Hardware herumstehen können, verschwindet leise.

Der KI-Aspekt ist neuer, aber ernst zu nehmen. LLMs tauchen in Engineering-Workflows auf - Code-Vorschläge, Refactoring, automatisierte Reviews. Aber KI-gestützte Entwicklung funktioniert nur sicher, wenn darunter eine echte Test-Pipeline liegt. Ohne automatisierte Validierung ist ein Code-Vorschlag akzeptieren nur ein schnellerer Weg, einen Fehler einzubauen, der erst in der Produktion auffällt. CI/CD ist das, was diese Werkzeuge tatsächlich nutzbar macht.

In den nächsten Jahren ist zu erwarten, dass Beckhoff mehr in Tooling investiert (PLC++ signalisiert, dass die Lücke bekannt ist), mehr Cloud-Dienste TwinCAT gezielt adressieren und CI/CD schrittweise zum Standard für Teams jeder nennenswerten Größe wird.

Ehrliche Einschätzung

Kleine Teams: Lokale Builds sind vorerst in Ordnung. Der Schmerz kommt meistens, wenn jemand geht - oder wenn ein Kunde nach Dokumentation fragt, die nicht gepflegt wurde. Man merkt es, wenn man an die Wand stößt.

Teams, die das Zeugwerk Framework nutzen: Wer hier ist, denkt bereits richtig über Software-Engineering nach. CI/CD ist der natürliche nächste Schritt - er macht alles andere zuverlässiger.

Teams mit DevOps-Kapazität: Jenkins funktioniert. Nur darauf achten, dass es kein Einzelpersonen-System wird.

Teams, bei denen es einfach funktionieren soll: Cloud-CI ist die ehrliche Antwort. Ja, externe Abhängigkeit. Aber reproduzierbare Builds und Rückverfolgbarkeit, ohne die Infrastruktur selbst aufzubauen.

Die unbequeme Wahrheit

Die meisten Teams in diesem Bereich spüren den Schmerz noch nicht. Lokale Builds funktionieren, manuelle Tests fangen die meisten Fehler ab, und CI/CD klingt nach Overhead für ein Problem, das nicht offensichtlich kaputt ist.

Der Schmerz kommt meistens auf einmal. Der Anruf um 2 Uhr nachts, weil niemand sagen kann, was sich zwischen den letzten beiden Deployments geändert hat. Das dreimonatige Onboarding, weil der Build-Prozess vollständig im Kopf einer Person lebte. Das Kunden-Audit, das nach Testergebnissen fragt, die nicht existieren.

Wenn es dringend wird, ist die Nachrüstung teuer und störend. Teams, die es früh angehen - wenn es noch optional wirkt - sind die, die nicht in diese Situationen geraten.

Fragen zu CI/CD für TwinCAT oder Interesse daran, wie das Zeugwerk-Tooling in der Praxis funktioniert? Einfach melden.