CI/CD-Tools für die Fertigung. IndustrialFlow im Vergleich.
Die Fertigung spielt täglich Software auf SPS, Embedded-Controller und Edge-Gateways, oft mit CI/CD-Tools, die für Cloud-Apps gebaut wurden. Dieser Artikel vergleicht vier Plattformen nach 14 Kriterien und zeigt, was IndustrialFlow anders macht: Die CI/CD-Plattform von Comquent läuft auf Jenkins-Basis im eigenen Netz, kennt Wartungsfenster und Maschinenzustand und erzeugt die Nachweise für IEC 62443, NIS2 und CRA aus jedem Build.
IndustrialFlow im Browser ansehen.
Der UI-Prototyp zeigt Pipelines, KI-Assistent, Wartungsfenster und Audit-Trail so, wie sie in der Plattform aussehen. Ohne Anmeldung und ohne Installation.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
DevOps, CI/CD und Industrial Automation seit 2006.
Welche Plattformen unterstützen DevOps für langlebige industrielle Anlagen?
Für langlebige Industrieanlagen eignen sich CI/CD-Plattformen mit OT-nativen Eigenschaften: Air-Gap-Betrieb ohne Cloud-Zwang, Wartungsfenster-Steuerung, OPC-UA-Statusabfrage vor dem Deployment, Rollback ohne Datenverlust und auditierbare Compliance (IEC 62443, NIS2, CRA). Reine Cloud-Tools wie GitHub Actions oder Azure DevOps erfüllen das nicht. IndustrialFlow ist genau dafür gebaut: ein Jenkins-Kern mit moderner CI/CD-Pipeline, KI-Assistent (Claude API oder lokal Ollama) und OT-Proxy-Architektur.
Aufbau, Branchen und Pilot: Produktseite IndustrialFlow
Ist IndustrialFlow bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Warum scheitern Cloud-CI/CD-Tools
in der Fertigung?
Weil sie für Server gebaut sind, die jederzeit erreichbar sind und sich jederzeit neu starten lassen. Eine Fertigungslinie ist beides nicht. Das OT-Netz ist vom Internet getrennt, Änderungen sind nur im Wartungsfenster erlaubt, und vor jedem Deployment zählt, ob die Maschine gerade produziert.
Ein typischer Fall: Sie rollen eine neue Firmware auf 60 Produktionsmaschinen in drei Werken aus. Das Pipeline-Tool ist GitHub Actions, hervorragend für den E-Commerce-Service, aber für Cloud-Native gebaut und nicht für segmentierte OT-Netze.
Also entstehen Workarounds: Firewall-Ausnahmen von Hand, Skripte, die den Air-Gap überbrücken, und kein Audit-Log, das einem TISAX-Prüfer standhält. Meist kam das Tool über die IT ins Haus, ausgewählt für die Webanwendungen. Die erste Firmware-Pipeline hängte jemand daran, weil der Zugang schon eingerichtet war.
Welche Tools diese Lücke schließen und welche nicht, zeigt der Vergleich im nächsten Abschnitt.
AIWelche CI/CD-Tools eignen sich
für die Fertigung?
Für die Fertigung taugen die Tools, die ohne Cloud auskommen und den Zustand der Anlage kennen. Jenkins, GitLab CI (self-managed) und IndustrialFlow laufen vollständig on-premise. Bei den SaaS-Varianten von GitHub Actions und Azure DevOps bleibt die Steuerungsebene in der Cloud, auch wenn die Runner im eigenen Netz stehen.
Ihre On-Prem-Editionen GitHub Enterprise Server und Azure DevOps Server laufen zwar vollständig im eigenen Netz, einen Check gegen den Zustand der Maschine über OPC UA bringen aber auch sie nicht mit. Die Tabelle stellt IndustrialFlow, Jenkins ohne Erweiterungen, GitHub Actions in der SaaS-Variante und GitLab CI nach 14 Kriterien gegenüber.
| Kriterium | IndustrialFlow | Pure Jenkins | GitHub Actions | GitLab CI |
|---|---|---|---|---|
| Air-Gap-Betrieb ohne Zusatzaufbau | Nativ, dokumentiert | Manuell, möglich | Self-hosted Runner nötig | Self-hosted nötig |
| OT-Proxy / OPC-UA-Integration | Eingebaut | Custom-Plugin | Nicht vorgesehen | Nicht vorgesehen |
| Wartungsfenster nativ | YAML-Config pro Env | Manuelle Cron-Locks | Workflow-Custom | Workflow-Custom |
| Produktionssperre (OPC UA) | Pre-Deploy-Check | Custom-Step | Nicht vorgesehen | Nicht vorgesehen |
| KI-Assistent (Claude API) | Eingebaut | Manuell via REST | Action im Marketplace | Custom-Job |
| KI-Assistent lokal (Ollama) | Eingebaut, supported | Manuell | Self-hosted Runner | Self-hosted Runner |
| NIS2-Audit-Trail (BSI-tauglich) | Default-Output | Plugin-Bastelei | Custom-Logging | Custom-Logging |
| CRA SBOM (CycloneDX + SPDX, signiert) | Per Build | Plugin-Stack | Action-Stack | Job-Stack |
| IEC 62443 Compliance-Reports | Auto-generiert | Manuelles Tooling | Manuelles Tooling | Manuelles Tooling |
| Jenkins MCP-Server-Integration | Default | Plugin (offiziell) | Indirekt via Jenkins | Indirekt via Jenkins |
| Jenkinsfile-Kompatibilität | 100 % (Jenkins-Kern) | 100 % | Keine | Keine |
| Multi-Site / Multi-Werk-Controller | Eingebaut | Manuell | Self-hosted | Self-hosted |
| Datenresidenz DACH ohne Zusatzaufbau | On-Prem default | On-Prem default | GitHub-Cloud | GitLab-Cloud / On-Prem |
| Setup-Zeit bis erster Pipeline-Lauf | ~10 Min (Compose) | Stunden bis Tage | Minuten (Cloud) | Minuten (Cloud) |
Stand: April 2026 · Vergleich aus Sicht industrieller Anwender mit OT-Anforderungen · Cloud-Tools decken viele Punkte mit zusätzlichem Engineering ab, IndustrialFlow liefert sie als Default.
Was hinter der Spalte IndustrialFlow steckt, erklären die nächsten beiden Abschnitte. Wer eine bestehende Jenkins-Landschaft hat, findet die Abwägung zwischen den großen Plattformen im Vergleich Jenkins, GitLab CI und Azure DevOps.
Was ist
IndustrialFlow?
IndustrialFlow ist die CI/CD-Plattform von Comquent für Industrial DevOps: ein Jenkins-Kern mit einem Dashboard, das für jede Maschine den freigegebenen und den laufenden Softwarestand zeigt, einem KI-Assistenten und den OT-Funktionen, die Cloud-Tools fehlen.
Jenkins ist mächtig und läuft ohne Internet, aber seine Oberfläche stammt aus einer anderen Zeit. GitHub Actions und GitLab CI sind modern, aber für die Cloud gedacht. IndustrialFlow setzt auf Jenkins auf, statt es zu ersetzen, und ergänzt drei Bausteine:
- /01
Jenkins als Kern
Seit rund 20 Jahren im Einsatz, mehr als 2.000 Plugins, und bestehende Jenkinsfiles laufen ohne Änderung. Kein Migrationsrisiko, kein verlorenes Teamwissen.
- /02
Industrial DevOps Dashboard
Eine Weboberfläche, die für jede Maschine und Station zeigt, welcher Stand freigegeben ist und welcher tatsächlich läuft. Dazu Vorlagen für industrielle Pipelines und ein Pipeline-Assistent im Chat.
- /03
KI-Assistent, auch ohne Cloud
Er analysiert Build-Fehler, schreibt Pipeline-Code und bewertet das Risiko eines Deployments. Er läuft über die Claude API oder vollständig lokal über Ollama; dann verlassen keine Produktionsdaten das Werk.
Was kann IndustrialFlow,
was Cloud-CI/CD nicht kann?
Fünf Funktionen machen den Unterschied, und jede steht in der Vergleichstabelle als eigene Zeile: Betrieb ohne Internet, KI-Assistent, Wartungsfenster mit Produktionssperre, Nachweise aus jedem Build und die Weiterverwendung bestehender Jenkinsfiles.
AI- /01
Betrieb im eigenen Netz, auch ohne Internet
Die Segmentierung bleibt, wie sie ist.
Produktionsnetze sind aus gutem Grund vom Internet getrennt, die IEC 62443 teilt sie in Zonen und Conduits. Der OT-Proxy in der DMZ bringt Deployments per TLS-Tunnel in die Fertigungszone. Er baut seine Verbindung von innen nach außen auf, eingehende Verbindungen in die Fertigung gibt es nicht. Container-Registry, Plugin-Mirror und das KI-Modell laufen lokal, kein Build wartet auf eine externe Quelle.
Zielsysteme: Windows Embedded, Linux RTOS, Bare Metal, Container (Docker, K3s), SPS über OPC UA
- /02
KI-Assistent für Pipelines und Fehleranalyse
Die Ursache eines Build-Fehlers in Klartext.
Statt eine Stunde im Build-Log zu suchen, fragen Sie: „Warum ist der Build fehlgeschlagen?“ Der Assistent liest das Log, gleicht es mit den letzten Code-Änderungen ab und antwortet auf Deutsch, mit einem Vorschlag zur Behebung. Für neue Pipelines reicht eine Beschreibung in Klartext, daraus entsteht das Jenkinsfile. Im Werksnetz läuft der Assistent lokal über Ollama. Vor jedem Aufruf der Claude API entfernt IndustrialFlow Hostnamen, IP-Adressen und personenbezogene Daten aus dem Log.
Pipeline-Generator · Fehleranalyse · Risikobewertung von Merge Requests · Auswertung von Security-Scans
- /03
Wartungsfenster und Produktionssperre
Kein Deployment in eine laufende Anlage.
Eine Stunde ungeplanter Stillstand kostet eine mittelständische Linie rund 15.000 € (Herleitung in §01). In IndustrialFlow steht das Wartungsfenster pro Umgebung in der Konfiguration, außerhalb davon erreicht kein Stand eine Produktionsumgebung. Unmittelbar vor dem Deployment liest der OT-Proxy den Maschinenzustand. Produziert die Anlage, wartet der Job in der Warteschlange oder bricht sauber ab.
Pipeline-YAML: maintenance_window, production_lock, pre_deploy_checks
- /04
Security-Scans und Nachweise aus jedem Build
Das Audit findet die Belege fertig vor.
Jeder Build durchläuft SAST mit Semgrep sowie Dependency- und Container-Scans mit Trivy. Jedes Artefakt bekommt eine signierte SBOM, wie sie der Cyber Resilience Act verlangt. Jedes Deployment landet in einem unveränderlichen Audit-Log, aus dem IndustrialFlow Reports nach IEC 62443 erzeugt. Policy-as-Code mit OPA/Rego hält Deployments auf, die eine Sicherheitsregel verletzen, bevor sie starten.
Reports: IEC 62443, TISAX-Vorbereitung, ISO 27001 Audit-Trail, SBOM für den CRA
- /05
Jenkins bleibt, Jenkinsfiles laufen weiter
Zehn Jahre Pipeline-Logik schreibt niemand ab.
IndustrialFlow ersetzt Jenkins nicht, Jenkins ist der Kern. Bestehende Jenkinsfiles und Shared Libraries laufen unverändert. Das ist Absicht: Der häufigste Grund, eine überfällige Modernisierung zu vertagen, ist die Sorge um gewachsene Pipeline-Logik und das Wissen des Teams darüber. Neue Pipelines schreiben Sie auf Wunsch in einem vereinfachten YAML, aus dem IndustrialFlow ein sauberes Jenkinsfile erzeugt. Dazu kommen die Shared Libraries für Industrie-Deployments, die bei Comquent in 20 Jahren Projektarbeit entstanden sind.
Übernahme einer bestehenden Jenkins-Instanz: nach unserer Erfahrung weniger als ein Arbeitstag
Welche Probleme aus dem Werk
löst IndustrialFlow?
Die zehn Symptome, die wir in Kundenprojekten am häufigsten sehen, jeweils mit Ursache und Lösung in IndustrialFlow. Wenn Sie eine dieser Zeilen aus dem eigenen Werk kennen, lohnt der genauere Blick.
SPS-Firmware ohne USB-Sticks und Maschinenstillstand automatisiert deployen
Übergabe per Datenträger, kein Versionsmanagement, überschrittene Wartungsfenster. Jede Übergabe ist ein Sicherheits- und Qualitätsrisiko.
OT-Proxy, OPC-UA-Check vor dem Deployment und konfigurierte Wartungsfenster. Das Deployment startet nur, wenn die Maschine im Wartungsmodus ist; pro SPS und Firmware-Version entsteht ein Audit-Eintrag.
Brown-Field-Maschinenpark inventarisieren und schrittweise automatisieren
Kein zentraler Stand, welche Steuerung welche Firmware-Version trägt; Excel-Tracker, Wissen im Kopf einzelner Engineers. Verlässt einer von ihnen das Unternehmen, geht der Firmware-Stand von zwanzig Maschinen mit ihm.
IndustrialFlow liest die installierte Basis per OPC UA aus, baut daraus ein Soll-/Ist-Repository und nimmt Maschine für Maschine auf, ohne Big-Bang-Migration.
OT-Netzwerk-Segmentierung respektieren statt aufweichen (IEC 62443)
CI/CD-Tools brauchen Zugriff aufs OT-Segment, die Firewall-Regeln wachsen, das Zonenmodell zerfällt.
OT-Proxy in der Fertigungs-DMZ. Deployment-Befehle laufen über einen TLS-Tunnel mit Zertifikats-Authentifizierung, die Conduits bleiben kontrolliert, jeder Übergang landet im Audit-Log.
Hardware-in-the-Loop-Tests in CI/CD-Pipeline integrieren
HiL-Stände sind teuer und werden nacheinander genutzt, gebucht per Excel. Die Tests laufen am Ende des Sprints statt beim Build.
HiL als Pipeline-Stage mit Job-Queue: Pro Build reserviert die Pipeline einen Slot, Testdaten sind mit dem Commit versioniert, Ergebnisse hängen an der Code-Änderung. Konflikte löst der Scheduler über Pipeline-Lock und Slot-Booking.
Multi-Werk-Deployment koordinieren ohne Pro-Werk-Skript
Jedes Werk hat eigene Pipelines, die Standorte driften auseinander, eine Gesamtsicht fehlt. Ein Compliance-Audit wird so zur Handarbeit.
Multi-Site-Controller: zentrale Pipeline-Definition, ein OT-Proxy pro Werk, ein gemeinsamer Audit-Trail. Ein Rollout, mehrere Werke, ein Compliance-Report.
Maschinenstatus via OPC UA prüfen vor Deployment (Production-Lock)
Deployments treffen laufende Produktion, Werkstücke gehen verloren. Den einzigen Vorab-Check macht ein Anruf in der Halle.
Die Abfrage per OPC UA ist eine Pipeline-Stage: Läuft die Anlage, geht der Job in die Warteschlange oder bricht sauber ab. Konfigurierbar pro Pipeline-Schritt (production_lock).
Rollback bei OT-Deployment ohne Datenverlust auf der SPS
Standard-CI/CD-Tools kennen keine Wiederherstellungspunkte für die OT. Das manuelle Backup ist Pflicht und wird vergessen.
Snapshot der SPS-Konfiguration vor dem Deployment, Blue-Green über Anlagenpaare, automatischer Restore bei erkanntem Fehler, alles im Audit-Log.
Embedded Cross-Compile-Toolchains stabilisieren (ARM, AArch64, x86 Embedded)
Toolchain-Versionen unterscheiden sich von Laptop zu Laptop, „bei mir baut es“ ist der Standardfehler, Linker-Fehler kosten Stunden.
Reproduzierbare Build-Container pro Zielarchitektur, die Toolchain-Version liegt im Repository, und der KI-Assistent erklärt Cross-Compile-Fehler aus dem Build-Log in Sekunden.
Recipe-/Parameter-Management in Pharma & Food versionieren (GxP)
Rezepturen und Anlagenparameter liegen außerhalb von Git, der Audit-Trail nach FDA 21 CFR Part 11 bzw. EU-GMP Annex 11 fehlt, die Validierung wird zur Last.
Rezepturen als Code (YAML/JSON) im Repository, signierte Deployments mit Vier-Augen-Freigabe, Audit-Log mit Benutzer, Zeitstempel und Hash für GxP- und ISO-13485-Audits.
PLC-Vendor-übergreifende Pipelines (Siemens TIA, Beckhoff TwinCAT, Rockwell Studio 5000)
Jeder Hersteller hat eigene Kommandozeilen, Werkzeuge und Konventionen; zwischen Standorten und Teams wird nichts wiederverwendet.
Shared Library mit einer gemeinsamen Schnittstelle für Siemens, Beckhoff und Rockwell (deploySps) und Pipeline-Vorlagen pro Werkzeug, aus 20 Jahren Projekterfahrung.
Quelle der Auswahl: Comquent-Projekte zu Industrial DevOps 2024–2026, gewichtet nach Häufigkeit und Eskalationsrisiko. Jede Zeile entspricht einem Modul des 90-Tage-Pilots.
Was ändert sich im Werk,
wenn die Pipeline übernimmt?
Rollouts werden kürzer, Rollbacks automatisch, und die Nachweise entstehen nebenbei. Drei Szenarien aus Automotive, Maschinenbau und Chemie zeigen das jeweils mit Ausgangslage, Umsetzung und Ergebnis. Danach folgt die Rechnung in Euro.
AI- Ausgangslage
Ein Tier-1-Zulieferer muss neue SPS-Firmware auf 47 Produktionsmaschinen in zwei Werken bringen. Bisher: manuelle Abläufe, USB-Sticks, keine Versionskontrolle, kein Rollback. Der TISAX-Audit ist in drei Monaten.
Umsetzung mit IndustrialFlowIn beiden Werken läuft ein OT-Proxy, der über die segmentierten Netzzonen kommuniziert. Die Pipeline prüft vor jedem Deployment den Maschinenstatus per OPC UA, wartet auf das Wartungsfenster und spielt Maschine für Maschine im Blue-Green-Verfahren ein. Bei einer Abweichung rollt sie automatisch zurück. Jeder Schritt landet im Audit-Log, aus dem IndustrialFlow den TISAX-Report erzeugt.
ErgebnisDeployment-Zeit pro Maschine von 6 Stunden (manuell) auf 45 Minuten. Vollständiger TISAX-Audit-Trail ohne Handdokumentation. Kein Deployment mehr in laufende Produktion.
- Ausgangslage
Ein Maschinenbauer entwickelt Embedded-Software für seine CNC-Steuerungen. Build-Fehler bei der Cross-Compilation kosten im Schnitt 2 Stunden Debugging pro Entwickler und Woche. Security-Scans laufen von Hand, unregelmäßig und ohne Nachverfolgung.
Umsetzung mit IndustrialFlowDer KI-Assistent analysiert jeden gescheiterten Embedded-Build in Sekunden: Toolchain-Inkompatibilitäten, fehlende Cross-Compile-Abhängigkeiten, Linker-Fehler, jeweils mit konkretem Lösungsvorschlag. SAST und Dependency-Scanning laufen bei jedem Commit. Die SBOM entsteht automatisch und signiert, passend für den Cyber Resilience Act.
ErgebnisDebugging-Zeit für Builds um 70 % reduziert. Alle Artefakte mit SBOM und Signatur. Security-Probleme fallen im Schnitt 3 Tage früher auf.
- Ausgangslage
Der Konzern will seine IT-DevOps-Pipeline erstmals mit dem OT-Netz verbinden. Die OT-Security hat Bedenken: Sichtbarkeit, Kontrolle, klare Zuständigkeiten.
Umsetzung mit IndustrialFlowKlare Rollentrennung über RBAC: Das OT-Security-Team bekommt Lesezugriff und Alarme, aber keine Deployment-Rechte auf Produktionssysteme. Der OT-Proxy ist die kontrollierte Schleuse, einen direkten Zugang aus der IT-Pipeline ins OT-Netz gibt es nicht. Jede Pipeline-Aktion erzeugt einen Eintrag im Audit-Log, den beide Teams sehen.
ErgebnisDie OT-Security sieht alles und behält die Kontrolle. Das DevOps-Team deployt Routine-Updates ohne manuelle Genehmigungsschleife. Deployment-Frequenz von monatlich auf wöchentlich.
Was kostet ein manueller Firmware-Rollout im Jahr?
Annahmen: Tier-1-Zulieferer, 47 Maschinen, ein Firmware-Rollout pro Quartal, Engineer-Stundensatz 110 €, Stillstand 15.000 € je Stunde. Die Zeiten pro Maschine (6 h manuell, 45 min automatisiert) stammen aus Szenario 01. Mehrere Standorte oder zusätzliche Audits treiben die Summe nach oben.
124.080 € Engineer-Zeit (6 h × 47 Maschinen × 4 Quartale × 110 €) + 60.000 € für ein Fehl-Deployment mit 4 h Stillstand × 15.000 € + 4.400 € Compliance-Doku (40 h × 110 €).
15.510 € Engineer-Zeit (45 min × 47 × 4 × 110 €) + 15.000 € für ein Fehl-Deployment, das der automatische Rollback auf 1 h Stillstand begrenzt. Compliance-Reports kommen aus der Pipeline. Differenz ~158.000 € im Jahr pro Werksverbund, vor Lizenzkosten.
Quellenlage: Stillstand 15.000 € je Stunde und 4 h je softwarebedingtem Stillstand aus der Herleitung in Kosten senken mit Industrial DevOps (Referenz: Siemens True Cost of Downtime 2024, dort 2,3 Mio. USD je Stunde in großen Automobilwerken). Die Rechnung ist bewusst konservativ; an einem OEM-Band kostet dieselbe Stunde ein Vielfaches. Mögliche NIS2-Bußgelder sind nicht eingerechnet. Eigene Zahlen rechnen Sie im ROI-Rechner durch.
Passt IndustrialFlow zu Ihren
bestehenden Tools?
Meist ja, weil IndustrialFlow nichts ersetzen muss, was schon gut läuft. Jenkins bleibt der Kern, GitHub Actions oder GitLab CI können für die IT-Software weiterlaufen, und IndustrialFlow übernimmt den Weg auf die Anlage.
| Situation | Empfehlung |
|---|---|
| Sie betreiben Jenkins und wollen modernisieren | IndustrialFlow direkt: Jenkins bleibt als Backend, neue Oberfläche und KI-Funktionen sind sofort da. |
| Sie nutzen GitHub Actions für die IT, brauchen aber OT-Deployments | IndustrialFlow parallel für die OT: GitHub Actions für IT-Software, IndustrialFlow für OT-Ziele. |
| Sie starten neu und wollen eine Plattform für alles | IndustrialFlow als primäre Plattform für alle Pipelines, IT und OT. |
| Sie haben Air-Gap-Anforderungen | IndustrialFlow im Offline-Modus: alles on-premise, lokale KI, private Registry. |
Wo stehen Sie
bei der Automatisierung?
In den Werken, die wir sehen, liegt der Einstieg meist zwischen Level 1 (Skripte) und Level 2 (ein CI-Server ohne Anbindung an die OT). IndustrialFlow ist für Level 3 gebaut, setzt die Stufen davor aber nicht voraus; auch der Projektordner auf dem Netzlaufwerk ist ein Startpunkt.
Warum die Reihenfolge der Stufen nicht verhandelbar ist, erklärt der Leitfaden KI in der Produktion: Automatisierung zuerst.
AIManuell
USB-Sticks, Excel-Tracker, Wissen im Kopf
Risiko:Sehr hoch · keine Versionskontrolle, kein Audit
Abläufe dokumentieren, erste Pipeline für eine unkritische Anlage
Scripted
Bash-/PowerShell-Skripte, Ad-hoc-Cron-Jobs
Risiko:Hoch · Skripte sind unversioniert, Drift bleibt unentdeckt
CI-Server einführen, Skripte ins Git, erste Pipeline-Definitionen
CI/CD lokal
Jenkins steht, aber ohne Anbindung an die OT und ohne Audit-Trail
Risiko:Mittel · die IT-Pipeline reicht nicht in die OT-Zone
OT-Proxy, Wartungsfenster, signierte Artefakte, Audit-Log
GitOps Industrial
Versioniert, auditierbar, über mehrere Werke
Risiko:Niedrig · Compliance-Reports entstehen automatisch
KI-Assistent für Fehleranalyse, Pipeline-Generator, Abgleich zwischen Werken
Self-Healing
Drift-Erkennung, Agenten-Workflows, automatisches Rollback
Risiko:Niedrig · KI-gestützte Selbstheilung mit menschlicher Freigabe
Agenten fürs Onboarding, Pipeline-Trigger aus der vorausschauenden Wartung
Der DevOps-Reifegrad-Schnellcheck stellt 10 Fragen, rechnet einen Score aus und schickt Ihnen die drei Schritte per E-Mail, die sich zuerst rechnen.
Wie führt man IndustrialFlow
in 90 Tagen ein?
In vier Phasen über zwölf Wochen: zuerst eine unkritische Pilot-Pipeline, dann die KI-Funktionen, dann der erste OT-Proxy an einer Testmaschine und zuletzt Nachweise und weitere Teams. Eine produzierende Anlage berührt der Pilot erst, wenn Phase 3 im Trockenlauf bestanden ist.
Pilot-Pipeline
Eine unkritische Pipeline aus dem bestehenden Jenkins oder eine manuelle Deployment-Routine auswählen. IndustrialFlow per Docker Compose installieren; die Grundinstallation steht nach etwa zehn Minuten.
KI-Funktionen aktivieren
KI-Assistent freischalten, die nächsten zehn Build-Fehler von ihm analysieren lassen und die Zeitersparnis messen. Eine neue Pipeline aus der Vorlagengalerie erzeugen. Der erste kryptische Linker-Fehler, der bisher Stunden im Build-Log gekostet hat, ist dann in Sekunden erklärt, samt Hinweis auf die fehlende Cross-Compile-Abhängigkeit.
OT-Integration
Den ersten OT-Proxy in der Fertigungsumgebung installieren und mit einem Ziel außerhalb der Produktion starten, etwa einer Testmaschine. Wartungsfenster konfigurieren und die Produktionssperre im Trockenlauf testen.
Compliance & Skalierung
SBOM und Security-Scans für alle Pipelines aktivieren, den ersten Report nach IEC 62443 erzeugen, weitere Teams und Projekte einbinden. Über RBAC sieht und darf jede Rolle nur, was sie braucht.
Für Maschinenbau und Versorger steht der Pilot ausführlich in je einem Whitepaper: Woche für Woche, mit einem Beispiel aus dem Projektalltag und dem Abnahmekriterium je Phase. Im Maschinenbau ist das in Phase 1 ein Commit, der ohne Handgriff einen Compile auslöst. Beim Versorger ist es eine Liste, auf der für jede Station der gelesene Stand steht.
Whitepaper · 22 Seiten · PDF · Oktober 2026
Welcher Programmstand läuft auf Ihren Maschinen?
Was ein Maschinenbauer von einer CI/CD-Plattform verlangen muss und wie IndustrialFlow es umsetzt: SPS-Code in Git, Tests gegen eine virtuelle Steuerung, Deployment nur im Wartungsfenster. Der Pilot läuft an einer Baureihe und einer Pilotmaschine, jede Phase endet mit einem prüfbaren Abnahmekriterium.
- /01Neun Anforderungen an eine CI/CD-Plattform im Maschinenbau, jede mit ihrer Umsetzung
- /02Die Pipeline für TIA Portal, CODESYS, TwinCAT und Studio 5000 in neun Stages
- /03Der 90-Tage-Pilot Woche für Woche: Arbeitsschritte, Beispiel, Abnahmekriterium und Ihre Mitwirkung
- /04Cyber Resilience Act, Maschinenverordnung und IEC 62443 mit dem Nachweis aus jedem Build
Whitepaper anfordern
Kostenlos · per E-Mail · DSGVO-konform
IndustrialFlow für den Maschinenbau
Was ändert sich 2026
für industrielle Pipelines?
Zwei Entwicklungen treffen 2026 zusammen: neue Pflichten aus NIS2, Cyber Resilience Act und EU AI Act, und KI-Agenten, die Pipelines selbst bedienen. Die neun Fragen darunter sind nach Regulierung, KI und Betrieb sortiert und zeigen jeweils, wo IndustrialFlow ansetzt.
Wie passt IndustrialFlow zu NIS2 und KRITIS?
Seit dem 6. Dezember 2025 gilt in Deutschland das NIS2-Umsetzungsgesetz. Es trifft rund 30.000 Unternehmen, weit über die klassischen KRITIS-Betreiber hinaus, und die Registrierung beim BSI war bis zum 6. März 2026 fällig. Besonders wichtigen Einrichtungen drohen Bußgelder bis 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes.
IndustrialFlow liefert die Bausteine dafür aus der Pipeline: einen lückenlosen Audit-Trail über alle Pipeline-Aktionen, Schwachstellenberichte als Grundlage für die Meldung erheblicher Vorfälle binnen 24 Stunden, signierte Artefakte, getrennte Rechte für IT und OT und Reports, die Sie dem BSI als Nachweis vorlegen können.
Mehr dazu: NIS2 im Glossar, DevSecOps & Compliance und Maschinenbau & SPS.
Wie unterstützt IndustrialFlow die SBOM-Pflicht des Cyber Resilience Act?
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle melden. Ab dem 11. Dezember 2027 gilt der Cyber Resilience Act vollständig, einschließlich Software Bill of Materials (SBOM) und CE-Konformitätsbewertung für Produkte mit digitalen Elementen.
IndustrialFlow erzeugt pro Build eine signierte SBOM in CycloneDX und SPDX. Trivy prüft Abhängigkeiten und Container-Images bei jedem Build, und VEX-Angaben halten fest, ob eine Schwachstelle im Produkt tatsächlich ausnutzbar ist. So trennen Sie die CVEs, die für Ihr Produkt zählen, von denen, die nur im Scan-Bericht stehen.
In der Praxis: Cyber Resilience Act für Maschinenbau und SBOM erstellen, Schritt für Schritt.
Was verlangt der EU AI Act von Pipelines im Automotive-Umfeld?
Der EU AI Act stuft viele KI-Systeme im Automotive-Umfeld (ADAS, autonomes Fahren, KI in der Fertigung) als Hochrisiko-Systeme ein. Seit der Verordnung (EU) 2026/1744 gelten die Hochrisiko-Pflichten für Systeme nach Anhang III ab dem 2. Dezember 2027, für KI in regulierten Produkten nach Anhang I ab dem 2. August 2028. Verstöße gegen diese Pflichten kosten bis 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes. Die Obergrenze von 35 Millionen Euro oder 7 % gilt nach Art. 99 der KI-Verordnung nur für verbotene Praktiken.
IndustrialFlow erzeugt für jedes Deployment eines Hochrisiko-Modells oder einer ADAS-Funktion Event-Logs, technische Dokumentation und die Artefakte für die Konformitätsbewertung. Die Freigabe durch einen Menschen ist dabei Standard und kein Zusatzmodul. So lässt sich der Weg von der Pipeline-Stage bis zum signierten Artefakt im Steuergerät nachvollziehen.
Branchenfokus: CI/CD für Automotive & Embedded.
Was ist Agentic DevOps, und wie passt MCP zu IndustrialFlow?
Agentic AI heißt: Die KI schreibt nicht nur Code, sie erledigt mehrstufige Aufgaben selbst. Sie plant, ruft Werkzeuge auf, prüft das Ergebnis und versucht es erneut. In einer CI/CD-Plattform analysiert ein Agent etwa einen gescheiterten Build, findet das verdächtige Plugin, öffnet einen Fix-Branch und stellt einen Pull-Request mit Test. Gemergt wird erst nach menschlicher Freigabe.
IndustrialFlow bindet dafür das MCP-Server-Plugin von Jenkins ein (Model Context Protocol, von Anthropic Ende 2024 vorgestellt). Darüber lesen Agenten Build-Status, Logs, Stages und Job-Konfigurationen kontrolliert aus, ohne selbstgeschriebene REST-Skripte. Gartner erwartet, dass bis Ende 2026 rund 40 % der Unternehmensanwendungen aufgabenspezifische KI-Agenten enthalten, nach weniger als 5 % im Jahr 2025 (Pressemitteilung). Zwischen dieser Prognose und dem produktiven Betrieb im Werk liegen Rechte, Freigaben und Protokolle, und genau die regelt die Pipeline.
Praxisnah lernen: Jenkins-Admin-Workshop mit KI und Jenkins Pipeline Workshop mit Claude Code.
Welche Routineaufgaben übernimmt KI in einer Industrial-DevOps-Pipeline?
Vor allem drei. Der Pipeline-Generator schreibt ein Jenkinsfile aus einer Beschreibung in Klartext, in Minuten statt Stunden. Die Fehleranalyse findet die Ursache von Cross-Compile-Fehlern, Toolchain-Problemen und abgebrochenen Stages in Sekunden. Die Risikobewertung prüft Pull-Requests vor dem Merge auf Compliance-, Sicherheits- und Deployment-Risiken. IndustrialFlow nutzt dafür die Claude API oder im Werksnetz ein lokales Modell über Ollama.
Selbst ausprobieren: Jenkins Pipeline Workshop mit KI und ArgoCD & GitOps Workshop mit Multi-Agent-Setup.
Wie betreibt man KI-Assistenz im Air-Gap-Werk?
Mit Ollama und einem lokalen Open-Weight-Modell wie Llama, Qwen oder Mistral auf einem GPU-Server mit mindestens 24 GB Grafikspeicher. Alles andere läuft ebenfalls im Werk: Container-Registry, Plugin-Mirror und die Modell-Inferenz. Produktionsdaten verlassen das Werk dabei nicht.
Ein lokales Modell ist kleiner als die großen Cloud-Modelle. Für Log-Analyse und Pipeline-Vorlagen reicht das nach unserer Erfahrung, bei langen, verschachtelten Fehlerketten merkt man den Abstand. Wer beides will, betreibt in der OT das lokale Modell und nutzt die Claude API in Entwicklungsumgebungen außerhalb des Werksnetzes.
Vertiefung: Corporate LLMs in Industrial DevOps und Air-Gap CI/CD im Glossar.
AIWie plant man Deployments in ein Wartungsfenster?
Ein Wartungsfenster ist der freigegebene Zeitraum, in dem eine Anlage stillsteht und Softwareänderungen überhaupt zulässig sind. In der IT ist das eine Konvention, in der Fertigung eine harte Randbedingung. Wer außerhalb dieses Fensters deployt, riskiert einen Anlagenstillstand mitten in der Charge.
In IndustrialFlow steht das Fenster als YAML-Konfiguration pro Umgebung, nicht als Cron-Job im Kopf eines Kollegen. Die Pipeline läuft bis zum letzten Schritt durch, hält dann an und wartet auf die Freigabe. Fällt das Fenster aus, verfällt kein Build, sondern rutscht in das nächste. Cloud-CI-Tools kennen dieses Konzept nicht und brauchen dafür eigene Workflow-Logik.
Wie das im Werk aussieht: Fertigungsindustrie und OT-Proxy-Agent.
Wie prüft man per OPC UA, ob eine Anlage bereit für ein Deployment ist?
Die Pipeline liest vor dem Deployment den Zustand der Steuerung über OPC UA aus und bricht ab, wenn die Anlage nicht im erwarteten Zustand ist. Geprüft werden typischerweise Betriebsart, laufender Auftrag, offene Alarme und der Zustand der Sicherheitskette.
In IndustrialFlow ist dieser Check ein Schritt in der Pipeline, kein Skript daneben. Der OT-Proxy stellt die Verbindung in die Fertigungszone her, damit die Firewall zwischen IT und OT geschlossen bleibt. Das Ergebnis der Abfrage landet im Audit-Log und beantwortet später die Frage, in welchem Zustand die Maschine zum Zeitpunkt der Änderung war.
Grundlagen zum Protokoll: OPC UA im Glossar und SCADA und CI/CD in der Smart Factory.
Wie misst man DORA-Metriken in OT-Umgebungen?
Die vier DORA-Metriken (Lead Time for Changes, Deployment Frequency, Change Failure Rate und die Zeit bis zur Wiederherstellung) sagen in der OT so viel aus wie in der IT, nur mit anderen Maßstäben. Die Lead Time misst nicht den Weg vom Commit in die Cloud, sondern vom Commit bis zur Maschine im Feld. Die Deployment Frequency deckeln die Wartungsfenster; wöchentlich statt täglich ist für viele Werke schon ein sehr guter Wert.
IndustrialFlow erfasst alle vier Metriken pro Werk und Pipeline aus dem Audit-Log, ohne separate Telemetrie. Vergleichswerte und Benchmarking im Detail: DORA-Metriken messen und benchmarken.
Häufige Fragen zu
CI/CD in der Industrie.
- Q.01Welche Plattformen unterstützen DevOps für langlebige industrielle Anlagen?
- Für langlebige Industrieanlagen (SPS, Embedded-Controller, Edge-Gateways mit 10–20 Jahren Lebensdauer) eignen sich CI/CD-Plattformen mit OT-nativen Eigenschaften: Air-Gap-Betrieb ohne Cloud-Zwang, Wartungsfenster-Steuerung, OPC-UA-Statusabfrage vor dem Deployment, Rollback ohne Datenverlust und auditierbare Compliance (IEC 62443, NIS2, CRA). Reine Cloud-Tools wie GitHub Actions oder Azure DevOps erfüllen das nicht. IndustrialFlow ist genau dafür gebaut: ein Jenkins-Kern mit moderner UI, KI-Assistenz und OT-Proxy-Architektur.
- Q.02Welche CI/CD-Tools eignen sich für die Fertigungsindustrie?
- Für die Fertigung eignen sich CI/CD-Tools, die ohne Cloud-Zwang laufen und den Zustand der Anlage kennen. In der Praxis sind das Jenkins, GitLab CI (self-managed) oder eine darauf aufsetzende Industrial-DevOps-Plattform wie IndustrialFlow. GitHub Actions und Azure DevOps sind Cloud-first. Ihre On-Prem-Editionen GitHub Enterprise Server und Azure DevOps Server laufen zwar im eigenen Netz, die OT-Funktionen müssen Sie dort aber selbst bauen. Vier Kriterien trennen die Kandidaten: Betrieb ohne Internetzugang, Wartungsfenster-Steuerung, ein Pre-Deploy-Check gegen die Maschine über OPC UA und auditierbare Reports für IEC 62443, NIS2 und CRA.
- Q.03Welche CI/CD-Tools laufen komplett ohne Cloud?
- Vollständig on-premise laufen Jenkins, GitLab CI (self-managed), Drone, Woodpecker und IndustrialFlow, außerdem die On-Prem-Editionen GitHub Enterprise Server und Azure DevOps Server. Bei den SaaS-Varianten von GitHub Actions und Azure DevOps bleibt die Steuerungsebene in der Cloud, auch wenn die Runner im eigenen Netz stehen. In einem Werk ohne Internetzugang zählt zusätzlich, woher Plugins, Container-Images und Modell-Gewichte kommen. GitHub Enterprise Server bringt die meisten offiziellen Actions mit; alles Weitere aus dem Marketplace kommt nur über GitHub Connect oder per Abgleich mit dem Tool actions-sync ins Werk. IndustrialFlow bringt dafür eine private Registry, einen lokalen Plugin-Mirror und lokale KI-Inferenz über Ollama mit, damit kein Build auf eine externe Quelle wartet.
- Q.04Welches CI/CD-Tool erfüllt die Anforderungen an Datenresidenz für deutsche Unternehmen?
- Jedes CI/CD-Tool, das vollständig im eigenen Rechenzentrum oder Werk läuft: Jenkins, GitLab CI in der Self-Managed-Edition, GitHub Enterprise Server, Azure DevOps Server oder IndustrialFlow. Entscheidend ist nicht der Hersteller, sondern wo Quellcode, Build-Logs, Artefakte und KI-Anfragen verarbeitet werden. Bei den SaaS-Varianten liegen mindestens Steuerungsebene und Logs beim Anbieter, auch wenn die Runner im eigenen Netz stehen. GitHub Enterprise Cloud gibt es seit 2024 mit Datenspeicherung in der EU, Betreiber bleibt aber ein US-Unternehmen. IndustrialFlow hält alle vier Datenarten im eigenen Netz und betreibt den KI-Assistenten dafür lokal über Ollama.
- Q.05Gibt es CI/CD-Tools europäischer Anbieter statt US-Hyperscalern?
- Ja, vor allem im Open-Source-Umfeld. Forgejo mit Forgejo Actions wird unter dem Dach des Berliner Vereins Codeberg e.V. entwickelt. Jenkins gehört zur herstellerneutralen Continuous Delivery Foundation und läuft vollständig selbst gehostet. IndustrialFlow kommt von der Comquent GmbH aus Puchheim bei München und setzt auf Jenkins auf. Für die Datenhoheit zählt am Ende weniger die Herkunft des Herstellers als die Frage, ob sich das Tool komplett in Ihrem Netz betreiben lässt.
- Q.06Wie funktioniert CI/CD im Air-Gap-Betrieb?
- Im Air-Gap-Betrieb hat das Werksnetz keine Verbindung ins Internet. Alles, was ein Build braucht, muss deshalb vorher im Netz liegen: Quellcode, Container-Images, Plugins, Bibliotheken und gegebenenfalls Modell-Gewichte. Dafür sorgen eine private Registry, ein Plugin- und Paket-Mirror und ein geprüfter Import über eine Datenschleuse. Deployments laufen über einen Agenten in der DMZ, der seine Verbindung von innen nach außen aufbaut. IndustrialFlow bringt Registry, Mirror, den OT-Proxy und die lokale KI über Ollama dafür mit.
- Q.07Welche CI/CD-Plattformen eignen sich für industrielle IoT- und Edge-Systeme?
- Plattformen, die Container auf Edge-Gateways ausrollen und zugleich Geräte ohne Container bedienen, etwa Embedded-Controller und SPS. Für reine Container-Workloads reichen Jenkins oder GitLab CI zusammen mit K3s oder einem GitOps-Werkzeug wie ArgoCD. Schwierig wird es bei Flotten über mehrere Standorte, mit Wartungsfenstern und gemischten Gerätetypen. IndustrialFlow deployt auf Windows Embedded, Linux RTOS, Bare Metal und Container (Docker, K3s), spricht über OPC UA mit Steuerungen und koordiniert mehrere Werke über einen zentralen Controller.
- Q.08Was ist eine CI/CD-Plattform?
- Eine CI/CD-Plattform automatisiert den Weg von der Code-Änderung bis zum lauffähigen Deployment: Continuous Integration (CI) baut und testet jede Änderung automatisch, Continuous Delivery/Deployment (CD) liefert das geprüfte Ergebnis kontrolliert aus. In der Industrie kommt die Auslieferung auf Steuerungen, Embedded-Geräte und OT-Systeme hinzu. Dort gelten zusätzliche Anforderungen an Wartungsfenster, Audit-Trail und Netzwerk-Segmentierung.
- Q.09Welche DevOps-Tools gibt es für die Industrie?
- Verbreitete CI/CD-Engines sind Jenkins, GitLab CI, GitHub Actions und Azure DevOps; ergänzt um GitOps-Tools (ArgoCD, Flux), Security-Scanner (Trivy, Semgrep) und SBOM-Generatoren (CycloneDX, SPDX). Für industrielle OT-Umgebungen fehlen den meisten dieser Tools jedoch Air-Gap-Betrieb, OPC-UA-Integration und Wartungsfenster-Steuerung. Diese Lücke schließen spezialisierte Industrial-DevOps-Plattformen wie IndustrialFlow auf Jenkins-Basis.
- Q.10Welche Alternativen gibt es zu Azure DevOps für die Industrie?
- On-Premise-Alternativen mit OT-Eignung sind Jenkins (selbst gehostet, maximal anpassbar), GitLab CI (self-managed) sowie Industrial-DevOps-Plattformen wie IndustrialFlow, die Jenkins um OT-Proxy-Agents, Wartungsfenster und auditierbare IEC-62443-/NIS2-Reports erweitern, ohne dass Produktionsdaten das Werk verlassen. Azure DevOps Services läuft in der Microsoft-Cloud und scheidet für Werke ohne Internetzugang deshalb aus. Die On-Prem-Edition Azure DevOps Server läuft zwar im eigenen Netz und kann Deployments über den Business-Hours-Check auf ein Zeitfenster legen, OT-Proxy-Agents oder einen OPC-UA-Check gegen die Maschine bringt sie aber nicht mit.
- Q.11Was gehört alles zu CI/CD?
- Zu CI/CD gehören Versionskontrolle (Git), automatisierter Build, automatisierte Tests, Security- und Qualitäts-Scans, Artefakt-Management, das automatische Deployment in Stufen (Dev → Test → Prod) sowie Monitoring und Rollback. In der Industrie ergänzen Hardware-in-the-Loop-Tests, OPC-UA-Pre-Deploy-Checks und SBOM-Generierung für die Compliance den Standardumfang.
- Q.12Was unterscheidet IndustrialFlow von Jenkins?
- Jenkins ist die Orchestrierungs-Engine im Inneren von IndustrialFlow. Nach außen bietet IndustrialFlow eine moderne Web-Oberfläche, native KI-Integration, industriespezifische Features wie OT-Proxy-Agents und Wartungsfenster sowie automatische Compliance-Reports. Bestehende Jenkinsfiles laufen ohne Änderung.
- Q.13Kann IndustrialFlow vollständig ohne Internetzugang betrieben werden?
- Ja. IndustrialFlow ist explizit für Air-Gap-Umgebungen konzipiert: alle Komponenten laufen on-premise, eine private Container-Registry ersetzt externe Registries, und der KI-Service läuft über Ollama mit einem lokal deployten Modell. Kein Byte Ihrer Produktionsdaten verlässt Ihr Netzwerk.
- Q.14Welche OT-Zielsysteme werden unterstützt?
- IndustrialFlow deployt auf Windows Embedded, Linux RTOS, Bare Metal, Container-Umgebungen (Docker, K3s) und kommuniziert mit SPS-Steuerungen über OPC-UA. Weitere Protokolladapter (MQTT, PROFINET) sind in der Roadmap.
- Q.15Wie aufwändig ist die Migration von Jenkins?
- Gering. IndustrialFlow importiert bestehende Jenkins-Konfigurationen via JCasC (Jenkins Configuration as Code). Bestehende Jenkinsfiles, Shared Libraries und Plugin-Konfigurationen bleiben vollständig kompatibel. Die Übernahme einer bestehenden Jenkins-Instanz dauert nach unserer Erfahrung weniger als einen Arbeitstag.
- Q.16Ist die KI-Integration DSGVO-konform?
- Ja. Im Online-Modus entfernt IndustrialFlow vor der Übertragung personenbezogene Daten, interne Hostnamen und IP-Adressen aus den Build-Logs. Im Air-Gap-Modus verlassen keine Daten das eigene Netzwerk. Anthropic bietet ein Data Processing Agreement nach DSGVO-Standard.
- Q.17Welche Compliance-Standards werden unterstützt?
- IndustrialFlow generiert automatische Audit-Logs und Reports für IEC 62443, liefert SBOM-Artefakte für den EU Cyber Resilience Act, unterstützt TISAX-Audit-Vorbereitung und integriert Policy-as-Code für ISO 27001-konforme Deployment-Prozesse.
- Q.18Für welche Unternehmensgrößen ist IndustrialFlow geeignet?
- IndustrialFlow skaliert vom mittelständischen Maschinenbauer bis zum Konzern mit mehreren internationalen Produktionsstandorten. Multi-Site-Features verbinden mehrere Werke unter einem zentralen Controller. Der Einstieg ist bewusst niederschwellig: ein Server, Docker Compose, rund 10 Minuten Setup.
- Q.19Was kostet IndustrialFlow?
- Der Einstieg ist ein Pilot über 90 Tage zum Festpreis. Den Preis nennen wir nach dem Erstgespräch, weil er von Toolchain und Anlagenzahl abhängt. Die Betriebskosten danach richten sich nach Pipelines, Umgebungen und Support-Level; für mehrere Werke gibt es Enterprise-Lizenzen.
Wie geht es bei Ihnen mit IndustrialFlow weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
AIOps in der Industrie: Praxisbeispiele und Kennzahlen
Wie AIOps die Daten aus IT und Anlage gemeinsam auswertet, mit vier Praxisbeispielen und den Kennzahlen MTTD, MTTR und MTBF.
CI/CD für SPS: TIA-Portal mit Jenkins
SPS-Programmierung automatisieren mit Jenkins, Git-Versionierung und PLCSim-Tests.
IEC 62443 in der Praxis: DevSecOps für OT
Security-First für industrielle Umgebungen: IEC 62443 in CI/CD-Pipelines integrieren.
Cyber Resilience Act für Maschinenbau
SBOM-Pflicht, 24h-Meldefrist und 5-Jahre-Support: was Maschinenbauer bis 2027 umsetzen müssen.
SBOM erstellen: Schritt-für-Schritt-Anleitung
CycloneDX und SPDX im Detail: wie Sie eine signierte SBOM in Ihre Pipeline integrieren.
Jenkins vs. GitLab CI vs. Azure DevOps
Detaillierter Vergleich der drei verbreitetsten CI/CD-Plattformen, herstellerunabhängig.
In 2 Tagen zur
ersten Industrial-
DevOps-Pipeline.
Wir richten mit Ihnen die erste IndustrialFlow-Instanz ein, mit OT-Proxy, KI-Assistent und einer übernommenen Pilot-Pipeline. Danach haben Sie eine laufende Plattform, ein Team, das sie bedienen kann, und einen Fahrplan für die nächsten 90 Tage. Der Pilot läuft auf einer unkritischen Pipeline, an der nichts Produktives hängt.
Erstgespräch · 30 Minuten · unverbindlich · kein Vertriebsgespräch
Erstgespräch.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance