Kurs · Schulung · Workshop

Embedded DevOps: CI/CD für Firmware & Embedded Linux

Build, Test und Release für Embedded-Software automatisieren: Cross-Compile-Toolchains in Containern, Unit-Tests auf dem Host, Hardware-in-the-Loop mit eigenen Runnern, reproduzierbare Firmware-Artefakte und CRA-taugliche SBOM- und Release-Pipelines.

Embedded-Projekte haben eigene Regeln: proprietäre Compiler, Cross-Compilation, Zielhardware, die nicht in der Cloud steht, lange Build-Zyklen und Nachweispflichten aus Normen und Regulierung. Genau deshalb bleibt CI/CD in vielen Firmware-Teams beim nächtlichen Build-Script stehen. Dieser Kurs zeigt, wie ein durchgängiger Delivery-Prozess für C/C++-Firmware und Embedded-Linux-Systeme aussieht – von der containerisierten Toolchain über Unit- und Integrationstests auf dem Host bis zu Hardware-in-the-Loop-Tests auf echten Targets, die über eigene Runner an die Pipeline angebunden sind. Die Teilnehmenden bauen im Kurs eine vollständige Pipeline für ein reales Embedded-Projekt auf: reproduzierbare Builds, statische Analyse, Tests, versionierte Firmware-Artefakte, SBOM, signierte Releases und Dokumentation, die automatisch mit dem Code mitwächst. Wir arbeiten mit GitLab CI/CD; die Konzepte sind auf GitHub Actions, Jenkins und andere Systeme übertragbar.

In-House Kurs

Massgeschneidert für Ihr Team.

Anfragen

Kein passender Termin?

Neuen öffentlichen Termin anfragen.

Termin anfragen

Trainer

Urs Fässler

Trainer

Stimmen unserer Teilnehmer:innen

Diese Kunden haben Kurse im gleichen Themen-Cluster bei uns gebucht.Mehr Kunden →

Inhalt

Der Kurs besteht aus den folgenden Themen und wird für Inhouse-Durchführungen auf Toolchain, Build-System und Zielhardware des Teams zugeschnitten. Wir arbeiten mit GitLab CI/CD, CMake und Containern an einem realen C/C++-Projekt mit Embedded-Linux-Target; die Konzepte sind auf andere CI-Systeme und Bare-Metal-Targets übertragbar.

– Warum CI/CD in Embedded-Projekten anders ist:

Delivery-Ziel Gerät statt Cloud: was sich aus DevOps übertragen lässt und was nicht
Typische Blocker: proprietäre Compiler, Lizenzen, Zielhardware, lange Builds
Pipeline als Qualitäts- und Nachweiswerkzeug, nicht nur als Build-Automat – Toolchain in den Container:
Cross-Compile-Toolchains (GCC/Clang, Vendor-SDKs, Yocto/Buildroot SDK) reproduzierbar in Docker-Images packen
Umgang mit proprietären und lizenzgebundenen Compilern in der Pipeline
CMake-Toolchain-Files, Presets und Build-Varianten pro Target
Reproduzierbare Builds: Versionen pinnen, Build-Umgebung versionieren
Hands-On: Toolchain-Image bauen und ersten Pipeline-Build des Projekts durchführen – GitLab CI/CD für Embedded-Teams:
Jobs, Stages, Rules, Caching und Artefakte in der Praxis
Pipeline-Struktur für mehrere Targets und Build-Varianten
Build-Zeiten in den Griff bekommen: Caching, Parallelisierung, inkrementelle Builds
Hands-On: mehrstufige Pipeline mit Build-Matrix aufsetzen – Testbare Firmware-Architektur:
Hardware-Abstraktion und Schichtung, damit Logik ohne Target testbar wird
Legacy-Code schrittweise unter Test bringen
Unit-Tests auf dem Host mit GoogleTest/Catch2, Mocks für Peripherie und Treiber
Hands-On: hardwareunabhängige Logik extrahieren und in der Pipeline testen – Statische Analyse und Qualitätsgates:
clang-tidy, cppcheck, Compiler-Warnungen als Fehler, Coding-Standards (MISRA/CERT als Orientierung)
Code-Coverage erfassen und in Merge Requests sichtbar machen
Quality Gates definieren, die den Merge blockieren
Hands-On: Analyse- und Coverage-Jobs mit Merge-Request-Reports – Hardware-in-the-Loop (HiL) und Target-Tests:
Self-Hosted Runner am Teststand: Zielhardware sicher an die Pipeline anbinden
Flashen, Booten, Testen und Ergebnisse einsammeln – automatisiert
Emulation (QEMU) als Zwischenstufe zwischen Host-Test und echter Hardware
Umgang mit knapper Hardware: Scheduling, Reservierung, Stabilität von HiL-Jobs
Hands-On: Target-Test-Job auf einem Runner mit angebundener Hardware bzw. Emulation – Embedded Linux in der Pipeline:
Yocto/Buildroot-Builds automatisieren, Caching für lange Image-Builds
Image-Tests und Systemtests im Container oder in QEMU
Abgrenzung: Applikations-Pipeline vs. System-Image-Pipeline – Artefakte, Versionierung und Release:
Firmware-Artefakte versionieren, benennen und nachvollziehbar ablegen (Package Registry)
Software Bill of Materials (SBOM) automatisch erzeugen (SPDX/CycloneDX)
Firmware signieren, Release-Pipeline mit manuellem Gate
Update- und OTA-Pakete als Pipeline-Output
Hands-On: Release-Job mit versioniertem, signiertem Artefakt und SBOM – Nachweise und Compliance aus der Pipeline:
Pipeline-Ergebnisse als Evidenz für CRA und weitere Branchen-Normen
Traceability: Anforderung → Test → Pipeline-Lauf → Release
Documentation-as-Code: Dokumentation mit dem Code versionieren und automatisch bauen
Hands-On: Traceability-Report und Dokumentation als Pipeline-Artefakt – Einführung im eigenen Projekt:
Bestehendes Projekt schrittweise in die Pipeline bringen: Reihenfolge und Quick Wins
Umgang mit Widerständen: lange Builds, wenig Hardware, Legacy-Code
Rollout-Plan für das eigene Team erarbeiten

Der Kurs ist bewusst werkzeugübergreifend angelegt: Wir arbeiten praktisch mit GitLab CI/CD, die Muster – Toolchain-Container, Host-Tests, Runner am Teststand, Artefakte und Nachweise – funktionieren mit GitHub Actions, Jenkins oder Azure DevOps genauso.

Der effektive Kursinhalt kann, abhängig von Trainer, Durchführung, Dauer und Konstellation der Teilnehmer:innen, von obigen Angaben abweichen.

Ziel

Nach diesem Kurs können Sie eine CI/CD-Pipeline für ein bestehendes oder neues Embedded-Projekt aufsetzen und betreiben. Sie packen Ihre Cross-Compile-Toolchain – inklusive proprietärer Compiler – reproduzierbar in Container, trennen hardwareunabhängige von hardwareabhängiger Logik, damit Unit-Tests auf dem Host laufen, und binden Zielhardware über Self-Hosted Runner für Hardware-in-the-Loop-Tests an. Sie erzeugen versionierte, nachvollziehbare Firmware-Artefakte mit SBOM und Signatur und wissen, wie Pipeline-Ergebnisse als Nachweis für den Cyber Resilience Act (CRA) und weitere Branchen-Normen genutzt werden. Damit wird Ihre Pipeline vom Build-Automat zum Qualitäts- und Compliance-Werkzeug des Teams.

Dauer

2 Tage

Form

Zwei Tage Hands-on. Die Teilnehmenden arbeiten an einem realen Embedded-Projekt (C/C++, CMake, Embedded Linux) in der Letsboot Labmachine mit GitLab, Containern und angebundener Zielhardware bzw. Emulation. Jeder Themenblock endet mit einer Pipeline-Erweiterung, die die Teilnehmenden selbst umsetzen. Der Trainer bringt seine Erfahrung aus Modernisierungs- und Compliance-Projekten ein und geht auf die konkreten Toolchains und Targets der Teilnehmenden ein.

Zielgruppe

Firmware- und Embedded-Software-Entwickler, Testingenieure, Embedded-Linux-Engineers, Tech Leads und DevOps-Verantwortliche, die CI/CD in Embedded-Projekten einführen oder eine bestehende Pipeline auf ein solides Niveau bringen wollen. Besonders geeignet für Teams in regulierten Umfeldern, die Nachweise automatisiert erzeugen müssen.

Voraussetzungen

Erfahrung in der Embedded-Softwareentwicklung (C oder C++), sicherer Umgang mit Git und der Linux-Kommandozeile. Grundkenntnisse zu Containern (Docker) sind hilfreich, aber nicht Voraussetzung. Vorkenntnisse zu GitLab CI/CD werden nicht erwartet.

Vorbereitung

Vor dem Kurs erhält jeder Teilnehmer einen Fragebogen zu Toolchain, Zielhardware, Build-System und Teststand, damit wir die Übungen und Beispiele auf das Umfeld der Gruppe abstimmen. Wir stellen die Letsboot Labmachine mit vorinstalliertem Tooling bereit; für Inhouse-Kurse können eigene Toolchains und Targets eingebunden werden. Nach dem Kurs bleibt der Zugang zur Labmachine für weiteres Experimentieren bestehen.

In-House Kurs anfragen

Öffentlichen Termin anfragen

Kein passender öffentlicher Termin dabei? Trag dich unverbindlich ein – sobald genug Interesse besteht, planen wir einen neuen öffentlichen Termin und informieren dich zuerst.

Mehr über Embedded DevOps

DevOps-Praktiken aus der Cloud-Welt lassen sich nicht eins zu eins auf Firmware übertragen: Das Deployment-Ziel ist ein Gerät, kein Kubernetes-Cluster; der Compiler ist oft proprietär; und der Nachweis, dass eine Firmware-Version korrekt gebaut und getestet wurde, ist in vielen Branchen Pflicht. Embedded DevOps übernimmt die Prinzipien – kurze Feedback-Zyklen, Automatisierung, alles versioniert – und übersetzt sie in Werkzeuge und Abläufe, die mit Cross-Compilation, Hardware-Tests und Regulierung funktionieren.

Weitere Ressourcen:

History

Continuous Integration entstand in den späten 1990er-Jahren im Umfeld von Extreme Programming und wurde in der Web- und Enterprise-Entwicklung schnell Standard. Embedded-Teams zogen langsamer nach: Proprietäre Toolchains, lizenzgebundene Compiler und der Bedarf an physischer Zielhardware machten automatisierte Pipelines aufwendig. Lange blieb es beim nächtlichen Build auf einem dedizierten Rechner.

Container, CMake als De-facto-Standard-Build-System und Self-Hosted Runner, die Hardware direkt an die Pipeline anbinden, haben das ab den 2010er-Jahren verändert. Mit dem Cyber Resilience Act und branchenspezifischen Normen ist die automatisierte, nachvollziehbare Delivery-Pipeline heute nicht mehr nur Produktivitätsfrage, sondern Voraussetzung, um Produkte überhaupt in Verkehr bringen zu dürfen.